0

BACKGROUND

I have a C++ command-line application that was crashing on Windows 10 and Windows Server 2016. The cause of this crash is not pertinent to this post, and indeed I have already fixed the crash. While trying to troubleshoot this crash, I used this how-to to enable crash report dumping on Windows 10. I edited the registry and, within HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps, added these keys:

  • DumpFolder: C:\data0\CrashReports
  • DumpCount: 0x10
  • DumpType: 0x2

I also made sure that C:\data0\CrashReports was read-writable by everyone. After restarting the machine, I ran my application to crash again, but no crash report was dumped. After extensive searching and debugging, I came across this related Stackoverflow answer, where I learned that SetErrorMode( SEM_NOGPFAULTERRORBOX ) will prevent crashes from being reported to Windows Error Reporting. Indeed, my application had this call to suppress dialogs:

SetErrorMode(
  SEM_FAILCRITICALERRORS |
  SEM_NOALIGNMENTFAULTEXCEPT |
  SEM_NOGPFAULTERRORBOX |
  SEM_NOOPENFILEERRORBOX )

The documentation for SetErrorMode does not mention this. Of this flag, it says only:

The system does not display the Windows Error Reporting dialog.

Nevertheless, the SO answer appears to be true, because when I removed SEM_NOGPFAULTERRORBOX from that call and left the other three flags in place, I got the crash report I needed to debug and fix my crash. In fact, my crash also started showing up in Event Viewer. So, apparently, SEM_NOGPFAULTERRORBOX doesn't just suppress the WER dialog; it also suppresses crash report dumps and Event Viewer entries. It suppresses any evidence that the crash ever occurred (which is really terrible, IMO).

QUESTION

And now I get to my question: Also when I removed SEM_NOGPFAULTERRORBOX, no Windows Error Reporting dialog appears. I get the crash report, but the dialog window is still suppressed. This is the exact behavior that I wanted, so, yay!, but I don't understand it. According to that Microsoft documentation, removing that flag should have resulted in WER dialogs. Why am I not getting a WER dialog? Did Microsoft wise up to the notion that command-line-only applications shouldn't be opening error dialog boxes (which often cannot even be seen or closed, because SSH).

That other SO answer mentions setting the HKLM\...\WER key DontShowUI to 1 to suppress WER dialogs, and I was prepared to do that if necessary, but I did not do that yet. That key does not exist, so that is not the reason WER dialogs are not appearing.

Nick Williams
  • 2,864
  • 5
  • 29
  • 43

1 Answers1

2

I've looked into this in the past and came to the conclusion that the behavior of Windows Error Reporting in Windows 10 has changed. In previous Windows versions, it looks like the default value of DontShowUI was 0, while in Windows 10 the default has changed to 1 and you need to explicitly set it to 0 to enable the error dialogs again.

At least for when the crash occurs in a process that displays a user interface. For invisible (including console) processes, WER ignores the value of DontShowUI and is hard-coded to never show an error dialog.

This ultimately led me to write a tool that hooks itself into WER and modifies its behaviour to show the dialog for all crashes, including those in invisible processes: WerTweak. As a plus, it makes WER display the same old-style crash reporting dialog as in previous Windows versions, instead of the crippled new dialog usually displayed in Windows 10.

Tim De Baets
  • 169
  • 9
  • 1
    This is the conclusion that I'm beginning to come to, too—that, starting with Windows 10, invisible processes do not open an error dialog. This is a critical improvement, IMO, so I'm happy with it. I'll circle back in a few days and accept this answer, allowing some time for this activity to possibly attract other answers. – Nick Williams Sep 18 '21 at 21:05