none
What is the list of all NGen artifacts that we should add to our UWF write filter exceptions list?

    Question

  • Hi,

    we are developing an application on Windows 8 x64 embedded and we are having issues making the UWF write filter and Ngen coexist.

    I know that Ngen places its assemblies in C:\windows\assembly\NativesImages_* and we excluded that folder, and there's also the registry for which we added exceptions:

    uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework"

    uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOTWARE\Microsoft\Net Framework Setup"

    Without it, we got errors with "Ngen error because Mscorlib.dll does not have a native image" for each assembly being optimized. With them, sometimes we still get this error, but not for all of our assemblies, which makes our application go faster, but not as fast than we do not get this error without the write filter enabled.

    One of colleagues hypothesized that it could due to the fact that during the .Net installation Ngen is started as a queue with priority 3 (when the user is afk) so mscorlib.dll never gets to be installed (we have no screen saver nor lockscreen). We know that because we can see that a background task is scheduled by Ngen.

    It is very hard to figure out what we should exclude. Our only option now is to do compare the whole filesystem before and after, which is log and would give a lot of false positives.

    Monday, January 21, 2019 10:57 PM

Answers

  • You are correct the ngen does get kicked off after OS install. It runs in the background. For UWF, I typically open the following folders to mitigate overlay overflow:

     

    uwfmgr.exe file add-exclusion c:\Windows\System32\winevt\Logs

    uwfmgr.exe file add-exclusion c:\Windows\WinSxS

    uwfmgr.exe file add-exclusion c:\Windows\assembly

     

    I have never touched the registry keys. In my answer file, I have had the following pass 7 OOBE commands:

    ngen.exe update

    ngen.exe eqi 1

     For Windows 10, I have not had to run these NGEN commands like I had to do with earlier versions of Windows Embedded. Keep in mind there is the UWF architecture quirk. All writes are made to the overlay, even write-through. On a reboot the cache will be flushed. The above commands get the ngen process going faster so most of the assemblies are optimized in the master image before UWF is enabled on each clone after sysprep.


    Sean Liming - Book Author: Starter Guide Windows 10 IoT Enterprise - www.annabooks.com / www.seanliming.com


    Wednesday, January 23, 2019 12:50 AM
    Moderator

All replies

  • You are correct the ngen does get kicked off after OS install. It runs in the background. For UWF, I typically open the following folders to mitigate overlay overflow:

     

    uwfmgr.exe file add-exclusion c:\Windows\System32\winevt\Logs

    uwfmgr.exe file add-exclusion c:\Windows\WinSxS

    uwfmgr.exe file add-exclusion c:\Windows\assembly

     

    I have never touched the registry keys. In my answer file, I have had the following pass 7 OOBE commands:

    ngen.exe update

    ngen.exe eqi 1

     For Windows 10, I have not had to run these NGEN commands like I had to do with earlier versions of Windows Embedded. Keep in mind there is the UWF architecture quirk. All writes are made to the overlay, even write-through. On a reboot the cache will be flushed. The above commands get the ngen process going faster so most of the assemblies are optimized in the master image before UWF is enabled on each clone after sysprep.


    Sean Liming - Book Author: Starter Guide Windows 10 IoT Enterprise - www.annabooks.com / www.seanliming.com


    Wednesday, January 23, 2019 12:50 AM
    Moderator
  • Thank you for your reply.

    By issuing the command "ngen eqi 1", all assemblies related to the .NETFramework are generated.
    Once done, I can do ngen on MyAppA and it starts more quickly as expected. I also see that the "ngened" components of the application have been added to C:\Windows\assembly\NativeImages_v4.0.30319_64 as expected.
    In our context, once .NETFramework has been "ngened", I activate the UWF on the C: drive.
    After activating UWF on c:\, MyAppA can be started quickly. MyAppA is installed on D:\ which is not protected by UWF.

    However, after a while there is a small problem.
    Here it is:
    When I left the device idle for a while (hours or days), and when I launch MyAppA, it stops to start quickly. It's like if it is not "ngended" anymore.

    After some digging, I found on the device that mscorlib.dll has been erased from C:\Windows\assembly\NativeImages_v4.0.30319_64. I understand that this component is essential to "ngen" all other components from .NETFramwork and MyAppA.  Is it true?

    Also, while parsing the ngen.log files, I found that the ngen service was restarted automatically and seems to identify mscorlib.dll file as invalid or corrupted. Mscorlib.dll is then deleted from C:\Windows\assembly\NativeImages_v4.0.30319_64. It's hard to say what triggered this action. It's a bit random.

    If I redo ngen on MyAppA, mscorelib.dll can no longer be compiled with ngen.  Here is the kind of error I see in ngen.log when mscorlib.dll is "ngened".
        -02/12/2019 15: 40: 24.580 [3632]: 1> Compiling assembly mscorlib, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 (CLR v4.0.30319) ...
        -02/12/2019 15: 41: 21.280 [3632]: 1> Error compiling mscorlib, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089: Windows can not verify the digital signature for this file. A recent hardware or software change may have been incorrectly written or incorrectly corrupted. (Exception from HRESULT: 0x80070241)
        -02/12/2019 15: 41: 21.288 [3632]: 1> Ngen failed to generate native code for image mscorlib, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 because of the following error: Windows can not verify the digital signature for this file. A recent hardware or software change may have been incorrectly written or incorrectly corrupted. (Exception from HRESULT: 0x80070241)
        -02/12/2019 15: 41: 21.289 [3632]: 1> Ngen will retry compilation of image mscorlib, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089

    To prevent mscorlib.dll from being deleted, I tried several things without success.  Including:

    -Deactivate the following tasks in the Task Scheduler
       -NET Framework NGEN v4.0.30319 64 Critical
       -.NET Framework NGEN v4.0.30319 64
       -NET Framework NGEN v4.0.30319 Critical
       -NET Framework NGEN v4.0.30319

    Kill ngen optimization service by modifiing :
       -reg add "HKLM \ SYSTEM \ CurrentControlSet \ services \ clr_optimization_v4.0.30319_64" / v DelayedAutostart / t REG_DWORD / d 1 / f
       -reg add "HKLM \ SYSTEM \ CurrentControlSet \ services \ clr_optimization_v4.0.30319_64" / v Start / t REG_DWORD / d 4 / f

    Eliminate pending optimizations by deleting the following registry key:
       -Remove the registry key: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ .NETFramework \ v2.0.50727 \ NGenService \ Roots

    Trying to block erasing mscorlib.dll this way is a good thing?

    Does activating UWF on C:\ after having optimized .NETFramework on C:\ is the cause of "corruption" of mscorlib.dll?  Does UWF corrupt the file mscorlib.dll from a ngen point of view?

    Should the "ngen.exe update" and "ngen.exe eqi 1" commands be started after UWF is enabled on C:\ ? Currently, we are doing the opposite.

    Any hints will be appreciate.

       
    Tuesday, February 12, 2019 9:43 PM