I'm currently using a library that throws (and handles) about 5 exceptions when a request to get something fails. Normally this isn't a problem since it's expected this might happen, but the problem is that Visual Studio will log these exceptions anyway.
Is there a way to disable Visual Studio from outputting caught exceptions to the debug console? I still want all other exceptions that would cause a break to be logged.
You can ask Visual Studio to care about the exceptions in your code only, using the Just My Code option.
Go to the "Debug" menu and click on "Options and Settings", and then Enable Just My Code:
This has been discussed on StackOverflow too.
Then, if the methods that are throwing the exception belong to a project that is... your code, you can decorate them with the DebuggerNonUserCode attribute:
which combined with the "Just My Code" option will produce the desired behaviour.
More on the topic here.
Related
I have a Visual Studio App (Windows.Forms) that build a release .exe-App. If I run this exe an exception occurs, I only can see it in the windows log, nothing more happens.
But I would like to see the JIT Exception Window. Can I activate this somehow in VS?
Im asking for a general "If any exception at runtime - show the JIT Debugger"-switch. Is something like this available?
Did it now like here shown.
http://www.csharp-examples.net/catching-unhandled-exceptions/
Instead of logging made an MessageBox with the Exception Message und Application.Exit(). Works exactly as i like it to have.
I want the debugger to stop when:
A handled or unhandled exception occurs.
An unhandled exception occur in a function that has a DebuggerStepThrough or DebuggerHidden attibute. Debugger should stop where this function is being called.
There is no problem so far, I could able to make Visual Studio 2015 work like that. However when an handled exception occurs inside a function that has a DebuggerStepThrough or DebuggerHidden attibute, the debugger stops where this function is being called.
I couldn't find a way to fix this. I don't remember this behavior on Visual Studio 2010 or 2013. I've searched about it, and did not find anybody asking about the same issue.
Edit:
I have tried DebuggerNonUserCode, result is the same. It says "Exception thrown". No it does not!
My settings:
You could use the DebuggerNonUserCode Attribute instead of the DebuggerStepThrough or DebuggerHidden attribute in VS2015 since there are a few small differences between them:
https://blogs.msdn.microsoft.com/visualstudioalm/2016/02/12/using-the-debuggernonusercode-attribute-in-visual-studio-2015/
Update:
I get the same issue as yours using the VS2015. I found that it would be related to on debugging option, please enable the option "Use Managed Compatibility Mode" under TOOLS->Options->Debugging. Debug it again.
The MSDN article Using the DebuggerNonUserCode Attribute in Visual Studio 2015 explains what the DebuggerNonUserCode does and why it doesn't ignore exceptions.
This is caused by a performance improvement in VS 2015
when Just My Code is enabled, the debugger no longer gets notified of exceptions that are thrown and handled outside of “your code”.
This leads to a big performance improvement because:
The debugging performance improved because when Just My Code is enabled, the debugger no longer gets notified of exceptions that are thrown and handled outside of “your code”.
This behaviour can be switched off through a registry key introduced with Update 2:
To enable this, run the following command from your command line that will tweak the registry for you:
reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1
You'll have to experiment and see what is more important, ignoring exceptions or better debugger performance.
I used to be able to edit and continue when an exception occurred in my Visual Studio 2015 C# (WPF if relevant) projects. I often get simple things like null reference exceptions, and I could just quickly fix the issue and continue.
However, recently I've been constantly getting the following warning message:
"The debugger cannot unwind to this frame."
It notes that unwinding is nor possible in the following:
Debugging was started via Just-In-Time debugging. - This isn't the case, I'm debugging by running the "Start debugging" from Visual Studio.
An unwind is in progress - Not that I'm aware of, unless for some reason it's always in progress!
A System.StackOverflowException or System.Threading.TreadAbortException - This happens on all exceptions, including simple ones like Null Reference
My googling comes up with a few articles saying they've implemented this feature in 2006, other than that, only about 3 results come back!
It seems to be project specific. In a clean new project:
Object o = null;
String s = o.ToString();
Throws an exception, and lets me edit and continue the line before. In my existing project I cannot unwind and it throws up the dialog.
Edit: Tried it with a different computer and Visual Studio install and still have the issue.
It seems to be an issue with Caliburn Micro.
If I have a button on my user interface linked to an event in the code behind with the above code, I can rewind and debug. However, If I use cal.message.attach and put the code in the referenced ViewModel's method, then I cannot unwind. But I'm not sure.
You can try and test these solutions one by one.
Unwinding exceptions is unreliable in optimized code. Debug | Options - Check 'Enable Just My Code'
Debug | Options - Check 'Use Managed Compatibility Mode'
Debug | Options - Uncheck 'Enable property evaluation and other implicit function calls'. If that doesn't work, also:
Debug | Options - Check 'Use the legacy C# and VB expression evaluators'
Debug | Windows | Exception Settings - Expand the 'Common Language Runtime Exceptions' dropdown. Make sure your exception is checked.
I have a strange error. I'm debugging an asp.net site and suddenly it stops. Visual Studio stays in debug mode and my web application stays on running just fine. I found this post on, but I don't think a background thread is causing the problem. There's even a try catch around the code where it usually stops debugging, but the catch is not triggered... Everytime I try it, it stops at a different place in the code.
Have you set your debugger to break on all exceptions, not just unhandled exceptions?
Debug -> Exceptions -> Check the "Thrown" box for everything (or at least just Common Language Runtime Exceptions). If an exception is thrown during debugging, on any thread, this should cause the debugger to highlight and break on the "thrower".
Another thing to try, is to reset all your IDE settings. I've had various odd behaviours before where settings got corrupted and the IDE stopped behaving sensibly: Tools -> Import and Export Settings -> Reset All Settings.
In addition to Daniel Dyson's answer - if you "pause" as he suggests (once the debugging has "stopped"), open the "Threads" debug window. Are there any threads showing that have an entry in the "location column". If so, this is probably your code executing. Click on each in turn. Can you account for what each thread is doing, or does this shed any light on this odd behaviour?
Have you tried hitting the Pause || button? This will pause the debugger wherever it is executing, so if you are in an infinite loop outside of your try catch block, you will be able to find out where.
Add a breakpoint in Application_Error Event in the Global.asax.
Check mode in your ide its set to Debug not to Release.
Because cannot able to debug your application if it set to Release mode.
check for detail : http://msdn.microsoft.com/en-us/library/e8z01xdh(VS.80).aspx
Make sure the "Ping Enabled" setting is set to "False" in the IIS configuration.
In IIS7, right-click on your AppPool, choose "Advanced Settings," navigate down to the Ping Enabled setting and change it to false.
If you're using IIS6, the setting is slightly different. I believe it's called "Ping Interval" if I remember correctly and it's set to a number of seconds.
I solved the same problem. I post the solution here, hope it'll help someone in the future.
Here is my condition:
I use Visual Studio 2015 to debug my game on Unity (visual studio tools for unity)
After a few minutes of debugging, the debugging arrow disappear.
What cause it:
I had enabled "Show Threads in Source Code".
Solution:
Disable "Show Threads in Source Code", then restart Visual Studio (and Unity if you're using Unity).
Run debugging to make the button "Show Threads in Source Code" appear.
Disable "Show Threads in Source Code".
Close Visual Studio (and Unity).
Open Visual Studio (and Unity)
This is nearly my first experience with unit testing.
I added a unittest to my solution, and selected Test->Run->All Tests in Solution. My test failed due to an exception which got thrown in the tested code.
Normally, I would then go to the stacktrace toolwindow, click my way through it, looking at the values of locals in every stackframe, and figure out what went wrong. But when code fails within an unittest, I don't get the normal "yellow balloon" exception notification, and I'm not able to explore the stacktrace in detail. All I get is a "TestMethod1 [Results]" tab, which displays only the exception message and a plaintext stacktrace. So, no access to the values of locals, no access to any debug-output I may have printed to the console...
How am I supposed to debug it then?
You need to select "Test->Debug->All tests in solution" then the debugger works as normal.
All the normal debug windows are available by going to "Debug->Windows".
You can install TestDriven.NET, which is a Visual Studio add-in that allows you to do just that - debug your tests. There is a free community version.
You can put a breakpoint in your code, like this:
<TestMethod> _
Public Sub Test() <--- Put breakpoint here.
and then choose to debug the unit test, you can then step through the code.