I'm using VS 2015 Update 2 with an asp.net 5 web project configured for debug mode. When I run the project with F5 to debug it and hit a break point, some variables can not be observed in the watch window even when they are in scope. Further, if I hover over such variables no value is displayed.
If I use the same visual studio to create an empty web project and add a webform and place the code in the load method, the debugger works fine. That is to say, I can see the variables in the watch window and I can see their values by hovering over them. I glean from this that the root cause of the issue is not VS2015 Update 2 but rather something to do with the project or solution configuration, perhaps specific to asp.net 5 web projects.
I've scoured the web for answers and similar problems happen when trying to debug compiler optimized code. But I am running the solution in debug mode. Any suggestions?
I am aware of Variable does not exist in the current context while debugging but it applies to a different version of visual studio and the solutions offered there do not fix my issue.
I had the same problem. Eventually I noticed that some settings are different after update 2.
You need to go to Tools --> Options --> Debugging --> General and then check "Use Managed Compatibility Mode".
That worked for me.
This is a bug that was introduced in Visual Studio 2015 Update 2. Essentially the debugger is unable to inspect local variables in dynamic modules. We released a hotfix for it today. You can download the patch here. Documentation for the patch is here. Let me know if the patch does not fix your particular scenario.
Thanks!
-Patrick Nelson
Related
When I run my Web API application I get the following window:
It just stays like that indefinantly, until I hit cancel.
When I do hit cancel, this error message is shown:
I have tried rebooting, and running iisreset /restart but it does not fix it.
Any ideas what I can do to get my debugger working again?
NOTE: My Web API 2 project's Servers setting is set to Local IIS. My service is hosted by IIS and when I am not debugging, it works fine.
A possible fix:
Check the "Enable Just My Code" in Tools->Options->Debug
I just did a reset for all the settings for VS and it worked again.
Tools => Import and Export Settings => Reset All Settings
good luck!
I had this issue for Visual Studio 2017 and like with the previous post I had Debugging option "Enable .NET Framework source stepping" ticked. Un-ticking fixed the issue.
So as I commented before I had this same issue, but I now figured out the cause and have a solution.
I just got a new machine last week (this issue was actually one of the reasons why) and after a while I had the same issues, not being able to debug my projects. Luckily because I was installing all the updates one by one I was able to pin-point when it started happening.
It seems the latest update for the "Microsoft ASP.NET and Web Tools" extension breaks something.
Sadly, uninstalling or reverting the Web Tools extension is not easy: Remove this extension by going to the Windows control panel and modifying your Visual Studio installation. I had to remove Visual Studio completely and reinstall it (repair didn't do the trick).
You can update and install all your extensions as you wish, just make sure that you don't update the Web Tools extension
I tested this on my old machine and it did the trick there as well.
I've also created an Issue on GitHub as I won't be updating the extension until this is fixed, if anybody has additional information please add it to the Issue.
In Visual Studio 2015, go to Tools -> Options -> Debugging and deselect "Enable .NET Framework source stepping". This may relate to an issue with loading symbols, so if you want to keep the ability to debug .NET Framework source, then it may help to search the web for how to clear the symbol cache, or preload it, or set your symbol server, and so on.
In Visual Studio 2017, I just restarted my machine and ran the solution, no other windows opened not even a browser, although visual studio took a long time to open (30+ projects in a solution) the problem did not reoccur.
I had the same issue in VS 2017 and un-checking 'Native code' did the trick. Not sure why it was checked.
In my case I set Debugging ->Symbols -> To "Load Only Specified Modules" to include the symbols for, in my case a devops symbols feed for some internal NuGet packages
Options>Debugging>Symbols>Load Only Specified Modules
By checking the option "Always load symbols where located next to modules" the setting won't mess with the regular/classic debugging in VS for your own code
This way the Symbols are still loading where needed and Visual Studio is not trying to load debugging information for all the IIS .net dlls that were loaded by w3wp
Alternatively it can also be configured to not load symbols for microsoft.*.dll and it will also work.
Didn't see this in the current answers, so thought I'd give my 2 cents in 2022:
What worked for me:
Make sure to check that your IIS application pool hasn't been stopped (and restart it if it is), and then if that's not the case, restart your IIS server.
If you don't where those settings are, open our Internet Information Services (IIS) Manager, Application Pools are in the left-hand column, and restart/start/stop your server is in the right column.
When debugging an ASP.NET Core application, using Visual Studio 2015, I cannot see the variable, parameters and field values, when, for example, I hover them. I cannot add them to the watch as well. I am running in debug.
We might have found a solution (or at least a workaround) for the problem. If we go into Tools > Options > Debugging and enable Use Managed Compatibility Mode then we can inspect all the values we like.
I hope this solves the issue for you as well.
Update: Visual Studio 2015 Update 2 RC fixed the issue for me, but unfortunately not for the OP.
This behavior happens with 1.0.0-rc1-update1, but not with 1.0.0-rc2-16357.
If possible, upgrade. Microsoft is aware of it.
I have the following problem with design-time debugging in Visual Studio 2010 Pro.
In my solution I have got two libraries. One with name Alfa that contains some of my basic components. Two with name AlfaDesign that it contains designers for components from library Alfa. And of course I have a project for developing and testing Alfa components.
AlfaDesign is having reference to Alfa library. And the test project is having a reference to Alfa and AlfaDesign.
And my problem:
When I put breakpoint in component's constructor from the Alfa library and then I put this component on the form in my testing project, the debbuger is doesn't break. Visual Studio is still running.
I followed instruction from the tutorial Walkthrough: Debugging Custom Windows Forms Controls at Design Time, but without any success.
I ran into this problem today with one of my projects, and I spent the last several hours figuring it out. What I found is that the symbols and modules will not load when your project target framework is set to anything less than .NET 4 when doing an F5 debug. Switching the projects to .NET 4 does fix this weird behavior, but you may not want this for .NET 2 applications that you don't want to use the newer runtimes/BCL.
However, you can still correct this behavior. You can run manually use Debug -> Attach To Process and select devenv.exe and that will load the modules and symbols. So, you can either have a second instance of Visual Studio 2010 already open and simply attach, or you can run it on debug (Run External Program), Detach, and Re-attach to get the modules to load.
I thought this was something wrong with my environment settings, because my install of Visual Studio is very customized, so I thought there might have been some sort of setting, conflict, or file difference, but it seems to just be a weird behavior in the Visual Studio 2010 debugger. I would be curious to see if anyone from the Visual Studio 2010 team could investigate this a bit further.
If the breakpoints are properly resolved, then it must hit properly.
Please check the following.
Is the breakpoint resolved properly or not. If it's properly resolved, it will be displayed in red during debugging sessions. Otherwise the red will turn into a disabled state (with a yellow exclamation mark with a grayed circle).
Why don't you put a breakpoint where the object is being constructed and debug through it? So that you can ensure that your construction code is working well. You can step through (F11) to get inside the constructor.
I have a Visual Studio 2010 solution containing several C# projects, with Resharper 5.1 installed and enabled. All these projects target the .NET Framework 4.
This solution has been working fine for months, but this morning I got the following message when the solution was loaded:
I've looked around for an explanation on the meaning of this message, but with little luck.
Additionally, I haven't been able to repro this error, and it doesn't seem to have broken anything on my project.
Still, I don't like these kind of unexplained errors, so I was wondering if anyone reading this knows the root cause?
Hmm, that's special. It must be a debugger notification, the part of VS that 'attaches' and makes "Managed" a category. The other category is "Unmanaged", a different kind of debugger interface. It clearly lost its marbles there.
Counter-measures, in order, are:
Restart VS.
Reboot
Install Service Pack 1, it has many debugger fixes.
Consider moving 3 up the list if you haven't installed it yet, there are a ton of bug fixes and tweaks and works well.
In Visual Studio 2012 and Windows 8.1, I had this problem,I changed X86 from Solution Properties/Build/Platform target then my problem resolved.
This has been nagging me for a while. Finally I found a solution.
When I press the help button they suggest I sort out the attached debug option. Without any result I finally managed to check the Enable SQL Server Debugging option under Project Properties - Debug.
I have the exact same setting as you: VS2010 with several C# projects pointing to Net 4 and Resharper 5.1. I'm on Windows XP SP3
I was getting the exact same error, along with an empty VS icon in the taskbar.
The empty icon got away when I shifted VS to my main monitor (I have 2) and restarted. It seems that VS doesn't like to be in the second monitor.
As for your error, I cleaned up the Resharper cache (I'm storing it in the TEMP folder, not the solution folder) restarted, and didn't get the error again
In Debug Menu - GoTo Solution Properties and select debug tab and tick the ENABLE SQL SERVER DEBUGGING checkbox
I’m using visual studio 2008 and moles version 0.93. Everything works well except when I try to debug any test that uses a Moled type. The test skips all my breakpoints. And I get the following message in the output window:
Unable to attach. Check for one of the following.
The application you are trying to debug uses a version of the Microsoft .NET Framework that is not supported by the debugger.
The debugger has made an incorrect assumption about the Microsoft .NET Framework version your application is going to use.
The Microsoft .NET Framework version specified by you for debugging is incorrect
Please see the Visual Studio .NET debugger documentation for correctly specifying the Microsoft .NET Framework version your application is going to use for debugging.
If I try debbuger.Break () I get a message: "No symbols are loaded for any call stack frame. The source code cannot be displayed."
I’m in a crunch right now chasing an issue with one our main components and it has been a pain (like I need novocaine) trying to figure anything out without being able to step through the code.
I want to take advantage of mole's "smooth debugging experience". However, I can't seem to get the debugger to attach at all.
Thanks,
Bzz
See the solution to this issue here:
http://social.msdn.microsoft.com/Forums/en/pex/thread/91c08bf4-3260-458c-a221-91f030a75499
I had this problem when I moved a project from Visual Studio 2010 to Visual Studio 2008. Here's what I did to fix it.
Close Visual Studio. Navigate to the Debug/bin location. Delete the following files:
*.vshost.exe
*.vshost.exe.config
*.vshost.exe.manifest
Open the solution. Goto the project Settings. Under the Application Target Framework, select a framework lower than the one you are working with (you'll set it back later). Visual Studio will close and re-open your project automatically. Then set the Target Framework back to the original version you were working with. Rebuild all, and debugging will work properly.