Recurring crash: "An unhandled win32 exception occurred in mscorsvw.exe". How to diagnose/fix?

Question

I recently got a new PC at work and had to reinstall development tools, etc. The PC runs Windows XP (blech), and I've got Visual Studio 2010 and .NET Frameworks 2.0, 3.5, and 4.0 installed, each with all current service packs and patches. Windows XP itself is also up-to-date (if one could say that :-)

One recurring problem I've noticed is the following dialog, which tends to pop up after the machine has been idle for a bit:

I suspect the crash is due to the .NET Framework performing Ngen compilation of system assemblies in the background, and crashing when it reaches one assembly in particular.

I've found another mention of this problem at the MSDN forums, and one of the suggested workarounds is to configure Windows XP's Data Execution Prevention feature to "Turn on DEP for essential Windows programs and services only". However, that's already the setting in effect on my PC.

How can I diagnose further? When I try to attach to the process, it's already gone.

Are there any other suggested or likely fixes?

---

UPDATE:

I found some more information on ngen here and here.

I ran the following at a Command Prompt: ngen executequeueditems .. this now lets me reliably reproduce the problem instead of waiting for the idle background ngen to execute.

So, when ngen.exe got to the following entry:

Compiling assembly Microsoft.SqlServer.Management.MultiServerConnection, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 (CLR v2.0.50727) ...
WARNING: Cannot hardbind to mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 because dependency does not have a native image (check FusLogVw for reason)
Failed to generate native code for dependent image Microsoft.SqlServer.Management.MultiServerConnection, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 because of the following error: The remote procedure call failed. (Exception from HRESULT: 0x800706BE)

... the result was the following error dialog:

Whereas, other assemblies that failed native image generation didn't actually cause a crash, just an error message.

So, the specific assembly this is failing on is: Microsoft.SqlServer.Management.MultiServerConnection.

What else can I do? I don't particularly care if it can be ngen'd or not at this point; I simply want to stop this annoying recurring error dialog from above. I already tried:

ngen uninstall Microsoft.SqlServer.Management.MultiServerConnection,

... but it says "ERROR: The specified assembly is not installed."

Is there a way to remove an assembly from the ngen queue, so ngen won't even try to generate a native image for it?

Solution 1

The nGen of the Sql Server assembly is failing because a previous attempt at nGening the .Net Framework 2.0 mscorlib assembly has failed. This is nothing to do with .Net 4 at all so I suggest you stop looking at it's ngen service (2 and 4 use their own services).

As for why that's failed - well there's not a huge amount around on the net about this. I did find this on MSDN forums though - there's something in there about confirming whether mscorlib has been correctly nGen'd - I'd check that out.

Interestingly Sql Server is mentioned on that thread too; although it's 2005 and I think version 10 assemblies you're talking about here are Sql 2008. Still, might provide something.

But ultimately if this were my machine I would:

• Uninstall .Net 2.0 and 3.0 and 3.5 (if you're feeling brave uninstall 4.0 as well)

• Uninstall whatever Sql Server component it is that contains the assembly that's failing the nGen.

• Install the .Net 3.5 sp1 redist; making sure you have also got the hotfix that is referenced for further down the page as well.

• Wait for all the nGening to complete before continuing.

• If you uninstalled .Net 4 reinstall that now too.

• Reinstall the Sql Server component removed in step 2.

Yes, I know, kinda a 'switch it off and on again' answer - but I think it's better than trying to sidestep the issue. If mscorlib 2.0 has not nGen'd correctly then tbh .Net 2.0 is not really usable in its current state. And since this is a SQL Server component that's trying to nGen - only an nGen'd mscorlib v2 will work with it (nGen'd mscorlib v4 will not).

Solution 2

mscorsvw.exe could be seen as a Microsoft program and still profit from DEP, you can check if it is really off with Process Explorer. Either by adding a DEP column or checking the properties of the process.

Visual Studio (at least for me) isn't really handy to debug crashes, you'll better get a dump so we can try to look at the possible causes. You can install the default debugger using drwtsn32.exe -i. Or if you want to learn you could use WinDBG, which allows you to analyze crashed programs in more detail. Though, this is though stuff if you aren't interested in it...

I suspect the crash is due to the .NET Framework performing Ngen compilation of system assemblies in the background, and crashing when it reaches one assembly in particular.

Wouldn't ngen.exe crash instead then? Can you confirm that ngen.exe was running?

You could set up Process Monitor so that it only shows process/thread start/stops so you can see what ran, just leave it running for a while and consult back once you get that debugging window.

Solution 3

"Turn on DEP for essential Windows programs and services only".

Since mscorsvw.exe is a service, this doesn't really affect it.

How can I diagnose further?

Look at the ngen log files. They are probably located in various folders like C:\Windows\Microsoft.NET\Framework\v4.0.30319 or whatever framework versions you have installed.

Solution 4

From What is mscorsvw.exe? how to disable it from running :

Mscorsvw .exe is process related to Microsoft .NET framework. Mscorsvw process is used to precompile .Net framework assemblies in the background.

Mscorsvw.exe process runs only in the background if it needs to compile highest priority assemblies after installing .NET framework redistributable and an application using .NET framework is installed to have its assemblies compiled.

Normally precompiling high priority assemblies will be done by mscorsvw.exe process with in 5 to 10 minutes and then it will try to process low priority assemblies when your Computer is idle.

Disabling or stopping mscorsvw.exe

1. Navigate to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 in Windows Explorer.
2. Open the command prompt by typing cmd in run box and press enter.
3. Now we need to specify the above path in command and now type
   ngen.exe executequeueditems
   and press enter.
4. Now wait for the process to precompile all assemblies, after couple of minutes it will be completed.

Now you observe there will be no mscorsvw.exe process running in task manager.

You can also use this command at anytime to see if there is anything queued up waiting to be executed :

ngen queue status

and also :

ngen display

To clear all queued items do :

ngen /delete *

To find out which assemblies are causing the problem, the log files that may help answer this:

C:\Windows\Microsoft.NET\Framework\<version>\ngen.log
C:\Windows\Microsoft.NET\Framework\<version>\ngen_service.log

On another note, you do not need .NET Frameworks 2.0 and 3.5, as 4.0 is supposed to substitute for all of them.

View more solutions

Comments

[Tamara Wijsman]

What information does the event log provide? Because you could solve this if you knew why "The remote procedure call failed. (Exception from HRESULT: 0x800706BE)". Are there any crash dumps available?

[Chris W. Rea]

I can now reproduce the problem with ngen executequeueditems; please see my update above in the question.

[Chris W. Rea]

Thanks, the log file is helpful. +1. I'm still left with the problem, though now at least I know which assembly is causing ngen to crash.

[Chris W. Rea]

+1 for ngen.exe executequeueditems .. got me to reproduce the problem outside of the idle background context. Then, ngen queue status simply reports "Service name is: clr_optimization_v4.0.30319_32 .. The .NET Runtime Optimization Service is running." It doesn't actually show if there's anything in the queue, but ngen.exe executequeueditems always seems to have work to do.

[harrymc]

You might try to disable the "Microsoft .NET Framework NGEN v4.0.30319_X86" service. This may stop it from compiling in the background.

[Chris W. Rea]

@harrymc A heavy workaround. I'd rather keep the service running, and delete from the queue only the single assembly that's causing the problem.

[harrymc]

I have added some more info.

[sgmoore]

As I understand it, the list of items that should be ngen-ed is stored in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramew‌​ork\v2.0.50727\NGENS‌​ervice\Roots. So it might be possible to remove an entry from there. However, I can't help feeling that avoiding ngen-ing this dll is just going to avoid this error, but you might get an error when you try to use this dll.

[Chris W. Rea]

What I've read is that if an assembly isn't ngen'd, then the CLR will simply execute it via traditional JIT compilation. There will likely be a performance penalty with JIT instead of the native image. But I wouldn't necessarily expect it to crash, if the JIT compilation is different enough from the native image generator.

[sgmoore]

What I mean is, I suspect there may be some corruption with this dll (or something it uses) which is causing ngen to crash and if so, the problem will still remain regardless.

[harrymc]

Also, Microsoft.SqlServer.Management.MultiServerConnection belongs to Transact-SQL. Have you (un)installed any component of SQL Server when this began?

[Chris W. Rea]

+1, accepted, and bounty awarded. Uninstalling and reinstalling both .NET 2.0 and .NET 4.0 as described above appears to have solved the problem. There are no more crashes, no more messages about ngen failures in the event log, and the ngen queue is empty now. Thanks!

[Chris W. Rea]

@harrymc I did install SQL Server 2008 R2. But I think the root cause was a corrupted Framework, insofar as ngen is concerned, anyway. @AndrasZoltan's suggestion worked.

[Andras Zoltan]

@Chris W. Rea - excellent news, happy to help :)

[Chris W. Rea]

p.s. Thanks for the tip about WinDBG; I'm adding this to my list of things I'm ignorant of yet should learn more about. :-)

[harrymc]

Wasn't that solution just a over-elaborate method of doing ngen /delete * ?

[Chris W. Rea]

@harrymc No; I don't think ngen /delete * would have addressed the issue that mscorlib hadn't been ngen'd. That technique might have worked around the crash, but would have left me with a hobbled framework. (Prior to the radical action, I had also tried manually ngen'ing mscorlib but it never 'took'.)

[harrymc]

It is extremely rare for the framework to need reinstallation. Can't be sure, but I believe it never 'took' because the module didn't exist any more after something that happened during the installation when, as I said, ngen should be turned off. This would have been solved by ngen /delete, but we will never know now.