I'm currently working on a C# WinForm application, and am trying to create a custom Form to use whenever an uncaught exception is thrown. The reason for this custom form, is to be able to log the details of every thrown exception in a log file, as well as provide the user with a sharp looking GUI with better, and easy to understand details of the error that occurred.
As it stands right now, i am registering for exception events:
Application.ThreadException += new ThreadExceptionEventHandler(ExceptionHandler.OnThreadException);
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(ExceptionHandler.OnUnhandledException);
The ExceptionHandler class logs the error in a log file, and then displays my custom WinForm. My question is, is this the only way to display my custom form? An issue i know of right now, is i am unable to determine whether the application can still continue, or if it will close when the form is closed.
Overall, my question is... Is there a better, or easier way to use my custom exception form? Also, is there a way to know IF the application will be able to recover, once the Exception form is closed?
It's not safe to continue running a program if you don't understand the reason for an exception.
This topic is discussed in more detail here:
http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/631923.aspx
You should start by exiting the application for any error you do not anticipate. The form is a nice touch but beware it may not work, since you do not know what the problem is - so wrap that in a try catch. Then as errors come up do some analysis and if it is something you can recover from than catch that specific exception and recover. Typically though if something bubbles all the way up to AppDomain.CurrentDomain.UnhandledException it is probably something that will leave the app in a bad place and you want to close.
Related
Please note that I'm aware of possible solution and have read some other SO posts which will answer the question how to handle unhandled exceptions globally and I'm not asking if it is good practice or not.
What I'm asking is:
Why do WPF applications close on exceptions?
I always thought that it is the expected behaviour, however when researching how to implement the exception handling globally in WPF, I encountered this sentence on the Microsoft documentation page:
By default, Windows Presentation Foundation catches unhandled exceptions, notifies users of the exception from a dialog box (from which they can report the exception), and automatically shuts down an application.
But my experience is different, the application just exits without any warning, so any unhandled exception will be a total mystery for the user and me as a developer.
My question is really: Am I missing something, or is Microsoft wrong about their own framework?
The docs seems to be wrong.
By default, a WPF application exits without any dialog box when an unhandled exception is thrown on the dispatcher thread.
You may consider to edit the docs and submit a PR on GitHub by clicking on the "Edit" button in the top right corner of the page.
When I am drag picture Box in Windows form it's showing as Object already in use elsewhere.
I searched over Stack overflow and other website says that error is Threads, Coding oriented and GDI+. But I didn't write any coding in that. I just drag the picture box. Then it shows “already in use elsewhere”.
Anyone Explain?
This is usually an indicator that something else, potentially some other thread in your own application, already has the target file that you're trying to save locked at the file system level. If you look at the inner exception I believe it should mention this. If it's not directly in the InnerException Another way to confirm this (or discover what it might really be instead) is to turn on first chance exceptions in the debugger and watch for what exception is being thrown "underneath" Save and then being turned into this generic exception.
A Generic Error occured at GDI+ in asp.net mostly because of missing target folder / access permissions.
I know that the ThreadExceptionDialog is thrown for all exceptions that occur in the program.
My problem is that the dialog form shows assembly information along with the Exception details.
Is there a way to hide the assembly information and show only the exception information?
You can "disable" this behavior completely by calling Application.SetUnhandledExceptionMode() in the Main() method of your application. As far as I know, there isn't a way to hide just the assembly information from the default ThreadExceptionDialog. However, if you set your application to handle ThreadException, you can display your own information. If you don't override it, you get the normal ThreadExceptionDialog and the user may quit or continue. Continuing is not a good outcome 99.99% of the time.
Please review the MSDN document for more information.
My winform application is failing when run outside of the IDE with a dragdrop exception. The error does not occur while being run from inside the ide (VS2008). How can I trace this. I have seen mention of using JIT in the error box that is displayed post error - will this help me trace my problem?
Don't know if this will be helpful, but...awhile ago I was getting DragDropException when my WinForms app was being run on a thumb drive, not a full system. The form generating the error had no drag-and-drop feature. I never figured out the problem, but I saw that a UserControl on that form had defaulted AllowDrop=true unnecessarily. Once I turned that off, the problem went away.
If your form is intended to support drag-and-drop, I'd look into on what thread the form generating the exception is instantiated. My understanding is that Microsoft's implementation of drag-and-drop is COM-based, which must be initialized in an STA thread. Putting the [STAThread] attribute before your program's entry point will accomplish this.
On a Windows 2003 server I have a pure .NET 3.5 C# app (no unmanaged code). It connects to various other remote systems via sockets and acts like a data hub. It runs for 10-15 hours fine with no problem but from time to time it just disappears. If I watch the app using task manager the memory usage remains constant.
In the Main() function I wrap the invocation of the rest of the app in a try .. catch block which it just blows completely past - the catch block which logs the exception to a file is ignored. If I manually raise an exception for testing, the catch block is invoked.
Prior to entering the try .. catch I do :
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
The system has Dr. Watson on it, but nothing gets written in the directory DRWTSN32.EXE is pointing to.
How can I catch whatever exception is causing this?
Try using the debugging tools from microsoft. You can download them from here.
Use adplus to capture the crash and then windbg to analyze it.
adplus -crash -pn your.exe -quiet
Lots of great info about debugging on windows on this blog.
If this is a Windows Forms app, then it's likely that the unhandled exception is being caught by the window message pump, which is why you never see it. To deal with this, see my answer here.
If it's a Windows service, then the exception might be appearing on a background thread and not being marshalled back to your main thread. To deal with this, you need to marshal any background thread back to your main thread, and the exception will be re-thrown there so that you can catch it.
If it's a console app, then I'm a bit mystified.
EDIT: Your comment says this is a Windows Forms app. In that case, you're probably not seeing the exception because it's being handled by the built-in Windows Forms exception handler that does the following by default:
Catches an unhandled managed exception when:
no debugger attached, and
exception occurs during window message processing, and
jitDebugging = false in App.Config.
Shows dialog to user and prevents app termination.
You can disable this behaviour by setting jitDebugging = true in App.Config. Then you should be able to see the unhandled exception by registering for the event Application.ThreadException, e.g. in C#:
Application.ThreadException += new Threading.ThreadExceptionHandler(CatchExceptions);
You could also attach WinDBG at startup and enable breakpoints on .NET exceptions. You can then do a !printexception to see what is going on.
There might be trace of the application in the EventLog.
I have had a .Net app disappear without the possibility to catch an Exception. There was an entry in the EventLog every time this happened.
To view the eventlog just type EventVwr on the command prompt, or run box.
If it's a Windows Forms application, you could try Application.ThreadException.