I've been messing about a bit to try and get my debugger (VS2010) to allow me to step into the framework source code. (msdn) This didn't work and I ran out of time so changed my settings back, and now I don't get dropped into the debugger when a web project (in debug mode) throws an error, I simply get the yellow screen of death.
What's strange is that I can put a breakpoint in my code which works fine, and I can step over my code but as soon as I hit the line causing the error it drops out of the debugger back to the error in the browser.
I'm sure I've just got a setting wrong somewhere but its incredibly frustrating!
A colleague saved me! This article about Break when exception unhandled had the solution, I had the "Enable just my code" unchecked in Tools > Options > Debugging. No idea how it happened, but fixed now!
Related
I have strange problem here. I am using Visual Studio 2010. When I debug my code using F5, I am getting error. But without debugging (Ctrl+F5) code runs fine. So can anyone tell me what is the problem, what is the difference between both of them and how to overcome the problem?
I guess (cause you are no giving that much details) when you are talking about erros you are probably talking about exceptions right ?
The fact is when you are running your project with CTRL+F5 you are running WITHOUT debugging, and F5 "debugging".
So if you are facing exceptions while "debugging" and not while "not debugging" it seems to mean that those exceptions are properly catched. One way to get rid of those exceptions is to check within the Debug Menu / then Exceptions and to check that all "Thrown" checkboxes are unchecked. This Exception window is there to force debug process to break in case of Exception even if they are properly catched.
Hope this helps.
I'm working on a project in Silverlight and somewhere an exception is thrown. I'm not concerned with fixing the exception... I just want to find it.
Instead of Visual Studio popping up and showing the the line where the exception happened, I instead get a little window labeled "Just In Time" which mentions an error 4004, a managed runtime error. It asks which debugger I want to use to solve the problem. But, it only provides one option: a new instance of Visual Studio. If I try to accept its proposal, the new instance complains that a debugger is already attached.
Why doesn't the instance of VS which built the program and is already running catch the exception and show me where it is?
That is strange behavior. The first thing I would do is change a few settings
Disable Just My Code
Enable native debugging
Break on first exception thrown
This should help you narrow down the place where the exception is occuring.
Disable Just My Code
Tools -> Options
Debugger
Uncheck "Enable Just My Code"
Enable Native Debugging
Right click on the project and select properties
Go to the Debug Tab
Check "Enable Unmanaged Debugging"
Break on first exception thrown
Debug -> Exceptions
Check "Throws" for Common Language Runtime Exceptions
Silverlight has a habbit of swallowing exceptions. I call this "silent failure" and have found it very expensive and frustrating. When working with Silverlight do everything you can do expose exceptions, e.g. binding failures.
Have a look here: http://msdn.microsoft.com/en-us/library/cc189070%28v=vs.95%29.aspx
Also there is a setting on elements to have them visualise binding failures but I forget what it is as I'm not working in Silverlight any more.
Looks like the problem is the type of debugging. In your project properties make sure you enable Silverlight debugging. In your website project right click, go to properties, then on the 'Web' tab at the bottom there's a section called Debuggers. Make sure that Silverlight is selected.
Sometimes the JS debugger is attached to the IE process, which means that there's a debugger attached, but it's simply not the debugger you want. I think this might be the cause of this problem.
Hope this helps.
Miguel
click debug, choose exceptions, mark common language runtime exceptions as thrown.
I had the same problem and it fixed the problem for me
I am working on a C#.NET class library project in VS2010. In my project settings -> debug settings, I have the project set to start an external program (C:\Windows\SysWOW64\wscript.exe) which runs a very simple jscript file (test.js). The script simply creates an instance of the class and calls one of it's methods.
The problem is when I start debugging, VS2010 does not stop at any of my breakpoints. If I open up the exact same project in VS2008 it does stop at the break points. Is there a new setting somewhere that is preventing the breakpoints from being hit? Has anyone else ran into this issue?
My first check would be to disable "Just My Code"
Tools -> Options
Debugger
Uncheck "Enable Just My Code"
Try the scenario again.
To solved this problem by creating a config file for the application which is using the component to debug with the following data:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
With this file you tell the debugger to use the right runtime version for debugging (it seems the debugger uses version 4.0 by default).
I have a tried a whole day to find out why I couldn't debug my visual studio 2012 console application, and the answer was embarrassing.
I was running it in "RELEASE" mode.
Sometimes the obvious is the hard to find.
Close the Visual Studio IDE and Open it. Now it will work. For me it also face the same issue. I used this way to overcome
I had a "Rebuilt" VS2013 project that I couldn't debug (no symbols). Finally, I saw Optimization was checked (Project->Properties->Build). I unchecked it and Rebuilt. Symbols loaded finally. My two cents, only use (compile) Optimization when absolutely necessary.
While I can't answer why it happens, I can provide you with workaround.
Include
using System.Diagnostics;
At the very beginning of your code (Class constructor for instance) place the following lines:
#if (DEBUG)
while(!Debugger.IsAttached);
Debugger.Break();
#endif
Start debugging.
Menu Tools→Attach to Process
Attach to your process.
breakpoint should trigger in your code.
Other breakpoints should trigger as well.
Could be a number of reasons. Usually it's because you're trying to debug against the wrong version.
These actions work about 80% of the time.
Get the latest code
Clean
Rebuild
Restart IIS
Try again
If no good, go to Debug > Windows > Modules and if the relevant dll is there, right click it and load symbols.
If it's not in the list, try running the code anyway. Sometimes even though it says the breakpoint will not be hit, it's only because the dll is not loaded until you enter a scenario that needs it. Try the scenario that depends on the dll, and it may just hit the breakpoint anyway.
Oh one more idea, restart your browser. You might have something cached from an older dll.
If the reason is wrong .NET runtime version (which was my problem), instead of creating configuration file you can simply choose the right version in the Attach to process dialog.
In the dialog, next to Attach to click on Select and switch from Automatically... to Debug these code types where you should check the right version.
If this was your problem also, then you probably had "Symbols not loaded" message on your breakpoints. Immediately after selecting the right version you should see that this error is no longer reported.
For me it was fixed by:
Open the project properties is VS2010
Goto Compile -> Advanced Compile Options
Change 'Generate debug Info' from 'None' to 'Full'
The problem could be your browser is using a cached version of the page, you are working with.
Try to add som nonsense extra querystring in your adress line of the browser f.x. add ?NONSENSE=1234
This forces the browser to use a new version of the web page since it does not know if the page should look different with this Query in the end. Next time use ?NONSENS=1235.
I had a problem with misplaced breakpoints in my native c++ code.
The reason was I had been editing the code so some line ends in the code was not \r\n. It was not possible to see in the code unless you searched for \r\n.
After inserting the proper line ends \r\n the debugger worked.
I encountered the similar issue but its in a CLR project. I had some old c++ syntax in the CLR project. For me after I enabled 'Use managed compatibility mode' in Tools>options>Debugging>General it started to hit the break points.
The answer to this has got to be simple, but I sure don't see it.
I'm working on an MVC2 project under VS2010, with Unit tests written in NUnit.
I debug the tests (and code) by starting the NUnit GUI, then clicking Debug -> Attach To Process in VS, and attaching to nunit-agent.
This has all worked fine for some time.
I added one additional test for a bug that I discovered this morning, and suddenly, my breakpoints are not being hit. NUnit just runs merrily along and says the test passes (which it shouldn't, since I haven't fixed the bug yet), without ever stopping at the breakpoint I have set on the very first executable line in the test method.
I've looked at everything I can think of, including rebooting the machine, and I can't figure out what has changed. (FWIW, the test project is configured to run under .NET 3.5, and I'm running NUnit 2.5.4. I have added the 4.0 "supportedRuntime" flag and "loadFromRemoteResources" flag to the section of nunit.exe.config, and I have also tried attaching to nunit.exe instead of nunit-agent.exe. Note that I am NOT getting the disabled breakpoint buttons with the "source code cannot be loaded" messages. The breakpoints are the standard red ball, they just never get hit.)
The answer was indeed simple.
Somewhere along the line, I had been using VS2010 to debug Script code by attaching to the browser. When you attach to a process in the debugger, you have to tell it what kind of code you are debugging, and debugging script code is incompatible with debugging managed code, so it turns off Managed code. Apparently VS remembers your last selection.
So when I attempted to attach to N-Unit, it was selecting Script as the type of code that I wanted to debug, and I didn't notice. All I had to do was select the drop down box in the "Attach to process" dialog box, and check managed code.
Thanks to Paul Laudeman in his CodeBetter Blog
Try attaching to the nunit-agent.exe process. That worked for me.
Maybe a silly question but one day I did something accidentally in VS2008 and ever since then, whenever I hit F5, just before my app appears, I see a quick flash of a small window labeled "Object Test Bench". ie, it appears and very quickly disappears.
I've read about Object Test Bench and (since this happened) had a quick play with it in View / Other Windows but I haven't been able to stop that quick flash.
It's not really a problem, VS seems to work fine but I'm always uncomfortable about something happening that I don't understand and didn't happen before.
I also have the same problem. I once had JetBrain's Resharper 4.5 installed. I uninstalled it after my trial expired, and I think that's when I noticed the Object Test Bench popping up when I debug.
Did either/both of you have Resharper or any other Visual Studio add-on installed/uninstalled before this problem?
UPDATE
Try resetting the Visual Studio settings. How to: Reset Your Settings
After resetting, the object test bench popup went away.
If you would rather not lose all of your settings:
export your current settings
reset all settings
import selected settings from your exported back-up settings. Keep everything else, but de-select 'window layouts'