The unhandled exception filter is the responsibility of the process; don’t change it without permission

A customer developed an Office add-in and wanted to intercept all unhandled exceptions so that they could collect crash dumps, capture stack traces, and so on. To do this, they used the Set­Unhandled­Exception­Filter function to register their custom unhandled exception handler to capture crash dumps and stack traces.

The customer reported that this technique was successful in earlier versions of Office, but stopped working starting in Office 2013. (They didn’t test Office 2010.) Their custom unhandled exception handler is no longer being called.

The customer wanted to know if there were any known circumstances where the Set­Unhandled­Exception­Filter function would stop working, and what workarounds were available, even if it means abandoning their current strategy and getting their crash dumps some other way.

The unhandled exception filter is a process-wide resource, and therefore the process is the one who makes the decision what unhandled exception filter they want. A DLL is a guest in the host process, and common courtesy says that guests don’t cancel the homeowner’s insurance policy and replace it with their own.

Besides, imagine what would happen if two plug-ins wanted to replace the unhandled exception filter. (Bonus: And then one of those plug-ins was unloaded.)

The Office team discovered that large numbers of add-ins were (either intentionally or inadvertently) corrupting the process-wide unhandled exception filter. This meant that crashes were no longer being routed through Office’s own unhandled exception filter. Not only were none of the crashes in Office being reported through Windows Error Reporting, users were losing data because Office’s custom unhandled exception filter was not getting a chance to attempt document recovery before the process finally went away.

To work around rogue DLLs replacing the unhandled exception filter, Office detours the Set­Unhandled­Exception­Filter function.

This answer from Office developer support confirms the above discussion and further suggests a workaround: Register your plug-in with Windows Error Reporting. Microsoft’s back-end error reporting service (known as Watson, not the same as Dr. Watson). All the crashes received by the Watson service are analyzed, and if the analysis concludes that your plug-in was responsible for the problem, the crash dump will be made available to you.