Fix For App-V .NET Applications Broken By Recent Security Updates

Over the past 9 months or so I’ve either experienced or heard about issues where a sequenced .NET application runs fine on a clean App-V client but not a live production build.  I recently found this again in Attachmate Reflection 2011 R2 SP1; I had a sequence that worked, but when I re-sequenced it, I got a ‘CLR error: 80004005‘ error when trying to launch on the customer’s Windows 7 x64 desktop.  It worked fine on my clean unpatched test VM however.

This application uses .NET 4, and a Google search indicated that re-installing the .NET Framework v4 might fix my problem, which indeed it did!  I came to the conclusion that this was due to the fact that re-installing the framework also removes all of the .NET 4 related security updates.  I grabbed a copy of these patches to see which ones could replicate the crash on my test machine:

  • OK:
    • MS11-039 (KB2478663)
    • MS11-066 (KB2487367)
    • MS11-044 (KB2518870)
    • MS11-069 (KB2539636)
    • MS11-100 (KB2656351)
  • Problematic:
    • MS11-078 (KB2572078)
    • MS12-035 (KB2604121)
    • MS12-016 (KB2633870)
    • MS12-025 (KB2656368)
    • MS12-034 (KB2656405)
    • MS12-038 (KB2686831)

So, one patch from 2011 and all of the ones from 2012 caused the issue.  But simply not deploying these patches wasn’t really an option for me.  Luckily I was in a good position to troubleshoot as I had an older version of the sequence that worked fine with these .NET patches, so I set about comparing them.

Through a bit of trial and error, I found that the registry keys under HKLM\Software\Microsoft\Fusion\NativeImagesIndex were the culprit.  Here is what the working registry looked like:

And the registry of the non-working app:

There is a registry value HKLM\Software\Microsoft\Fusion\NativeImagesIndex\v4.0.30319_32\LatestIndex (set to ee in hex):

Then a corresponding subkey named indexee:

Deleting this indexee subkey was enough to fix the application.  By the way, you can also see the previous index entries were deleted during sequencing so are stored in the sequence in a deleted state, which hides the equivalent real keys from the virtual app.  You cannot see these hidden deleted keys in the sequencer, but you can in AVE.

I don’t fully understand how it works, but the .NET framework compiles .NET applications from MSIL to native machine code in the background via ngen.exe and these registry keys are responsible for storing the mappings between the two.  Somehow the recent .NET patches don’t get on with these settings – perhaps the patches wipe these keys clean on install but are of course unable to do so to the virtual registry.  You are probably perfectly safe to just remove the entire NativeImagesIndex key.

It’s also conceivable that an application could generate this data after launch and store this information in the PKG files, then a .NET update could break the application.  If this ever did happen then repairing the application should help.

 

10 responses on “Fix For App-V .NET Applications Broken By Recent Security Updates

  1. Qaiser Imam

    Nice information!! also this can be implemented when similar issue arises for some other applications as well.

    1. I hope so, do let me know if you ever come across it and this resolves it!

      1. Jonas Berends

        Hi Dan, thanks for posting this – I had this issue for the first time when creating a sequence for PTV SmarTour 2.0.0 today, and your solution did the trick. To be sure, I removed the index subkeys from both the 32- and 64-bit branches in the registry as I sequenced on a 64-bit OS (with App-V 5.0 SP1 as sequencer).

        1. I usually delete the entire NativeImagesIndex reg key from the package nowadays, as well as C:\Windows\Assembly\NativeImages* folders – so check to see if those folders are taking up space too!

          The problem does not occur if the same .NET versions are installed on client and sequencer. It’s possible that the root issue has been fixed in subsequent framework versions, but you never know when a client .NET update will make it happen again!

  2. I am getting seriously close to recommending checking for anything being adding .NET Framework, Fusion, and winsxs folders. The former can probably be safely added to the exclusion list, while in the latter anything with VC## in the name means you need a native install outside the package.

    Awfully glad this side by side stuff solved dll hell!

    1. Not entirely sure but I think some of those .NET Framework keys are necessary, such as those generated when you register assemblies with regasm.exe or gacutil.exe, so be careful with a blanket exclusion list!

      I did sequence this again and left it a little longer before stopping the monitoring process and I picked up all of the compiled binaries under C:\Windows\Assembly\NativeImageIndex, almost doubling the size of my sequenced app. Deleting everything from the NativeImageIndex in both the file system and registry will save space but may result in a slower running application as I’m not sure if ngen will run again automatically to recompile everything. One thing to note is check at the end of installation and see if mscorsvw.exe is running – if so then the installer has queued up files for ngen to optimise.

    2. It’s ironic that App-V solves traditional dll hell, yet side-by-side causes hell in App-V!

      1. Christoph Wegener

        Would it be a good idea to run an ‘ngen executequeueditems’ after installing anything with .NET into a sequence?

        1. Yes and no (and perhaps). I notice that Microsoft advise to do so when sequencing Visual Studio. It will have the advantage of including all precompiled binaries in the sequence, making the app launch and run faster. However, in the case if the problem with Reflection detailed in this post, running that command would generate those binaries that were causing the problem, only making things worse.

  3. Rajesh Attaluri

    Thanks for this post Dan!!! Saved troubleshooting time for one of the application with same error..

Leave a Reply