I have a WPF application that\'s crashing once I get it onto machines that do not have a development environment installed-- if this is a dupe, I\'m welcome to closing, but
Exception logging (as in the answer from Alastair Pitts) would be a help in zeroing in on the source of the error.
The presence of XamlParse on line P9 suggests that there may be a problem initializing a control or window from the XAML description. There may be an assembly referenced by the XAML which was not found on the target computer, or did not match the signature in the XAML.
Edit:
XAML parsing occurs in InitializeComponent() which is called in the constructor of the window or control
The procedure I would use is to handle the UnhandledException
event in the app domain.
Once you have done that, you have a number of options. Logging the exception to a file, serialising it for later inspection, showing a dialog box with the exception message.
EDIT: XamlParseException
's occur when your main window is being created. This means that the constructor of that window is being called. If you perform any logic in that constructor, any resulting exceptions will throw a XamlParseException
. It is my understanding that the UnhandledException
handler will still catch this exception.
To hook up the UnhandledException
event in WPF, add the event hookup in your app.xaml
<Application
x:Class="DispatcherUnhandledExceptionSample.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="MainWindow.xaml"
DispatcherUnhandledException="App_DispatcherUnhandledException" />
which then adds a method in your app.cs
public partial class App : Application
{
void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
// Process unhandled exception do stuff below
// Prevent default unhandled exception processing
e.Handled = true;
}
}
MSDN
In addition to Alistair's answer, it's the InnerException that gave me the clues I was looking for:
public partial class App : Application {
void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e) {
Exception ex = e.Exception;
Exception ex_inner = ex.InnerException;
string msg = ex.Message + "\n\n" + ex.StackTrace + "\n\n" +
"Inner Exception:\n" + ex_inner.Message + "\n\n" + ex_inner.StackTrace + "\n\n" +
Utils.RegistryVersion();
MessageBox.Show(msg, "Drop Print Batch Application Halted!", MessageBoxButton.OK);
Utils.MailReport(msg);
e.Handled = true;
Application.Current.Shutdown();
}
}
In addition to having an unhandled exception event handler that logs the stack trace, it is also useful to look at the crash dumps being generated on the repro machine. You mentioned it's Windows 7, so you can look for corresponding crash dumps in the following ways:
Control Panel -> All Control Panel Items -> Action Center -> "View problems to report" link underneath the Maintenance/"Check for solutions to unreported problems" area. This brings up a list of applications that have crashed and you can drill down into them to find the dump files and information. Look for the "View a temporary copy of these files" link in the bottom left of the problem technical details. This will extract the dump files and show them to you in an explorer window.
cd /d %ProgramData%\Microsoft\Windows\WER.
WER seems to keep it's crash dumps underneath that directory, so what I do is a dir /s/b for part of the app name that I know will be there. For example, I made a on purpose crashy app that i called crashyapp.exe:
C:\ProgramData\Microsoft\Windows\WER>dir /s/b *crashy* C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_crashyapp.exe_56f8d710d72e31d822d6b895c5c43a18d34acfa1_cab_2823e614That directory contains the hdmp and mdmp files for the crash. Time to get a debugger attached!