Fall back to a plain minidump when the rich one fails

[HeathHowren]

Why

Two CI runs failed on An uncaught C++ exception produces a minidump (3d439cb Debug, 2c2a614 Debug). Both failed the same assertion: the .dmp existed and was over 4 KB, but the crash log did not contain "minidump written".

Only the terminate path ever failed. The access-violation and invalid-parameter probes never did — and the invalid-parameter one passes the same null exception info, so that is not the difference.

MiniDumpWithIndirectlyReferencedMemory walks everything the stack points at. That walk can report failure after most of the file has already been written, which leaves a large .dmp sitting next to a log line saying no dump was written — and it is worst on the terminate path, where an exception is still in flight while the walk runs. That is the one moment the crash log has to be believable.

What

• writeMinidump now retries as a plain MiniDumpNormal when the rich type fails. A plain dump needs no walk. Much less than the full dump, much more than nothing — and the log line becomes true again.
• The three crash tests print the log they read and require it to be non-empty. A log that could not be read and a log missing a line both arrived as npos != npos, so neither CI failure could say which had happened. The comment in that file had already complained about exactly this.

Tests

• Fallback verified directly: with the rich attempt forced to fail, all four crash tests pass on MiniDumpNormal alone — so a plain dump still clears the 4 KB the test requires and the log line is honest. Without this, the retry would be an untested path in a crash handler.
• Debug and Release both 99/99, warning-clean under /W4 /WX.

Honest limit: the flake has never reproduced on my machine — 25 consecutive [crash] runs in Debug are clean both before and after the change. The diagnosis comes from the two CI failures and from which of the three probes fail, not from a local repro. CI is the only place this can be confirmed. If it recurs, the new INFO output will name the line the log actually contained.

Needed on master before v2.1.0 is tagged: the tag build runs the same suite, and this was failing roughly one Debug run in four.