Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 

Sign in to follow this  

slow logon bug caused by .NET Framework NGEN - how to fix?

Recommended Posts

Exdit: duplicat thread:

Is anyone familiar with this bug and if so, what causes it?

The bug occurs when one installs .NET framework 4.0 on (even on full XP SP3). Apps at log on are delayed for 2minutes on the first reboot after installing 4.0 and occurs everyboot thereafter until 4.0 is otherwise uninstalled).

In a pre-made image of XP, available on the web, there is described a feature called "F4SBF Patch v2.0" which supposedly fixes this.


F4SBF Patch v2.0: Fixes the Windows XP slow boot bug which is caused by the “Microsoft .NET Framework NGEN v4.0.30319″ Service.

I don't want to link to the page due to forum policy.

I'm curious what this update entails.



Edited by shorterxp

Share this post

Link to post
Share on other sites

Update: I managed to track down the patch, here is the code that supposedly fixes the bug. (save as .vbs and run it)

' This Script fixes the Windows XP slow boot bug which is caused by the "Microsoft .NET Framework NGEN v4.0.30319" Service.
' This Script will checks if the "Microsoft .NET Framework NGEN v4.0.30319" Service is "Running" and if it is then the Script will try to set the "Startup type" for this Service to "Disabled".
' Disabling the "Microsoft .NET Framework NGEN v4.0.30319" Service will not cause any problems with the programs that are run on Microsoft .NET Framework v4.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServiceList = objWMIService.ExecQuery _
    ("Select * from Win32_Service where Name = 'clr_optimization_v4.0.30319_32'")

For Each objService in colServiceList
    If objService.State = "Running" Then
        errReturnCode = objService.ChangeStartMode("Disabled")
    End If

It works! If that doesn't work theres:

' [ MS .NET Framework 4 - WinXP Slow Boot Fix v3.1 ]
' This Script will fix silently in the background a Microsoft .NET Framework 4 bug that causes a slow Windows XP boot up.
' This Microsoft .NET Framework 4 bug can occur, for example when reinstall Microsoft .NET Framework 4 or when installing new Microsoft .NET Framework 4 Updates.

Set objShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")

ExeFile = objShell.ExpandEnvironmentStrings("%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\ngen.exe")
  If (objFSO.FileExists(ExeFile)) Then
    objShell.Run Chr(34) & ExeFile & Chr(34) & "eqi", 0, false
  End If



The fact NGEN halts the logon process upward of 90seconds is rediculous.

What is NGEN? When you install .net framework, uncompiled or raw libraries aka native images, that programs built using .net depend on, are moved from .net installer to target hard drive. However these libraries cannnot be read in their raw state, they first have to be compiled. With older .net installations,compile was done during initial .net installation which now explains why these sometimes took a long time.  Instead .net distros (as of 2,0?) install a background service alongside the libs - the service becomes active when the computer is idle, supposedly compiles the libs, which when finished are used with .net based apps.

Native images or raw libs supposedly simplifies software development at the burden of we, the clients (thanks lazy developers). It excels in scenarios where software is deployed en masse and enables compatilty across varying architecures i.e. intel/amd, x86/x64 (32 and 64bit) or ARM. That is, when the raw libraries are unpacked by end-user via .net installer, they are compiled to reflect the architecture of the system on which it is installed.

I assume that the aim is/was to save dev time and simplifiy software deployment; it eliminates need for multiple itterations of software otherwise needed to work on systems of varying architecture.

If the NGEN (£%$!@) service is disabled and an app (developed with .net and this depends on the ,net libraries), is exectued this - ***supposedly*** -  hinders app start up time (warm start vs cold start) though I've never experienced this personally and I've used net apps for almost two decades - so I call BS on that.

Edited by shorterxp

Share this post

Link to post
Share on other sites

Bumping this thread because I think it would prove to be an interesting topic. Why would NGEN background service halt logon for 90s?

I'v used XP for over 15years, installed .net countless times and never had I noticed this issue of prolonged logon times, until last year. According to antedotes on other forums, this is common, even on factory image of XP pro; so it its not just me.

It may be deliberate act of planned obsolecene, hardcoded into XP (a countdown timer thats since elapsed?).
I doubt switching from Intel x86 based system to an AMD x86 system led to this.

Any thoughts?

Edited by shorterxp

Share this post

Link to post
Share on other sites

%windir%\Microsoft.NET\Framework\ngen executequeueditems supposedly compiles these libraries / native images in one go, usually taking a few minutes but after that slow boot never happens again.


Of course ones can still sue the .vbs script in post #2.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...