Handling GAC and NGEN Operations after Reboot

Heath Stewart

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.

Heath Stewart Senior Software Engineer, Azure SDK

Follow