When debugging a 64-bits process with RyuJIT enabled Windows Freezes and Crash

[redknightlois]

Last couple of days I had been a very bad time dealing with debugging a project. The debugger would crash msvcmon.exe and Windows will stop responding (even Ctrl-Alt-Del wont work). After disabling RyuJIT everything came back to normal.

[jkotas]

cc @cmckinsey @CarolEidt

[mmitche]

@redknightlois Is this against CoreCLR or the Desktop CLR? If it's against Desktop, can you file an issue on Connect so we can take a look? http://connect.microsoft.com/VisualStudio. Please include detailed steps to reproduce the problem.

[redknightlois]

@mmitche DesktopCLR which is sad, because Connect is where bugs are sent to rot and be forgotten.

There are not many more instructions as:

• Process running on fumes memory wise (the process being debugged uses a lot of memory)
• Debugger breaks.
• You just do your usual debugging things (step in-out etc)
• Eventually the whole computer stops responding
• A message box I have never seen before tells me that an operation has been waiting for too long, with 2 options (end process and/or keep waiting).
• No matter which one I select, the whole desktop crash (explorer) and a msvcmon.exe also appear. And not even Ctrl-Alt-Del will be able to show the options. Sometimes it comes back after a minute or two, but most times I ended up hard rebooting (which happens instantly).

Important to note: I had VS2015 installed one of the latest RC5 and then the RTM (since release). This started happening a few days ago, probably related to some clr update. Disabling RyuJIT makes the problem disapear (havent seen it again).

Environment: Windows 8.1 (patched up to today)
Installed: Visual Studio 2010, 2012, 2013, 2015

[mmitche]

@redknightlois Luckily, connect gets routed to developers fairly quickly these days :) Is your process that is running on fumes 64-bit or 32-bit?

[CarolEidt]

@redknightlois Have you taken a look at the RyuJIT troubleshooting tips here: https://github.com/Microsoft/dotnet/blob/master/docs/testing-with-ryujit.md?

[redknightlois]

@mmitche 64-bits
@CarolEidt From that document is where I got how to disable RyuJIT to try if it had anything to do with the issue I had or it was something else.

[CarolEidt]

@redknightlois If I understand the above correctly, this problem did not start occurring immediately after installing VS2015 and .NET 4.6, but some time later? If so, it might be useful to understand what may have changed - can you correlate with any updates or changes that happened?

[redknightlois]

@CarolEidt I have it installed since release, but I havent worked with that project for a while. I remember having done something along the time I installed it (without trouble), so any update that may have happen in between could be the culprit. I have it setup to automatically update whenever an update is available, so you can assume an up-to-date machine. Sadly as I cannot recover from the issue it is hardly difficult I would be able to get more data.

However, I can try to repro it enabling RyuJIT if you have any way to acquire relevant information.

[Furynation]

I am also having the same issue. At first, I thought it was related to a continuous testing tool I used (called NCrunch); so I filed a bug report with them, I captured a minidump which can be found here: http://forum.ncrunch.net/yaf_postst1622_Unable-to-Debug-tests-in-Visual-Studio-2015.aspx

It crashes with this message: The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted. This doesn't freeze Windows for me, only Visual Studio until the message box pops.

I have been able to reproduce it in a 2nd scenario repeatedly as well. I'm not sure if it will repro if I package it up. Bug just filed over at Connect: https://connect.microsoft.com/VisualStudio/feedback/details/1650051/msvsmon-exe-crashing-randomly

[redknightlois]

@Furynation Glad I am not the only one to have this issue and that you were able to get a minidump for it.

[mmitche]

@Furynation thanks!

[Furynation]

@mmitche No problem! I hope there's enough info. in the dump to help resolve the issue.

[mmitche]

@Furynation @redknightlois Looking at the dump now