When launching from VS: Error "Ignoring managed exception from unknown thread"
-
Monday, May 02, 2011 2:13 PM
Hi!
After a malware infection, I can no longer launch projects that use version 2 of System.dll. It occurs in both VS 2008 and 2010.
Process is terminated due to StackOverflowException. Ignoring managed exception from unknown thread.The program '[3504] WindowsFormsApplication1.exe: Managed (v2.0.50727)' has exited with code -2147023895 (0x800703e9).
The error occurs only when launching from within Visual Studio, my applications work when I launch them manually. Not a single line of my code is executed. The error occurs even when I create a new empty Windows Forms application.
Obviously, there is something wrong with my machine (note the Malware infection I had). However, I hope there is a solution for this :)
I already tried re-installing .NET Framework and VS.
All Replies
-
Monday, May 02, 2011 4:43 PMModerator
What does the callstack say? Go to Debug\Exceptions and tell VS to throw the exception when it is raised rather than ignoring it and you'll get a better idea of what is going on. If it occurs for any WinForm app then it is a system-level problem which might require that you reinstall VS, .NET and the SPs. Repair might not work in this case.
Michael Taylor - 5/2/2011
http://msmvps.com/blogs/p3net -
Monday, May 02, 2011 5:38 PM
Thanks Michael!
Unfortunately, the call stack doesn't say anything. If I check "Thrown" for all Exceptions, the debugger still doesn't break.
When vshost is enabled, it doesn't even say "Process is terminated due to StackOverflowException.".
It occurs for any app that uses version 2 of System.dll (which is apparently used when targetting Framework 2.0, 3.0 and 3.5). However, the error only occurs when launching from within visual studio. Otherwise, everything works.
-
Monday, May 02, 2011 5:41 PMModerator
What process is actually throwing an exception - your app or vshost? If you disable vshost what happens?
Michael Taylor - 5/2/2011
http://msmvps.com/blogs/p3net -
Monday, May 02, 2011 5:43 PM
If I disable vshost, I get the exact error message I posted above. If I enable vshost, the first line is missing ("StackOverflowexception").
So disabling vshost doesn't solve it, it only produces a slightly different message.
-
Monday, May 02, 2011 5:46 PMModerator
Sounds like a .NET framework corruption issue. In VS2010 is the exception the same? If you switch to v4 does the problem go away. Back to the exception you're getting. When VS throws up the dialog is there an inner exception available? The call stack is empty? Do you have Just My Code enabled?
An alternative to try and diagnose this is to start up VS and then attach another instance to it for debugging. Then run your app in the debuggee to see if the debugger will catch the exception.
Michael Taylor - 5/2/2011
http://msmvps.com/blogs/p3net -
Monday, May 02, 2011 6:13 PM
Yes, the exception is the same in VS2010. VS does not throw any exception dialog, it just displays the message in the output window. Nothing else can be seen on the screen.
The message goes away if I switch to .NET Framework 4.0 and replace the System.dll v2 by System.dll v4.
I tried attaching mdbg.exe to visual studio, it didn't work:
mdbg> run "c:\program files\microsoft visual studio 9.0\common7\ide\VCSExpress.exe"
Could not detect debuggee version -- using latest debugger API.
STOP: Process Exited
(visual studio crashed immediately after being launched with the debugger). I also can't attach Visual Studio to itself because I'm using the Express Edition.
Thanks for your patience!
-
Monday, May 02, 2011 6:35 PMModerator
Given that it only impacts v2 I'm leaning toward a corrupt framework. You could try installing WinDbg and then debug VS through that. If that doesn't work then I think you're at the point where a clean reinstall of .NET and VS would be appropriate. As one final approach though you could start VS using /safemode and reset your settings but I don't think either of these will resolve your issue.
Michael Taylor - 5/2/2011
http://msmvps.com/blogs/p3net -
Tuesday, May 03, 2011 6:14 PM
Hi Guys:
I'm having the same issue on the VB side of VS 2008. I was also the victim of a malware attack last week - specifically this one.
The immediate windows shows this on pressing F5:
"Ignoring managed exception from unknown thread."
If I go to the project properties > Debug and check "Enable unmanaged code debugging", then I can run the project in VS. However, performance is poorer and I can't use edit-and-continue, so it's not really a viable workaround.
I uninstalled & re-installed VS 2008 and SP1, and no dice.
Did not try to uninstall/re-install the framework, though.
I'd be interested in hearing about any solution.
Thanks,
--Dave O
-
Tuesday, May 03, 2011 6:26 PMModerator
Performance and EnC shouldn't be impacted by the option you specified. Given the malware description I don't see why VS would be impacted at all unless the malware hasn't been completely removed. It's possible that there is a legacy registry key or something getting in the way. A couple of tests you can do are:
1) Use AutoRuns to ensure your machine has no extra software running or configured.
2) Create a new user account, log in and try creating and running a project in VS. If it works then your user account is still dirty.
Michael Taylor - 5/3/2011
http://msmvps.com/blogs/p3net -
Tuesday, May 03, 2011 8:03 PM
The performance thing may just be paranoia on my part, but I do get a messagebox when I try to edit something after a breakpoint is hit. Message text is "Changes are not allowed when unmanaged debugging is enabled."
EDIT:Already tried creating a new user account. No Joy.
I didn't see anything strange in AutoRuns.
I'll give the uninstall/re-install another go, this time including the framework.
Thanks for your help,
--Dave O
-
Wednesday, May 04, 2011 9:37 AM
Ok, I tried re-installing VS and .NET Framework, but that didn't help.
I ended up re-installing Windows 7, that solved it ;-)
-
Wednesday, May 04, 2011 1:36 PMModerator
Ouch!! I guess there's no need to get on a soapbox about running with admin privileges anymore (based upon the malware description you'd have to be an admin to get it). You've learned a valuable less. VS runs really well as a normal user. I've been running as a non-admin since XP with very few issues. Given Win7's UAC functionality it is really seamless these days.
Michael Taylor - 5/4/2011
http://msmvps.com/blogs/p3net- Marked As Answer by Aspen VJ Wednesday, May 11, 2011 1:02 AM
-
Saturday, May 21, 2011 11:23 AMUnfortunately I have been hit with exactly the same problem yesterday. It began by a crash of Skype, then after a few seconds - BSOD. After a reboot, Windows Security program, which appeared to be malware, popped up. It then disabled task manager and removed a bunch of shortcuts on the desktop and start menu. Luckily I was able to quickly kill it with Process Explorer, and did a Windows restore to a few days old restore point. Have no idea where the malware came from, as I don't remember running any suspicious programs.
Anyway - system restore got everything back except now I can't debug any .NET Framework 2.0 (and 3.5) applications in C# and also in VB.NET. The only other thing is a Skype crash at startup. Apart from that - I can not see anything else wrong with my system. I wonder what that malware could have changed to affect debugging of .NET applications?
Because nobody has a solution for that, I will probably have to do a system repair. -
Monday, May 30, 2011 10:02 AMLooks like I managed to resolve the issue. My \system32\drivers\volsnap.sys was infected with TDSS rootkit. After replacing the file with a good one from another computer using recovery console, both problems are gone. I can debug .NET applications again and even Skype does not crash at startup anymore.
-
Thursday, May 17, 2012 8:03 PM
-
Thursday, May 31, 2012 6:54 PM
turning on "Enable unmanaged debugging" in debug properties of the project solved the issue, but made the debugging real slow. Upon further investigation, found out that, I had a crash rule setup for the process I was trying to debug in Visual Studio in the DebugDiag tool and that's what is preventing Visual Studio from being able to attach its own debugger. Removing the crash rule in debugdiag resolved the issue for me. I wish Visual Studio put out a bit more descriptive error message
- Proposed As Answer by Vijay Nara Thursday, May 31, 2012 6:54 PM

