My vs2010 shows this message when an exception is thrown:
How can I configure the debugger to show exceptions like this instead:
Thanks!
Big difference between the two. You'll only see the first one when you explicitly configure the debugger to stop when an exception is thrown. You do so with Debug + Exceptions, Thrown checkbox. You don't often use this, really only when your code contains too many catch statements that swallow exceptions inappropriately and making the code misbehave. It also has a knack for showing exceptions in code you didn't write. Click the Break button to allow the debugger to show you the details.
You'll only get the second screenshot when an exception is thrown and there is no catch block to catch it, making it an unhandled exception. That's a fatal error, the program cannot continue. The debugger stops to show you the problem, it is otherwise the end of the debugging session. Without a debugger your program will crash. This is the 'good' kind, you get it by omitting try/catch blocks so your program terminates when something unexpected happens. You will want to write an event handler for the AppDomain.CurrentDomain.UnhandledException event so the user at least has an idea what went wrong. And you for that matter.
Related
While debugging in ASP.NET Core w/ VS 2019, when I have break on exceptions turned on 🟢, I break on the throwing, which is what I want 👍, but then I have to continue, F5 through each pop of the stack 🔁.
how do I say "CONTINUE out of this request & let the exception bubble up to the top w/o breaking"? is that an option in VS?
As the ASP.NET Core app is a long-running process, VS has no way of knowing where & when a request starts and ends. You can disable all breakpoints, hit F5, then re-enable them for the next request.
Use the top menu: Debug > Disable All Breakpoints
Use Breakpoints panel
You always can set a hotkey to speed up this workflow
I do believe that what you're seeing is the exception being rethrown on every async stack frame. You could confirm this if the exception dialog says that you can suppress the exception when thrown from System.Private.CoreLib.dll assembly, even though it was originally thrown in your code.
If you disable Just My Code, you should see that the exception is thrown from ExceptionDispatchInfo, which is the type used to rethrow exceptions with their original call stack in async/await. This is also what causes these exceptions to be thrown from System.Private.CoreLib.dll.
The only way I have found to improve this is to not break when the exception is thrown from System, either by using exception filter with module parameter, or in exception dialog > Exception Settings. This is only valid for exceptions that you never encounter from System.Private.CoreLib.dll. I am also not sure how this would work for Just My Code and external libraries as an exception might reach your code only after redispatch from async/await machinery.
With that in mind, you'll often just have to F5 all the way or rely more on breakpoints instead of exceptions for debugging.
Alternatively, as hinted in the other answer, you could disable exceptions until the request completes and re-enable them.
Using UI Automation for some Windows I get the following exceptions on a IUIAutomationElement::FindAll() call using VS2017. First question, what is a wil:ResultException and what does it mean it rethrow at memory address 0? I check the FindAll() result and doesn't seem to have FAILED(hr) because it outputs a debug message if it did and it's not.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: wil::ResultException at memory location 0x000000550AF2BDC0.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
I don't know if it is related or not. I turned on the fairly new "Use Text cursor indicator" as users are telling us our app can crash when it is on. After doing some testing, I was closing the app and got an access violation deep in UIAutomation.dll. The system was just exiting the process. I was trying to duplicate the crash and though I didn't crash, I just saw this same message and the reply to this post that mentioned UIAutomation. The "fairly" new setting is new to me because our IT just allowed the version update that has the setting on our boxes.
The crash occurred while doing a PeekMessage during the exit of the process. We had a static c++ object that was being deleted and during that call, it called the API. I rearranged the code to make the call that used PeekMessage so it happened before the process exited. That avoided that crash. However, we are MFC based and in a debug build, if any code does an ASSERT during shutdown, MFC's assert code does a PeekMessage to remove WM_QUIT before showing the assert message box. So, we can still crash there randomly in our debug builds.
When running with the Text Cursor Indicator on, I see a lot of these "wil" exceptions in the debug output window (release or debug builds). Many seem to occur when a window that has the indicator drawn over it closes. Example - standard file open dialog. I open it, click the path edit box and when I close the dialog, I get some of those exceptions. Turning off the indicator setting avoids all of that and the crashes.
Just installed VS2019 and noticed one uncomfortable thing: in Debug it stops ("falls") at the each exception, even inside try sections. How can I force it to ignore these exceptions, go to catch and work further?
After answer of Perry Qian-MSFT. Now I see this when I have UNHANDLED exception.
Translation: "application is in pause mode". And call stack is empty.
How to force VS2019 ignore exceptions inside “try” section
First, I agree with dixv and thanks for his help.
Current VS IDE can ignore specific exceptions as required.Under Debug-->Windows-->Exception settings
You can record the previous exception's name and search under it and then uncheck it.
Note
After that, please uncheck Just My Code option, otherwise the exception may still be interrupted.
Tools-->Options-->Debugging-->General-->Just My Code
Update 1
If you enable that feature and also want to see the detailed info about that exception without breaking Debugging, you can add these code in catch
try
{
xxxxxxxxxxxxxxx
}
catch (Exception e) {
Debug.WriteLine("=============================");
Debug.WriteLine(e.Message);
Debug.WriteLine(e.Source);
Debug.WriteLine(e.StackTrace);
Debug.WriteLine("=============================");
}
It will show the specific info about that exception in output window:
More info, you can refer to this issue.
Update 2
When you face that situation, you can just click on View Detail of that exception window, it will call Watch Widow and then when you click on StackTrace, it will show the related error file name and related line to you.
Hope it will help you.
Appears, there're two possible ways to... not solve this issue, but at least make it less uncomfortable.
1) Update 2 from Perry Qian-MSFT
2) I enabled Diagnostic Tools while debugging and when exception appears, I just select it in the log of the DiagTools and VS shows me required line.
You probably have the debugger set to break on first chance exceptions, which means it will break when the exception is thrown regardless of any code to catch it. To prevent this behavior, uncheck the respective exception types under Debug / Windows / Exception Settings.
From Manage exceptions with the debugger in Visual Studio:
The debugger can break execution at the point where an exception is thrown, so you may examine the exception before a handler is invoked. [...]
If you select an exception in the Exception Settings window, debugger execution will break wherever the exception is thrown, no matter whether it's handled. Now the exception is called a first chance exception.
I just came across odd behavior with exception handling in .Net. (I'm using C# in MS Visual Studio 2008, but one question I saw here seemed to imply that what I see is true throughout the .Net world.) I am writing a plain WinForm application. I am intentionally causing an unhandled exception to be thrown inside a form_load event handler, outside of any try block. I get no notification. If an unhandled exception occurs in a normal method, a message pops up telling me that the exception happened, and giving me some information about the problem. But in the handler, the code just quietly exits the function without letting anybody know that it happened. If I add a try/catch block, the exception is caught as expected.
Is it true that this behavior happens in all event handlers? And is this expected behavior? And if so, is it because there is too much danger of bad things happening if an event handler unexpectedly stops?
Whether inside or outside VS, this behavior occurs when there is a debugger attached to the process. However, being a debug version makes no difference. If running outside VS without a debugger attached, the unhandled exception will fire up.
You can check
Why the form load can't catch exception? , and
VS2010 does not show unhandled exception message in a WinForms Application on a 64-bit version of Windows , for possible solutions.
EDIT: This behavior is only specific to the form_load event handler, as far as I know.
In my code I had an error that was catched by following exceptions while program was running. However when I was running program in Visual Studio when the error was happening application was simply exiting without any error (other errors usually bring me to the problematic line).
if (ApplicationDeployment.IsNetworkDeployed) {
AppDomain.CurrentDomain.UnhandledException += currentDomainUnhandledException;
Application.ThreadException += applicationThreadException;
}
Of course if i remove the if i get this exception handling done by my methods which simply uses MessageBox to show the error. Is there a way to force Visual Studio to catch this error like it catches other types of errors?
Only by using Debug + Exceptions, Thrown checkbox. That makes the debugger stop on the "first chance". At the point the exception is thrown. You typically want to do this:
if (!System.Diagnostics.Debugger.IsAttached) {
// Subscribe the events
//...
}
Note that this already works that way for Application.ThreadException, Winforms already avoids catching exceptions if it sees a debugger. For the exact same reason.