Related
I have just reloaded a project on visual studio (2019) that I was using a few days ago and the watch function in debug mode does not appear to be working anymore. I have normal debug flags (no optimisation and full debug information) and as far as I can remember I have not changed anything from the last time that I used this project (when the watch function was working normally). Apart from this, the code runs normally and without bugs.
When the code hits a breakpoint, although the local variables appear in the locals tab, when trying to view variables in the watch 1 tab, all variables (even those defined locally) appear as identifier "..." is undefined. Hovering over variables has also stopped displaying their value.
I have tried restarting visual studio, clean and rebuild, restarting the PC, opening a different project and creating a new project, but the problem persists for all of these.
Maybe there is a switch that I have changed accidentally since the last time it was working? Thanks in advance!
I managed to fix this by using the visual Studio installer and using the repair option under more->Repair. After the repair and a restart, the issue was solved.
I am getting this message in the Diagnostic Tools window in Visual Studio 2015 when debugging a C# MVC web application.
I've checked solutions to a similar problem: Visual Studio 2015 diagnostics tool does not support current debugging configuration but using administrator mode and disabling "Use Managed Compatibility Mode" do not help. I've also tried disabling Options -> Debugging -> Just-In-Time -> Script, which still has no effect. It's the only reference I can find to 'Script' and I don't know how to change my debug engine.
I've also tried this solution from the web about setting the Visual Studio locale to the same as the OS, but they're both using US English. https://blogs.msdn.microsoft.com/devops/2015/05/06/known-issue-for-diagnostics-tool-window-in-visual-studio-2015-rc-the-diagnostic-tools-failed-unexpectedly/
Can anyone tell me what I'm doing wrong?
My error message is
The diagnostic tools failed unexpectedly. The Diagnostic Hub output in the Output window may contain additional information.
Try to modify the Environment Variable TEMP as following rules and reopen Visual Studio. That works for me, maybe it also works for you. My IDE is Visual Studio Enterprise 2015 Update 3.
It must only one path in TEMP. For example,
Fail:%USERPROFILE%\AppData\Local\Temp;C:\OTHER_PATH
Fail: %USERPROFILE%\AppData\Local\Temp\;C:\OTHER_PATH
Pass: %USERPROFILE%\AppData\Local\Temp
If you create a default MVC web app, and then debug your app, could you use the Diagnostics tool in your side? I test it in my side, it works well using the default settings, my OS and VS all are the English version. So you use the same language version, am I right?
If possible, you could check the following steps:
Reset your VS settings:
Open VS, TOOLS->Import and Export Settings Wizard->Reset all settings->select “No, just reset settings, overwriting my current settings”->Choose a Default Collection of settings(I often use the General or C#).
Please use the latest VS2015 with update 3.
Maybe you could download and install the match VS version as your windows directly, debug it again.
I am working on an SSIS package. The package has a script (C# language) task. I need to debug the script task. I set the break point. The script in script editor (Visual Studio) and the task in SSIS package editor, both, show break point in red color - means the break point is enabled. However, when I debug the package the break point does not hit.
The break point has no conditions on it, so I expect it to hit every time the package runs.
I am using Visual Studio 2008 on Windows 2003 R2 64-bit SP2.
After more research and trial-error, found that the SSIS package ignores the breakpoints in a Script Task when debugging on a 64-bit machine. To fix it -
Go to the Solution Explorer
Right click your SSIS project node > Properties
In Configuration Properties > Debugging > Debug Options > Set Run64BitRunTime to False.
After making this change, the breakpoints hit like magic.
I tried all the answers provided here with no success (using VS2015). After some more searching I found this question that is actually an answer which stated that newer C# features / syntax were causing the debugger to not fire correctly.
In their example (and also mine) using string interpolation was causing the breakpoints to not be hit.
Replacing
$"{someVariable} - {someOtherVariable}"
with
string.Format("{0} - {1}", someVariable, someOtherVariable);
did the trick for me.
EDIT
It appears this issue has now been fixed with SQL Server Integration Services Projects, but you need to be running VS2019 to download it.
Update: Guys, I againg lost any ability to set breakpoints (a request to MS)
My previous fixes are below.
Now I'm using logging and tracing instead of debugging.
C# new features (after C# 4.0) are blamed for killing debugging of the SSIS Script Task.
To return the breakpoint capability I do the following.
Remove C# new features
Run my Script Task once, successfully. I.e. without a crash.
Reopen the Vsta Project from my Script Task and put breakpoints there.
At the end, you have to see a red circle on your Script Task.
(Tested in VS 2017.)
Note. I have to mention that debugging works even if your use "Execute Task" only, not "Execute Package"!
Remove C# new features
To remove the C# new features, I can advise you two ways.
First, restrict Vsta Project properties to C# 4.0 (migrated packages may not support this).
Dobule click your "Script Task" to open "Script Task Editor".
Click "Edit Script..." button to open Visual Studio.
In "Solution Explorer" select the project and click the F4 key on your keyboard.
In opened "Properties" window in "C# Language Level" choise "C# 4.0"
Build your project and fix compilation errors.
Secondly, Vsta Projects in old/migrated packages may not show the above "C# Language Level" property.
So you can put your code in a fake project in Visual Studio 2010 and compile it there.
Run it once successfully
After you fix your C#, you have to run your Script Task once successfully.
You may want to put the return statement at the beginning of the Main() method to prevent any real execution.
Sorry, this doesn't always work and I don't realise why but you definitely need to fix your C# in the first place.
At least you will get a working Script Task and can debug it in an old fashioned way (logs by Dts.Events..., exceptions, etc.)
TL;DR
It looks like I even got severe cases when C# new features forced Script Tasks to fail silently with a success completion status.
As an example, add the following to your Script task.
string Bug { get; } // Only getter properties.
//...
var str = $"Now is {DateTime.Now}"; // String Interpolation in C#
//...
var dummy = val?.ToUpper(); // ?. and ?[] null-conditional Operators
And workarounds for this non-complete list:
string Bug { get; set; }
//...
var str = string.Format("Now is {0}", DateTime.Now);
// etc.
What I also do, I build my C# code in Visual Studio 2010. It simply doesn't compile the new .NET features and do not allows .NET Framework versions above 4.0. So far, so good.
Of course, other answers from this SO-question didn't help me.
In my case, none of these solutions worked. I finally got to know that the Resharper was culprit. After uninstalling it, it started working like charm.
In my case, I had to get rid of all features from C# 6: string interpolation, null conditional operators (?., ?(), ?[]) and expression-bodied members (=>) (there might be more in your case). You can check them all here. Of course, the same applies to C# 7 features.
The 32/64 bit changes from other answers didn't help, so I rolled back those and the debugging kept working just fine.
Use System.Diagnostics.Debugger class to add breakpoint programmatically:
System.Diagnostics.Debugger.Launch();
System.Diagnostics.Debugger.Break();
You can check if the debugger is attached or not:
if (System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Break();
Follow these step:
Keep your project or solution opened.
Run your app to hit breakpoint.
Select your project in Just-In-Time Debugger.
I inherited an SSIS package where unfortunately the above answers didn't help.
In the end I found the script task's build properties for debug mode had had the optimize code ticked. Make sure this isn't ticked because for me visual studio would fire up for script debugging and close shortly after without breaking at all.
Pretty obscure but worth a mention.
We hit the same problem recently. For us the solution was to ensure that the script task project was marked to run as with the platform target set to x86.
Edit the script task
Click on the project and select properties
Select to set the platform target to x86
In addition to Jeff's suggestion, also change the Platform Target to "x86" (In the script's properties' Build tab. This FINALLY got me debugging again on a 64-bit system.
Microsoft released an update v3.2 of SQL Server Integration Services Projects where it resolves the issue with Roslyn and other C# language features introduced after .Net 4.5. C# features.
Bad news - this fix is for Visual Studio 2019 only, you have to upgrade your VS to use it.
I spent whole day on this and NONE of the solutions mentioned here worked for me.
In my case, the existing project was targeted to SQL Server 2016 which defaults ScriptLanguage Microsoft Visual c# 2015. This doesn't allow debugging in VS 2019. I have to target project to SQL Server 2019 to make debugging work. Of course, I am not going to checkin version change. It's only to debug script. Once script is working, I am going to revert target version to SQL server 2016.
Hope this saves time for someone.
I had the same problem as you #PAS. Using VS 2019 and Target server version 2016.
Just found out that if upgrading SSIS in Visual Studio (going into Extensions->Manage Extensions) to latest version (which now is 3.15) debugging is now working.
My breakpoints refused to hit no matter what I did. I ended up debugging and fixing the issues just using exception throws. Once I had fixed the issues I was having, the breakpoints started hitting!
So my breakpoints would only hit once the code did not experience any runtime issues... which is bizarre.
In my experience, it doesn't matter:
if Run64BitRuntime is true or false
if you build the 32 or 64 bits version of your package
But there is something very important, not mentioned in any other answer: you must run the whole package. If you run a Task or a Container the breakpoint will be ignored.
I'm using Visual Studio 2013, on a 64 bits machine.
I only had one Script component were no breakpoints were hit (I was doing some CRM stuff without needing source/target).
I trid to add a Source componenet with a simple fetchXML (even if I didn't needed it).
Then it worked! :-)
I found out that by copying a Script Component task, the VSTA project as a whole is copied as well. This is what you would expect, but what I did not expect is with that, the assembly name for example is also copied.
Running then Execute Task works fine, but running the whole package actually only runs the first script that was copied and resulted in exceptions being thrown before ever hitting the row processing function.
That was also the reason for me that breakpoints were not being hit.
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).
My Visual Studio 2012 installation has unexpectedly started to show the message "Unable to evaluate the expression" everywhere where we watch variables in debug mode.
I already tried to change some debug settings, as proposed by some fixes, but the problem stays there.
Some others fixes recommend us to re-install visual studio, which I wouldn't like to do. What more can we do to fix it ?
A reset in all my visual studio settings using "tools -> import and export settings" (which allow you to save the current settings before reset).
After the reset my debug issue was fixed. Then I imported my saved settings and the problem stays fixed keeping all my original settings.
I had a similar problem and in my case it appeared that several devenv.exe instances were running, which caused the issue.