As per title, this is a problem that's similar to bug 1434933 but trickier to handle. The fix for bug 1434933 prevents us from generating two crash reports from the same crashing child process but only works if:

• The exception handler is set
• Windows Error Reporting is not involved

The latter generates problems with the main process too (see bug 1542485 comment 34) as WER will generate minidumps even when the exception handler has been unset.

A robust solution to this problem requires us to atomically set a value indicating that a process is crashing and we're handling the crash. This value would need to be read by all paths that are capable of generating a crash report (so including WER) to prevent them from generating further reports from the same process.

There's another wrinkle to this: in Breakpad we don't support recursive exception handling as it would make things even more complicated. This means that if we have a bug in the crash reporting code and this bug will cause a crash while handling a previous one then we'll never see it. Since WER lives outside of Firefox processes it was capable of catching these crashes - which was useful in some occasions. Preventing it from catching crashes we're already handling would effectively kill this functionality.

... unless we limit its ability but only under some circumstances. Let's say we store the thread ID of the crashing thread when we start handling a crash. We could ignore crashes coming from other threads but still catch crashes coming from the crashing thread, because that would indicate a bug in the exception handler.