I just upgraded my VS2013, and the same code has a different behavior in debug mode.
In VS2013, I was having the debug breaking on exception I got.
Some of them that might happens and are handled were put in Try-catch block with a DebuggerStepTrough:
Example:
[DebuggerStepThrough]
private void DoSomething(){
try{
throw new InvalidOperationException();//Obviously in my case, it's not a throw exception here but a method
}catch(InvalidOperationException){
//log something & handling this case
}
}
private void SomeEntryPoint(){
DoSomething();//In VS2015 I got the debug breaking here. In VS2013 I don't
}
I was not having this behavior in VS2013. Is there a way to avoid it?
(I've the "Just My Code" enabled)
You are correct, the behavior you described is a result of a new performance improvement that was introduced in the Visual Studio 2015. The new feature greatly reduces debugging overhead of processing clr exceptions thrown and caught within non-user modules (With Just My Code enabled).
Unfortunately, in an oversight, exceptions thrown and caught within functions with [DebuggerHidden], [DebuggerNonUserCode], and/or [DebuggerStepThrough] attributes are no longer treated as if they were thrown and caught within non-user code - the debugger essentially ignores those attributes with regard to exceptions in Visual Studio 2015 (Step filtering and Call stack filtering still work the same as they did in Visual Studio 2013).
The bad news is that there is no good way to restore the previous version's behavior for this scenario. There are 2 possible options:
Target your application to use .net framework version < 4.0
Refactor your code such that the functions/classes with those debugger attributes are in a different module and build that module optimized and/or without symbols.
The good news is that the Visual Studio debugger team has acknowledged the issue and will provide a workaround in the next update for Visual Studio 2015.
Update
The workaround for this issue is available in Visual Studio 2015 Update 2 and is detailed in the Using the DebuggerNonUserCode Attribute in Visual Studio 2015 blog post.
For those who just want to know what to do. Run the following in a command prompt:
reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1
Related
While doing pair-programming on an React project with Visual Studio Professional 2017, my partner was working on my machine and disabled some debugger option to see less warnings. I want to undo what he did, but he is not available any more, so that's why I am asking here. I remember faintly that he said something about disabling "some breaking".
I am sure it must be somewhere in the options window which appears after Debug > Options and on that popup somewhere under the entry Debugging. I attached a screenshot of Debugging > General. I already tried the toggling the 3rd check-box, but that did not do the trick.
The interesting thing is that in the sub-window Output I used to see all those exceptions logged, but I do not see them anymore.
References
How to turn off warnings while debugging in VS Code?
Enable a single warning in Visual Studio
How to re-enable breaking on unhandled exception in Visual Studio 2012 Express for Web?
I am facing a very, very strange issue in Visual Studio 2015 RTM, while programming a Windows Forms Application.
My Program class, (entry-point-) Main method has a routine that checks if a certain configuration file exists in the current output folder, alerting an error and forcing an Environment.Exit(-1) if otherwise.
I have a UserControl I intend to add to a particular form and... when, in design time, I try to add the built component into it, this happens,
crashing the IDE with it.
Please notice that the message alert was created after a generic exception was caught, back at the entry point (the Log extension method does it).
I'm running a VS2015 RTM version, along with a fresh-from-update Resharper 9.1.3 and PowerTools. This issue has not happened in VS 2013 Premium.
Has anyone here faced something similar?
UPDATE
I just realized how confusing a code in a foreign language can be, so I'll try to explain it the best I can, updating the first image.
UPDATE(2)
It has happened in VS2013 Premium, running a 9.1.2 Resharper and PowerTools. Am I missing something here?
UPDATE(3)
This is not an answer: Catching exception in Main() method
It happens in design time, not in debug mode.
I recently installed visual studio 2013. In VS2013 i've opened a VS2010 solution.
As i wished to debug the application, i've set some breakpoints on code that are always hit. secondly i've included the option to break on exception (so i know exactly where it went wrong).
yet when i run the application (in Debug)
The exception isn't caught. The exception goes through the normal channels of handling without popping up to me.
None of the breakpoints are hit.
The solution had never such problems in VS2010. Another solution (built & created under VS 2013) doesn't give any problems during debugging. With all the exceptions being thrown and all the breakpoints being hit.
What have i done wrong?
What i've tried sofar:
reinstall VS2013
Changed targeted framework
Clean & rebuild
Attached to process
....
Thank you for your time
I noticed that you attached the process, have you manually detemine the type of code to debug ?
Hello I'm getting this exception thrown at me whenever I try to test a web application via visual studio, any ideas why? I'm building a project using MVC3 model and visual studio 2010
Exception: A first chance exception of type 'StructureMap.StructureMapException' occurred in StructureMap.DLL
First chance exceptions might occur while debugging. They might be handled properly by your code and never propagate when running the application normally but nevertheless Visual Studio shows them in Debug mode. If you don't want to be bothered you could disable them in Visual Studio and they will no longer appear.
I have a solution comprising of about 6 projects, and when I debug on one machine, any un-handled exceptions that occur cause the environment to break at the point that exception is thrown, allowing me to debug it.
However, on a different machine with the same solution (in the same version of VS), all I get when an exception is thrown is the "Visual Studio Just-In-Time debugging" window popping up, which tells me the name of the exception, and little else - it offers to open a new visual studio instance in order to debug it, but that doesn't work, because it is already being debugged by the IDE!
What is going on, and how can I get back to visual studio telling me where the exception happened?
Cheers
You might want to check Exceptions in the Debug menu (mapped by default to Ctrl+Alt+E) and verify that both machines have the same exceptions selected.
Probably on the second machine you have less exception types selected in that window. When one of the exceptions that are not selected is thrown:
the debugger does not handle it because it has been instructed not to
the exception gets passes to the OS
the OS launches the default system-wide debugger which is the "Visual Studio Just-In-Time debugging" launcher if you installed VS2005 on that machine.
Sounds like it can't find the debug info.
Try copying the PDB files to your output directory.
I've had this problem as well - two machines, identical exception settings, different behaviours. The solution for me was to set the Debugger Type in the project properties on the "bad" machine to Mixed, even though the application only contains managed code. On the "good" machine exceptions are caught in Visual Studio using the Managed Only setting.