There is a fix for that. See: http://support.microsoft.com/kb/922918
The thing is, a service might require ldap or another remote access an is experiencing delays because of this. This can especially happen when the server is starting. By extending the delay you can ensure the service will start.
Better would of course be to troubleshoot why this service takes so long to start. Is your environment unersized? Have you got performance issues on a service that is being polled by the service being delayed to start?
This may be due to how .NET locates assemblies, documented here:
How the .NET Runtime Locates Assemblies
http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx
Note the following:
"The compiler records static references in the assembly manifest's metadata at build time. Dynamic references are constructed on the fly as a result of calling various methods, such as System.Reflection.Assembly.Load."
If your reference is static, you may examine the executing assembly's metadata for the manifest. The manifest may be examined using ILDASM or some other tool such as ILSpy. If it is dynamic, the location process is complex and sophisticated.
My experience has been that if multiple CLR versions exist (e.g., both 2.0 and 4.0), the result may be unexpected. There are several additional factors, such as:
- machine configuration and application configuration;
- if the application is all managed code, or has some unmanaged code (COM/Interop);
- if the executing/calling assembly and called assemblies are platform independent ("any cpu"), or platform-specific (x86 or x64).
It is also possible to run both 2.0 and 4.0 CLR code in a process at the same time (side-by-side execution).
I would think that this should be reproducible in a development environment, and it is unrealistic to expect the consumer to know or deal with all possible scenarios.
.NET In-Process Side-by-Side Execution
http://msdn.microsoft.com/en-us/library/ee518876%28VS.100%29.aspx
Assemblies: locating, binding and deploying
http://www.codeproject.com/KB/install/assemblydeployment.aspx
When you run Microsoft SysInternals' Process Explorer, select the service process, and the .NET Assemblies tab, it should show you all of the various loaded assemblies so you can validate that the correct file is loaded:
Best Answer
We have experienced this situation with every version of the .Net framework ever installed - it turns out the NGEN service is the Native image GENerator, not Next Gen or something else I thought it was for a while.
At any rate, what is happening is quite annoying, but it is not suspicious nor is it malware, a bug, or harming your computer. The logs you posted indicate that the service is PRE compiling the .Net framework and it shuts down the service as soon as it's done. However, as an experienced C, C++, C#, Objective-C, etc. developer for 20+ years...I'm not sure why Microsoft has it install with an "automatic" startup type. Additionally, I'm not sure why the compilation needs to ever run more than once (except should a patch come out or something). But, I'm not privy to those answers...so, I'll stick to only advice about what I have found helps!
This issue also causes numerous problems in Server Manager on 2012+ servers where it throws up a red warning that a service set to start automatically is stopped.
That way, Windows Service Manager will start it when necessary but it will not attempt to needlessly start (and then stop) all the time. This should alleviate some of the log-spew for you. It has completely eliminated the warning about the services not running for us on over 100 Windows Servers and 200 Client Workstations. HOWEVER, please do not perform this change unless you are doing so on a non-production computer or are certain it will not have any adverse effects.
Even though we haven't experienced any problems with this workaround, it doesn't mean that problems do not exist - so just be careful when changing it!
Hope this helps!