Related
When I debugging in VS2013 update3, msvsmon.exe crashed when hit at a breakpoint.
It shows "The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted".
I'm not using remote debug.
Is it possible to shut down the msvsmon.exe to avoid calling it when debugging ?
Deleting all of the breakpoints solves the problem when I hit this error. Disabling the breakpoints was not enough - they had to be deleted.
I was able to attach to a process numerous times. Once I added a conditional breakpoint (with a few checks), I started getting this error when attempting to attach to that same process.
The error provided in the question is one problem. I also received an error stating that a debugger was already attached when I tried again. Either way, deleting breakpoints solved it.
Try turning on Options > Debugging > General > "Use Managed Compatibility Mode"
I got this error/crash too while debugging and trying to inspect a variable with 50 MB of text data in it. This option worked in both VS2013 and in VS2015 to allow me to debug and inspect the variable with large data.
A couple of things that worked for me:
Try Closing VStudio and relaunching.
If not, reboot helps.[I know thats generic, but its worth a shot]
Disable unnecessary break points.
I had this error also, and I too have Astrill installed. Completely uninstalling Astrill fixed the issue.
I reached out to Astrill support, and they answered (within 2 hours) saying the correct fix is to hold Ctrl and press the "Help" button on the Astrill application, and then choose "Uninstall LSP". This has fixed the issue without needing to un-install Astrill.
I don't know what LSP is, but I presume it's some sort of proxy.
In my case, it was caused by a VPN software. It changed my hosts file and my localhost was not 127.0.0.1 anymore.
So check your localhost in the hosts file (e. g. %WINDIR%\System32\drivers\etc\hosts) and make sure it is 127.0.0.1.
This error just occurred for me with visual studio 2015 RTM. Deleting all the breakpoints resolved the "The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted" condition.
So If you clear all your breakpoints, in your version, you will not need to avoid using MSVSMON.exe.
I was using the OzCode debugger extension. Unfortunately they don't have a way to completely disable the extension - you can only disable certain features - so I had to completely uninstall it to confirm it was what was contributing to the crashes.
I got the same error. No effect after deleting all breakpoints and repairing Visual Studio (I have 2013 Community Edition). The problem was the Bitdefender software. I have Bitdefender Internet Security 2016 and had set Active Thread Control (Modules->Antivirus) to Normal level. But after setting this settings to Permissive the error doesn't show up anymore.
This error occured to me, when I tried to debug with Visual Studio / Service Pack 3, when Service Pack 4 was already released. After updating to the Service Pack 4 I was able to debug.
So, try installing the newest version of Visual Studio
Regards
This (or something that manifests in exactly the same way) is still an issue in VS2017. In my case it was caused by a dependency being too large to debug. The dependency in question was a generated client for a large REST API. I was able to debug again after slimming down that dependency.
Here's yet another answer: I changed my project from "Platform Target: Any CPU" to "Platform Target: x86". Went from needing about 5 attempts to debug to working every single time.
I had previously tried every suggestion in this thread: I reinstalled, I killed all breakpoints, and looked for fishy software interactions.
I started getting this exact error today in my VS2019 project. Attempting to expand/inspect simple data structs in VS debugger would make it freeze for a minute and then I'd get that "The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted" message:
If I add msvsmon.exe process to windows defender exclusions list, then the problem disappears.
I hit this in Visual Studio 2019 (16.4.3) (C++) with a cause that I have not seen mentioned: I had accidentally added a Watch with incorrect syntax that was attempting to instantiate a singleton rather than returning the existing instance.
Repeatedly choosing right click > Clear All in the Watches view while debugging fixed the issue.
Fixed by changing Options->Projects and Solutions->Web Projects -> Use 64bit version of IIS......... to False.
In my case i am using the wcf Service on the wpf application and inputting parameters from here.The Wpf Application Execution on Facing this error "The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted".
That case i am hosing the Wcf service and run the wpf application exe
In this type of Execution on I didn't Facing any Error like -- "The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted"
please,try this proceed error solved because some execution process didn't supporting the debugging..... we are removing the Debuggers on also we face same error.
that case on helped this process.......
I just experience this with VC2017 Community Edition 15.7.2. Turning off the Microsoft Symbol Server lookup while debugging fixed it for me.
I've just had the problem in VS 2015. I hadn't noticed that one of my breakpoints was bogus - I had inadvertently pressed F9 to set a breakpoint when the disassembly window was showing in the previous debugging session. The solution was simply to delete that one bogus breakpoint - I got to keep all my others.
I tried almost every answer in here, but for my case, nothing worked.
Switching to 32-bit just made Visual Studio 2019 crash instead of msvsmon.exe crashing.
What did work for me is to set a very early breakpoint and use that opportunity to close the "Parallel Stacks" window. I didn't need that anyway, but it was open by default in my layout.
In my case, I had this error when I had the "Locals" tab opened during debugging and hitting a breakpoint. For some reason VS might've been unable to display one of the local variables. The error disappeared when switched to a different tab before hitting the breakpoint where the error was occurring.
My problems started after moving a project to a new folder. I wasn't having any luck with any of these answers using VS2019. I even deleted the entire .vs folder thinking maybe something got corrupted. No luck.
But on a whim I tried starting the project with CTRL-F5 instead of just F5 and that actually worked. It's consistent. CTRL-F5 runs fine. F5 gives me the msvsmon.exe error.
I have no idea what's going on, but at least I can get the project to run again.
This problem is at least 1 1/2 years old maybe more. Today is 6-11-22 and I have the problem in Ms Studio Pro 2022 with a fresh install of windows 11 not much of anything else in the computer. Then I uninstalled it and install Ms Studio Community 2022 put in 1 breakpoint at the beginning and I got the error.
Today 6-12-22 I reinstall Ms Studio Community 2022. For some reason I switch from x86 to x64 went through a about 1000 changes of errors and a crashed form1.resx file thank goodness for a backup I had or I'd be done again. anyways so far have several break points with no problems.
I deleted all my watch variables. That fixed the problem for me.
I know it doesn't directly address the error, but as a workaround, I'm using the Rider IDE from JetBrains, and am not encountering the error (code, system, etc. the same).
Visual Studio version: Professional 2017, 15.5.4
Rider version: 2017.3
None of the other answers worked for me, when I encountered this error. If you are not actually remotely debugging, you can use another editor until you figure out the problem or it resolves itself (the latter was the case for me).
Since this morning I keep getting this same message "Visual Studio Remote Debugging Monitor has stopped working" and no matter how many times I restart VS or Windows, that doesn't help. Unfortunately I must use x64 debugging due to third party components. I had no significant changes on the system. From last time everything worked fine.
I've seen this question
VS2008: Unable to start debugging, Remote Debugging Monitor has been closed
and it helped me to understand what is happening but doesn't help me fix the problem...
I am debugging x64 app in local and remote debugger snaps always at the same point of the app start up. The other application still works fine.
Does anyone have some solution for this?
I had a similar debugger issue where details showed that "Fault Module Name" is SYMSRV.dll. So I've fixed that by ticking off "Microsoft Symbol Servers" (Tools->Options->Debugging->Symbols) and cleaning symbols cache.
Sorry, I'm not good at English. I had the same problem. It only happened on my workstation win7 VS2010+SP1. I found that it happened when the program trying to load the assembly "EnterpriseLibrary.ExceptionHandling.Logging.Configuration.Design.dll". Strangely, this assembly references itself! so when the program execution is passing through the statement Assembly.Load("EnterpriseLibrary.ExceptionHandling.Logging.Configuration.Design") in debug mode, the msvsmon.exe crashes with this error message: "visual studio remote debugging monitor has stopped working".
Go to “Start > Run”. Type the following path and hit Enter
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe
I have a very annoying issue with visual studio 2008 sp1 on windows 7 64 bit.
The software we are working on uses a client that connects to a windows service. so, when i do a debug, i debug on 2 processes, the client and the service.
When hitting a breakpoint on the service, and using F10, F11 for 20-30 times aprox, I get an "Visual Studio is busy doing an internal operation ..." message, after which the debugger throws me to another place. If I look at the call stack, there is a message "Evaluation of:". above it, the call stack where I currently am, and below it, there is the call stack where I was before the error occurred.
here is something similar: http://social.msdn.microsoft.com/Forums/en-MY/vsdebug/thread/4c30e3f4-587e-4f14-8cec-8663d268c55c
I tried installing latest updates, cleaning solution, deleting dll files, *ncb, *suo. nothing worked :|
It's not related to the wpf editor bug.
Thanks.
This is barely an answer, but I had the same problem with VS 2008 (updated to KB972221) running on 32-bit Windows XP.
The key seems to be running two instances of VS2008 at the same time.
I had a client/server setup and was running each of these executables via its own VS2008 instance. The server was multi-threaded, the client I think single-threaded.
Like you, I had set a breakpoint and was then F10 stepping through the code when I had the same experience of VS hanging for a while then dumping me elsewhere in the code following an Evaluation of: message in the call stack.
However, I changed to simply running the client executable on its own, with just the server running in debug mode with VS2008, and the problem never recurred (to date!).
So maybe the workaround is simply to stick to a single VS2008 session.
I'm having a problem where VS2010 Ultimate is freezing up every so often for several seconds before returning to normal operation. This happens several times during a session, and is obviously very annoying. I haven't been able to pin it down to any specific activity-- it seems to hang whenever I scroll around in a document, open/create a document, basically anything. Anyone else have this issue or know what might be the cause?
Incompatible add-ons or system configurations can cause Visual Studio issues (performance issue, error, etc).
Fortunately we can try to troubleshoot the issues by referring to the Visual Studio activity log.
Simply run the following command to run Visual Studio 2010 and log its all activities.
DevEnv.exe /log
The log file will be generated to:
XP
%USERPROFILE%\Application Data\Microsoft\Visual Studio\10.0\ActivityLog.xml
Vista & Windows 7
%USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\10.0\ActivityLog.xml
Once you run it, 2 files will be generated: ActivityLog.xml and ActivityLog.xsl
And when you open the ActivityLog.xml, it will contain something like this:
The problem was solved by deleting the user options file called SolutionName.suo.
Somehow it had gotten very big and probably corrupted. You will only lose your breakpoints and open files as far as I know, but rename it to be safe.
I know people have had problems with computers that are older or don't have as much RAM. I know my use of VS 2010 ultimate can run to 500 MB's sometimes and if you don't have enough RAM, then it will hang for a little.
I've had issues with VS2010 when debugging is running or if I'm opening files from a network drive. I'm not sure as I currently don't have any team server repos connected, but if you do maybe the connection to the repo might be an issue as well.
Turns out the issue was network related. One item in my solution was looking to a mapped network drive, which apparently didn't always respond fast enough.
My solution for that problem was beyond the scope of my thinking. I found it on this website, and it goes like:
Launch Internet Explorer. Go to Internet Options, then Advanced tab. Under the Security group, untick “Check for server certificate revocation“. You may need to restart Visual Studio.
My scenario is that I have network drives with references mapped via VPN. That should have to do with that.
I faced similar issue with Visual Studio 2008. I have not thoroughly investigated the issue though.
Reading your post it seems the behavior at your PC is really annoying, but for me it's not that frequent.
One thing I noticed, the frequency at which this happens is dependent on the RAM size and time elapsed since last setup. I came to this conclusion seeing the performance of machines of my colleagues.
I noticed that my anti-virus software tends to lock down my entire system sometimes. If you have an anti-virus application, you might try disabling it for a moment to see if it is the culprit.
I had a similar issue - that still happened after a /resetsettings, reinstall and using /safemode. For me, the issue was that Assembly Binding logging was turned on ago and I forgot to turn it off, it got to the stage where the log files concerned were >200MB and each append was taking ages...
Managed to find the issue with procmon from sysinternals. Suggest that anyone who comes across a similar issue tries procmon if none of the above solutions help.
My VS2010 would hang as well in a similar fashion.
DevEnv.exe /log would indicate it failed to load strings around the time it would hang.
Reinstalling VS2010 SP1 and deinstalling Resharper to install Resharper 7.1.3 solved the problem.
My VS 2008 has a lot of plugins such as Resharper, Syncfusion, Typemock, TestDriven.net and you-name-it. And I am always running all of them on the latest beta versions.
The problem is that this morning the VS 2008 crashed when it was loading Windows Form designers. I think it must be due to Syncfusion ( version 7.2.0.20), or its interaction with other add-ons such as Resharper. Just to be sure, I need to have access to the stack trace before it crashed so that I can get the vendors to fix the problem.
Any idea where the exception trace is logged when VS 2008 crashes, or is there anyway I can obtain the stack trace?
P/S: there is this log switch command in devenv command, but from what I learn, it's only logging the activities, not the stack trace.
If you'd rather not have another instance of VS running in the background, you can use adplus instead. Just attach it to the VS instance you use for dev, and have it create a full dump in case VS crashes. This way, you won't have any overhead while doing your regular work with VS, and in case it crashes you'll have the full context of the crash.
Start another Visual Studio instance, go to Tools -> Attach to a process, and select the instance that should be debugged here. This will give you the ability to break into the debugger when the problematic instance crashes.