Native Image Cache & .NET Framework Update RRS feed

  • Question

  •  I am trying to track down a customer issue in which my application is performing unexpectedly after an update to the .NET runtime (e.g. a service pack) is installed.  I can recreate this issue by:

    1. Install .NET Framework 2.0.
    2. Install my application.  Everything works as expected.
    3. Install .NET Framework 2.0 Service Pack 1.
    4. Reboot
    5. Unexpected behavior that customer is seeing.

    Tracing this issue further, it appears that my assembly is no longer in the Native Image Cache on the system.  Instead, it is listed as 
    (StatusPending) (Pri 3) 
    when I run 'ngen.exe display'.  Ok, so the Service Pack invalidates all native images and queues them for regeneration (makes sense).  However, it has now been 30 minutes since step 4 above, and none of the queued assemblies has been regenerated (I let the machine sit idle until opening IE to post).  The assembly in question is a 3rd party library that has known issues with JIT and as a result must be installed as a native image.

    Does anyone know approximately how long it takes after a .NET update to get the freshly-generated images?

    Are there any known issues with mscorsvw.exe that would cause this to take so long (it has yet to even regenerate one image of the 50 or so queued items).

    Is there anyway, short of ngen.exe executeQueuedItems, to make this happen more quickly?

    Any help would be appreciated.

    Tuesday, July 29, 2008 3:30 PM


  • Well, it should be done by now.  It takes a while.  Run ngen.exe executequeueditems to see feedback.  Beware that ngen.exe uses the exact same JIT compiler as the framework.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Monday, August 4, 2008 7:13 AM
    Wednesday, July 30, 2008 2:42 AM