I have a WinForm application, with some dependencies on an external library that can on occasion cause an exception outside of the running threads context. As it stands now, this is completely OK behavior ( well, except of course the exception ) and we wired up AppDomain.CurrentDomain.UnhandledException to simply restart the program.
The only problem is, the [Your Program] has stopped working like the one below, appears:
alt text http://telcontar.net/store/archive/CrashGallery/images/crash/vista/2007-05-30%20Microsoft%20Register%20Server.png
Is there a way to prevent this dialog from appearing at all, be it in the AppDomain unhandled exception handler or in a config setting, as no end users are going to be reading it and it just holds up resources until it is clicked.
Avoid the WER dialog by preventing your UnhandledException event handler from exiting. Call Environment.Exit() to terminate your app.
Related
I am binding images to URLs. If the image does not exist, is just now shown, and I see a System.Net.WebException thrown into the output window. That's what I need, if not there, don't show, but my question is: are these unhandled exceptions going to create any other issues? (performance,etc)
Good question.
Actually there is no issue if you don't catch an exception, if you're sure that it won't cause the application to crash.
Normally the flow of the application is affected by exceptions and chances are there to get the application crashed. So it's the normal process to catch exceptions and handle them. You could either show a message or some default image in a case where there is no exception.
Also try below code for handling unhandled exceptions.
AppDomain.CurrentDomain.UnhandledException
+= new UnhandledExceptionEventHandler(ErrorHandler.HandleException);
(see update below)
While running within the VisualStudio 2010 environment, I can easily tell if my Winform application causes an exception. I just have to go to Debug | Exceptions and make sure that both columns of checkboxes are checked. I then run the application and if any exceptions then I get dropped straight into the offending piece of code.
How do I determine exceptions during testing, when I give test build to a tester. I do not want the tester to run within Visual Studio, just as a regular user. I still want to know if there are exceptions and the pertinent details.
Obviosualy, I should be able to control the process, so that when the code gets released normal execution happens.
Yes, I know about and use try/catch blocks, but I am talking about a method similar to Visual Studio exception catcher and reporter, just possibly compiled into the product and used for deployment to beta testers.
Maybe Visual Studio has such a feature, in which case where and how to set up, or possibly a third party component.
[Update:
I added two sub-questions, which you can find at Unhandled Exception next line or exit.
The solution mentioned below sounds great and with a tweak probably works, just not at the moment.
Inside the Visual Studio both 2010 and now 2012 works great. The exception handler gets called, okay after VS breaks at the line and I say to continue. I decided to test outside the VS2012 IDE, good thing for that. The OS traps the bug, shows the standard an "An Unhandled Exception Occurred" dialog giving the details along with a continue and quit buttons. Selecting continue, just continues the application with no trapping into my uber exception handler. Selecting quite, whites-out the application and displays the standard close window dialog. The quit button also does not call my uber handler.
The purpose is so that my exception handler gets called. I do not need an uber exception handler if I am working inside the VS2012 IDE. The purpose of the handler is for end users and beta testers, namely anyone other than myself and who will not have my development station.
So unless I am missing something, the question is still open.
There are code samples in the other question, enough to copy and paste and create a test application in a couple minutes time.
]
Thanks in advance,
Sarah
I don't know of any automagical ways to reports error in Visual Studio but here is what I do.
Hook into the UnhandledException event for the application.
Use a logging framework like nLog or Log4Net to log the exception and other data you get from that event. Or just write to a text file.
Upload that data either from within your application or have the beta-tester send it to you.
Okay, the Google Uberlord took pitty upon me and I found this wonderful article solving the problem. Praise to the almighty Google.
Here is the link:
http://www.switchonthecode.com/tutorials/csharp-tutorial-dealing-with-unhandled-exceptions
Basically, JRadness had the right idea, just slightly in error. He should have used
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
rather than
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
The author on Switch on the Code talked of three methods, the first of which is what JRadness proposed and does not work for Windows forms.
The autor even solved my other question of Continue and Abort. The OS got bypassed.
Yeah!!
I've had a couple nasty problems with WPF applications crashing on certain client machines but working everywhere else - every developer's nightmare.
I'm posting the problems / solution here to help preserve the sanity of fellow developers. These were not easy to troubleshoot.
Both of these issues are classic "it works on my machine but not theirs" issues.
WPF app crashes on startup. No errors, no idea why.
WPF app starts up, the window border shows, but the contents do not paint. It just hangs (reported as a "transparent window") Clicking to close triggers a crash report (machine was windows XP).
1) WPF app crashes on startup. No errors, no idea why.
The key troubleshooting step to actually find the error in the first place is to add additional error handling to app.xaml.
In your App.xaml header, add:
<Application DispatcherUnhandledException="App_DispatcherUnhandledException" />
and in your App.xaml.cs, add something like:
void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs args)
{
log.Fatal("An unexpected application exception occurred", args.Exception);
MessageBox.Show("An unexpected exception has occurred. Shutting down the application. Please check the log file for more details.");
// Prevent default unhandled exception processing
args.Handled = true;
Environment.Exit(0);
}
After adding this additional debugging, I caught the error:
System.TypeInitializationException: The type initializer for 'System.Windows.Media.FontFamily' threw an exception. ---> System.ArgumentException: Illegal characters in path.
Further research, googling, and coffee, led to the solution that the client machine had a trailing '◻' character in a font entry in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
Removing this rogue character solved the problem.
See the career-saving blog post "How to Crash every WPF application".
2) WPF app starts up, the window border shows, but the contents do not paint. It just hangs (reported as a "transparent window")
This was another font-related issue. I initially boiled this down to a fontSize="16" in Window.xaml not working on one (and only one) machine at a client site, as if WPF refused to render their fonts at size 16 (?). I removed the code specifying the font size and it worked ... but as it turns out, it only worked for my login profile. It continued to fail for a colleague's login profile on the same machine machine. I could literally login as myself, run it successfully, log out, he'd log in as himself, run it, and it'd fail with the "transparent hanging window". Same machine, same permissions.
As a last resort, I logged in as him and noticed he had a custom theme set with enlarged font. I changed the windows theme back to the classic theme ... and this fixed the issue (?!?). This issue appears to also be font related, but I don't have an absolute root cause identified. Changing the theme back to standard theme is a temporary workaround.
I try to debug my silverlight application that contain OpenFileDialog.ShowDialog() call - and i get error exception about security ( "SecurityException was unhandled by user code : Dialogs must be user-initiated" )
When i run the application without debug - i don't get this exception.
But i must run it in debug mode because i need to see that i doing the right thing with the file that the customer choose ...
How can i run it with in debug mode ?
Thanks for any help.
If you are, and I assume you are, initiating the ShowDialog() call with a button click, Silverlight has some strange heuristics for determining if the action was user initiated.
It does work with debugging, but if you're stepping though the code from the Button_Click to the ShowDialog(), it seems to think that because of the delay, it is not a user initiated action.
To get around this, I'd recommend using logging instead of stepping through to debug the application. Silverlight is notorious for throwing these exceptions when trying to debug the ShowDialog() calls.
*EDIT
Silverlight does not use the Click() event to determine whether the button was user initiated. It uses a host of heuristics to determine it correctly including a timer (which is why debugging fails)
This issue has been logged at Microsoft:
http://connect.microsoft.com/VisualStudio/feedback/details/597430/debugging-of-code-between-the-user-initiated-entry-point-and-call-for-the-savefiledialog-openfiledialog-showdialog-method-lead-to-the-dialogs-must-be-user-initiated-exception#details
Just put the breakpoint after .ShowDialog().
make sure that when you open the dialog it is triggered by a button click. This is done for security reasons.
Edit
Apparently there is a bug in IE that can cause this error to raise even when user initiated
http://forums.silverlight.net/forums/p/208282/491053.aspx
Another knack on the "Dialogs must be user-initiated" Security Exception in Silverlight printing
Update: here is an MSDN article How to: Make Thread-Safe Calls to Windows Forms Controls. It states:
The .NET Framework helps you detect
when you are accessing your controls
in a manner that is not thread safe.
When you are running your application
in the debugger, and a thread other
than the one which created a control
tries to call that control, the
debugger raises an
InvalidOperationException with the
message, "Control control name
accessed from a thread other than the
thread it was created on."
This exception occurs reliably during
debugging and, under some
circumstances, at run time.
My previous experience was that the exception was thrown at run time, too.
Thanks to Spence for pointing me in the right direction.
I have a pretty common error in WinForms app: background thread accessing UI controls directly instead of using Control.BeginInvoke().
My problem is the following: I see the InvalidOperationException "Cross-thread operation not valid: Control 'uxCheckStatus' accessed from a thread other than the thread it was created on." in debugger on background thread, but then it is swallowed somewhere in WinForms internals.
I expect it to kill the background thread and entire application.
Moreover, the code that is triggering it uxCheckStatus.Text = "success"; sometimes gets executed during/after exception is thrown i.e. label text reads 'success'! I'm basically lost. Anyone else experiencing this behavior?
I reproduce it on completely new WinForms solution with 1 button, both using ThreadPool and Thread for evil background thread.
If I throw a new InvalidOperationException() on background thread, it does kill the application. So my only guess is that WinForms handles this specific exception somewhere, but I cannot find references to this behavior on the web.
I run .NET 3.5, VS 2008.
THis is by design. This is a coding error, not a runtime error. THe developers of Winforms decided that from .Net 2, they would implement code to check for the cross thread code and then fire an MDA. The MDA isn't an exception though, it's a check for badly designed code.
Additionally the MDA doesn't fire when your code is in release mode, it will just randomly fail every so often, the MDA is to help you at test, not during release.
I'm assuming that you are rewriting a badly written application to invoke onto the threads and you were hoping that the exceptions would catch for you, I have a suggestion:
Update your event handlers for GUI stuff to look like so:
public void button_clicked_handler(object sender, EventArgs e)
{
if(this.InvokeRequired)
{
this.Invoke(delegateToThisMethod)
}
else
{
//perform method
}
This pattern will catch all your methods and make it seamless for cross thread ops. If the threads are directly accessing code, this is a little tougher. You can get around this by renaming a control, then creating a property to the control, where you can then apply the invoke pattern to it. I've had to do this to troubleshoot some very funky cross thread stuff before.
EDIT:
Just wanted to clarify that checking the synchronisation context of the current thread and the Win Forms thread is a costly operation. Thus the reason they implemented the MDA is so that you find it in debug but that your release mode code isn't slowed down on EVERY access to EVERY property or method of a windows forms control.
I don't know of any specific documentation for how/why WinForms handles this exception. However, if you want to gracefully shut down your application when this happens, consider a global exception handler.