RavenDB throws tons of handled and expected exceptions internally. I have Enable Just My Code checked. I've tried clearing my symbol cache, but if I have Debug > Exceptions > Common Language Runtime Exceptions > Thrown checked, Visual Studio still breaks on these internal RavenDB exceptions.
Why does Visual Studio think RavenDB qualifies as "Just My Code"?
Related
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
I'm using Web Api and when an exception happens in my code (for example a bad cast), and the debugger is attached, the exception is not thrown in Visual Studio. I just get the 500 internal server error on the browser side with the exception details but it's a pain because I have to track down what line it's thrown on.
I don't believe this was always the case, and thought it must be one of my settings messed up but I have already tried to reset visual studio settings to no avail.
How can I get the debugger to break again on 500 internal server errors.. I don't want to enable first chance exceptions.
Tools -> Options -> Debugging -> General, Ensure that "Enable Just My Code" is checked.
In visual studio Debug->Exceptions for exceptions that you need or for all of them select checkbox in the Throw column. It's because by default Asp.Net runtime handles all exceptions. MSDN
There's a really weird bug in my app (C#, WPF based UI): in a certain scenario, if I unpin the explorer, I'm getting tons of exceptions (System.NullReferenceException – Object reference not set to an instance of an object).
The problem is: I can't find the specific reason for this exception because Visual Studio stops debugging (so there is no stacktrace, and no evidence for the exception).
I tried changing the exception handling settings in VS to throw any exception instead of handling it, but it didn't help.
How can I find the exact location which threw the exception?
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.