I've started working on an old project, where WinForms application uses DevExpress controls, for example DataGrid.
The program window contains another multiple windows, and when I'm minimizing some of them, I get an Unhandled Application Exception with Attempted to divide by zero. in details. I want to know what causes this exception, but when I run the project in Debug mode in Visual Studio (2005 version), it does not react in any way to this exception.
Is there a way to find out the reason this exception is thrown?
Enable such exceptions in
Debug -> Exceptions -> Common Language Runtime Exceptions
Also
Also, it is a good idea to turn off the Tools-->Options-->Debugging-->Enable Just My Code option.
Related
I have a set of NUnit tests (running using the Resharper test runner), and some of those fail due to assertion exceptions happening in background threads; and when this happens VS2017 breaks into the debugger, what is undesirable as I want it to keep on running other tests.
All the settings in "Exception Settings/CLR/Thrown" are turned off.
The "User-Unhandled" settings in that dialog aren't present whether I switch the "Just My Code" option on or off
All the "Exception Settings/Managed Debugging Assistants" settings are turned off.
Any other ideas how to prevent it from breaking on those exceptions?
The first thing I'll mention is that assertion exceptions shouldn't be propagating out of your testing framework. If they are, then it could be because of some sneaky code that I can't conceive of. In other words, all assertion exceptions are inherently "handled", because your test framework will handle them for you.
There is also a concept of running vs. debugging a test. If your intention is to simply ignore all exceptions everywhere in your tests, then you should just choose to run - and VS will not attach the debugger at all (and then can't break). I don't know what this difference looks like in resharper's test runner, but in VS it's under the Test > Run and Test > Debug menu respectively.
If you can't re-architect your tests, and you want to be debugging other exceptions (just not assertion exceptions) or you want to hit break points, read the following:
By default, the new debugger (2015+) will break when an exception is un-handled - but you can turn this behaviour off for all exceptions or just a specific one.
Open the exception settings window (Debug > Windows > Exception Settings)
Right click on "Common Language Runtime Exceptions" (or the specific exception you want to change)
In the right click menu click "Continue When Unhandled in User Code".
You should now see a the text "Continue when unhandled in user code" on the right hand side of the window under the "Additional Actions" column and VS should no longer break.
Apparently, this was a bug in Visual Studio. Installing the later updates has fixed it.
I'm using Visual Studio 2008, and working on a winform. Usually, on the event of an unhandled exception, the code will break on the line causing the error. However, it has started simply closing the form. When stepping through the code, it will go straight from the unhandled exception to the form dispose, and close my application.
Have I inadvertently changed an option?
For testing purposes, I created an empty windows form, with only one line:
throw new Exception();
And observed the same behavior. Also, everything is set to break when user-unhandled exceptions arise. I've tried another project without the issue, so it must be project specific.
Go to Menu | Debug | Exceptions... and make sure VS breaks on the proper exceptions.
when i start visual studio 2010 c# .. and open my application i got this. it stopped responding and gives me that message in the picture once my application is opened but other application works fine.
then i debug visual studio 2010 .. and i got the exception
Unhandled exception at 0x76a0b9bc in devenv.exe: 0xE0434352: 0xe0434352.
EDIT: i tried to open the .exe file in project folder in debug folder and i got this.
how to fix that ? what should i do ?
thanks in advance.
Visual Studio is vulnerable to certain exceptions that are raised in design mode. Hard to categorize them, it is an immediate crash to the desktop. The exception code says as much, 0xe0434352 is a low-level managed code exception. You'd normally work around it by checking-in an earlier revision of your control and pay extra attention to code that needs to be disabled at design time by checking the DesignMode property. Your screenshot shows as much, seems like the control is actively displaying runtime info while in design mode. Risky.
If you want to debug it then you can by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one (devenv.exe). Debug + Exceptions, tick the Thrown boxes for CLR exceptions and Win32 exceptions. Switch back to the first instance and load your project.
i've figured out what happened .. my form got 3 usercontrol that i made before.. one of those usercontrol has a customized progressBar which is a library .. for some reason that library stopped working .. so i removed it .. then added again from that usercontrol .. then the application worked.
I have client-server (Silverlight) app.
Some server code throws exceptions that I handle on client. When I debug - Visual Studion breaks on those exceptions and I have to hit "Continue". It really slows down development.
Is there any way to skip specific exceptions or deal with this somehow?
Debug Menu -> Exceptions (Ctrl + Alt + E) -> Find.. type the exception name, then untick the check boxes.
If it's your own exception, you can add it by clicking Add, select Common Language Runtime Exceptions and then putting in the fully qualified name of the exception. Then untick the boxes.
See How to: Correct Run-Time Errors with the Exception Assistant
Basically you can disable checkbox "Enable the exception assistant" under the Visual Studio menu:
-> Debug
-> Options and Settings
-> Debugging
-> General
Also it could be that you've checked specific exception types to be handled so check it under the Visual Studio menu:
-> Debug
-> Exceptions
In visual studio, the Debug menu -> Exceptions. You can check and uncheck exceptions. You can have it break on handled thrown ones, or unhandled ones.
Also, if your exceptions are custom, they won't appear in there by default (only CLR exceptions are there). You can add them using the same window, be sure to use the fully qualified name for the exception (namespace and all)
It happened to me once when i was debugging a code and it will show a Continue button and will never go inside the exception. The error that i was having is like i was creating and instances before the InitializeComponent() was called. I think this can help you to find what you are doing before that.
I have a TextBox in which I validate the input with a third party library. However, this library throws custom exceptions when the syntax is incorrect. This is not a real big deal, except for when you are debugging.
When debugging, since the text in the TextBox will always be initially wrong (I am still typing it), the debugger will stop after each letter until it is correct, which is really annoying as I validate with each letter.
How can I tell the debugger to not break at these custom exceptions?
P.S. I have already tried to filter the Debug -> Exceptions (added it in Common Language Runtime Exceptions), but this did not work for me. The debugger still stops at the line where the library is called.
P.P.S. Using Visual Studio 2010.
Answer:
In the end I was very close with my PS. It was a pretty silly mistake: I had a typo in the namespace. Thanks to Pop Catalin and Madhur Ahuja for pointing it out!
There is an 'exceptions' window in
Visual Studio ... try Ctrl-Alt-E when
debugging and click on the 'Thrown'
checkbox for the exception you want to
stop on
You are looking for reverse of this:
Visual Studio: How to break on handled exceptions?
Assuming you want to break when the exception occurs unexpected you really should hide the method from the debugger using the [System.Diagnostics.DebuggerHidden] method.
Debug + Exceptions, click the Add Button. Set the type to "Common Language Runtime Exceptions" and the Name to the full name of the custom exception, including the namespace name. You can now untick the Thrown box for this one, expand the node first if necessary.
This worked for me: [DebuggerHidden]
This is not a bug in the debugger, it was a intentional change. While
the behavior is different and can be confusing, it had to be changed
in Visual Studio 2010 to support several other scenarios including
Silverlight debugging.
Disable "break on user unhandled exceptions" for the exception types you you are encountering here (via Debug -> Exceptions)
Disable "break on user unhandled exceptions" for all exceptions (via Debug -> Exceptions)
For more details please refer the link here.
Breaking on exceptions in VS2010