Handling GAC and NGEN Operations after Reboot

Handling GAC and NGEN Operations after Reboot

  • Comments 5

Some people have noticed a general slow-down after restarting their computers after installing a .NET Framework 1.0 or 1.1, or a Visual Studio .NET 2002 or 2003 patch. This is due to a change in how post-reboot operations are handled that are sometimes necessary after installing a patch.

Windows Installer automatically schedules files for replacement if the file is locked. If the file is soft-locked, the in-use file is moved and the NTFS link tracker will remove it when all open handles to it are closed. If a file is hard-locked — which is always the case on Windows 9x and Me — then the file is scheduled for replacement after a reboot. Windows Installer also does not handle installation of files into the GAC directly, but relies on Fusion to do that and Fusion does not currently handle pending file rename operations (PFROs) because registry updates are necessary as well.

So, the Visual Studio Update team — now known as the Developer Division Customer Product-lifecycle Experience team — had to develop a way to install files into the GAC (only on Windows 9x and Me) and NGEN assemblies after a reboot. This was done originally using the RunOnce and Run registry keys. This causes problems, however, as it requires an administrator to login interactively after applying a patch and reboot. This could lead to performance issues since native images are not produced for the new assemblies, or leave the machine in an unpatched state — either in part or in whole.

For this reason NetFxUpdate.exe was rewritten to run as a service on Windows NT. This means that the service can run with the required privileges and does not require a user to login. Much like the new NGEN service in the .NET Framework 2.0, the service only exists when necessary and removes itself when completed. This uses a protected registry store — the same keys used for previous versions of NetFxUpdate.exe — and basic heuristic analysis of the command-line arguments so that it can retroactively fix older patches installed on systems with the newer NetFxUpdate.exe.

Because it is busy launching ngen.exe for updated and dependent assemblies and because creating native images can monopolize system resources, the system may seem to reboot more slowely. This will lead to performance benefits after the NetFxUpdate service has completed, however, and will help insure that your system is up-to-date with the fixes installed by the patch just applied.

Leave a Comment
  • Please add 7 and 6 and type the answer here:
  • Post
  • Hi Heath. Can you elaborate a bit on the soft/hard locking and the link tracker? (Nice link to the link tracker, btw. I've never really understood what that service was for, or how it worked. Now I know!)

    Cheers
    Matt
  • Matt, soft- and hard-locking are the terms we use to describe whether a file can be moved or not.

    When a file is soft-locked the file can be moved and the replacement file put in its place. When all open handles to the moved file are closed the file gets deleted. Meanwhile and after the file is deleted, applications load the replacement file because it has the correct filename.

    When a file is hard-locked the file cannot be moved so a pending file rename operation must be scheduled to replace the file after a reboot. Since pending file renames are handled after AUTOCHK but before page files are created, the file is replaced and applications instances will now use that file.
  • > Because it is busy launching ngen.exe for
    > updated and dependent assemblies and because
    > creating native images can monopolize system
    > resources, the system may seem to reboot
    > more slowely.

    But that's only once per patch, right? (That is, assuming the operation finishes before the next reboot after that.) So it doesn't explain why there would be a general slowdown in subsequent reboots, right?

    As an example I'm suspicious of some of the stuff that gets into the prefetch directory. I haven't looked at it since the early months of Windows XP RTM, but it contained things like Windows Product Activation and some stuff related to driver property pages and other things that should be one-offs instead of being loaded after every reboot. If a patch gets included in prefetch stuff then that could sound like a reason for general slowdowns.
  • Norman, NetFxUpdate.exe is registered only once (whether in RunOnce/Run on 9x or as a service in NT) for one or more patches, and continues to run - even across reboots - until the registry keys for GAC (only on 9x) and NGEN are cleared. As for a general slowdown across reboots (when NetFxUpdate.exe isn't running) I can't say we've seen that.

    The prefetch files aren't only for reboot scenarios but also to improve application startup times as well. Even so, the prefetch files should only be paged when the corresponding application is started.

    Do you have a netfxupdate.exe-[some hash].pf file in your %WINDIR%\Prefetch directory?
  • > and continues to run - even across reboots -
    > until the registry keys for GAC (only on 9x)
    > and NGEN are cleared.

    OK, that's good news, it sounds like it's just once per patch. If someone saw a general slowdown across reboots, it's because they rebooted before netfxupdate was done.

    > Do you have a netfxupdate.exe-[some hash].pf
    > file in your %WINDIR%\Prefetch directory?

    No not on the machine I'm using now, so that's good. There are 103 other files in it though, including 6 instances of autorun.exe. I wonder which applications I'm going to reinstall frequently. Actually most of the other 97 look pretty reasonable though. It looks like that directory does settle down pretty well after a few months.
Page 1 of 1 (5 items)