VSTO应用全局异常处理实现咨询：WinForms托管WPF窗体场景

Hey there! I’ve wrestled with this exact issue before when building VSTO add-ins that mix Windows Forms and WPF, so let me break down why your AppDomain.CurrentDomain.UnhandledException isn’t firing and the complete set of steps you need to implement proper global exception handling.

The core problem here is that VSTO, Windows Forms, and WPF each have their own independent exception handling pipelines. A lot of unhandled exceptions get caught by these frameworks before they ever reach the AppDomain level. You need to hook into all three systems to cover every scenario.

1. Hook into the VSTO Host Application's Thread Exception #

First, your VSTO add-in runs inside a host (like Excel, Word, or Outlook) which has its own UI thread exception handling. You need to subscribe to this event in your add-in's startup method:

private void ThisAddIn_Startup(object sender, EventArgs e)
{
    // Subscribe to the host application's UI thread exception event
    Globals.ThisAddIn.Application.ThreadException += HostApp_ThreadException;
}

private void HostApp_ThreadException(object sender, ThreadExceptionEventArgs e)
{
    HandleGlobalException(e.Exception);
}

2. Handle Windows Forms Unhandled Exceptions #

Since you're using WinForms user controls, WinForms will catch UI thread exceptions by default unless you configure it otherwise. Add this setup in your WinForms control's initialization code (like the constructor or Load event):

public YourWinFormsControl()
{
    InitializeComponent();

    // Tell WinForms not to swallow unhandled exceptions automatically
    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
    
    // Subscribe to WinForms UI thread exceptions
    Application.ThreadException += WinForms_ThreadException;
    
    // Subscribe to AppDomain-level exceptions (covers background threads)
    AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
}

private void WinForms_ThreadException(object sender, ThreadExceptionEventArgs e)
{
    HandleGlobalException(e.Exception);
}

private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    if (e.ExceptionObject is Exception ex)
    {
        HandleGlobalException(ex);
    }
}

3. Catch WPF Dispatcher Exceptions #

WPF uses its own dispatcher for UI thread operations, so you need to hook into its unhandled exception event in your WPF window/user control:

public YourWpfWindow()
{
    InitializeComponent();

    // Subscribe to WPF UI thread unhandled exceptions
    Dispatcher.UnhandledException += WpfDispatcher_UnhandledException;
}

private void WpfDispatcher_UnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
    HandleGlobalException(e.Exception);
    // Mark the exception as handled to prevent it from crashing the add-in
    e.Handled = true;
}

4. Create a Unified Exception Handler #

Now, create a single method to handle all exceptions consistently—this is where you’ll log errors, show user-friendly messages, etc.:

private void HandleGlobalException(Exception ex)
{
    // Example: Log the full exception details to a file
    string logPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "VSTO_AddIn_Logs.txt");
    File.AppendAllText(logPath, $"{DateTime.Now:yyyy-MM-dd HH:mm:ss} - Unhandled Exception:\n{ex.ToString()}\n\n");

    // Show a user-friendly error message (avoid technical jargon)
    MessageBox.Show("Oops! Something went wrong. Please try again or contact support.", "Error", 
        MessageBoxButtons.OK, MessageBoxIcon.Error);
}

• Don’t rely on just one event: Each framework (VSTO host, WinForms, WPF) handles exceptions differently—you need all three hooks to cover every case.
• Background threads: Any exceptions thrown in non-UI background threads will only trigger AppDomain.CurrentDomain.UnhandledException, so don’t skip that subscription.
• Mark exceptions as handled: In the WPF DispatcherUnhandledException handler, set e.Handled = true to stop the exception from propagating to the host application (which might crash your add-in).
• Fallback try/catch blocks: For critical sections of code, add local try/catch blocks as an extra safety net—some host applications might still intercept exceptions in edge cases.

内容的提问来源于stack exchange，提问作者Emad Gabriel