0

In good old time, invalid memory access or unhandled exception in application resulted in some form messagebox displayed.

It seems to me that recently this stopped to be true. I can create a small application that does nothing else than write to NULL pointer, run it from the windows shell and it just dies silently.

I have Visual C++ commandline tools installed and using to compile that small app (plain C++ and win32 SDK). App is compiled in 64bit mode.

Any clue what is going on? I am really missing those crash messageboxes...

Jabberwocky
  • 48,281
  • 17
  • 65
  • 115
Mirek Fidler
  • 330
  • 1
  • 9
  • What do you need those crash messageboxes for? – user7860670 Nov 13 '18 at 08:10
  • @VTT to let you know the app has crashed? – Jabberwocky Nov 13 '18 at 08:40
  • If this happens in development environment then debugger will notify you upon crash, if it happens in production environment then you will need to use some sort of crash reporting mechanism. – user7860670 Nov 13 '18 at 08:47
  • @jab: The crash dialog is pretty intimidating, and not entirely useful to an end user. A far better option is to restart the application, and notify the user about the crash, when the application is in a consistent state. The [Restart Manager](https://learn.microsoft.com/en-us/windows/desktop/rstmgr/restart-manager-portal) can be configured to restart the application when a process needs to shut down in an abnormal way. – IInspectable Nov 13 '18 at 16:44
  • 1
    Correction, the restart can be configured using the [Application Recovery and Restart](https://learn.microsoft.com/en-us/windows/desktop/api/_recovery/) technology, not Restart Manager. – IInspectable Nov 13 '18 at 16:48
  • Just to explain what I need them for: Often, when developing app, I run it without debugger. Error message box tells me early that something is wrong. – Mirek Fidler Nov 14 '18 at 09:16

2 Answers2

3

It's true by default this message boxes are disabled. You can do a few things about it:

1. (Re)Enable the messagebox (most probably what you are looking for)

Press Start and type gpedit.msc. Than navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Error Reporting -> Prevent display of the user interface for critical errors and select Disabled. Disable the Prevention This will bring back at least some error messages if your application crashes.

2. Setup an Unhandled Exception Filter (probably dangerous)

Install an exception handler filter and filter for your desired exceptions. The drawback here is, the filter is called on every thrown exception.

3. Setup a signalhandler (also dangerous)

Basically like this.

void SignalHandler(int signal)
{
    printf("Signal %d",signal);
    throw "!Access Violation!";
}

int main()
{
    typedef void (*SignalHandlerPointer)(int);

    SignalHandlerPointer previousHandler;
    previousHandler = signal(SIGSEGV , SignalHandler);
}

4. Use Windows Error Reporting

As mentioned by IInspectable and described in his answer.


Option 2 and 3 can become quite tricky and dangerous. You need some basic understanding in SEH exceptions, since different options can lead to different behavior. Also, not everything is allowed in the exception handlers, e.g: writing into files is cosidered extremly dangerous, or even printing to the terminal. Plus, since you are handling this exceptions, your program won't be terminated, means after the handler, it will jump right back to the erroneous code.

user1810087
  • 5,146
  • 1
  • 41
  • 76
  • You missed the most simple and powerful option to deal with this: [Windows Error Reporting](https://docs.microsoft.com/en-us/windows/desktop/wer/windows-error-reporting). Setting it up amounts to writing a few registry entries. Once set up, it will capture the state of the application at the point of error. A note on the unhandled exception filter: It is only ever called when no other exception filter communicated, that it would handle the exception. This isn't dangerous either. It's even customary to install one in every application. The support library's startup code does that for you. – IInspectable Nov 13 '18 at 12:16
  • @IInspectable, true totally forgotten about that. I personally never used WER, only read about, thus not very familiar. We did however implement a custom handler/filter which did create a dump file (on windows and linux), which we can use for post mortem debugging. Still, thank you for the reminder :) – user1810087 Nov 13 '18 at 14:42
  • 1
    Thanks for that. Bullet 1 is the right choice for a dev machine, I confirmed it worked well. – Hans Passant Nov 13 '18 at 15:27
  • Unfortunately, I still see crashes being handled silently, even after following suggestion 1. To verify, I've written a simple C++ application that just dereferences a NULL pointer. On Windows 7, the application triggers the `... has stopped working` error, as expected. But on all my Windows 8/10 systems, the application is terminated silently. Are there any other suggestions to disable Windows 10's silent crash handling? – Tim De Baets Dec 02 '19 at 21:01
  • After some more research, I've found out that suggestion 1 does in fact help in some cases. But in other cases, for example when the application doesn't have any UI, the crash is still being handled silently. Even more annoyingly, the WER crash dialog contains a lot less information than on previous Windows versions. – Tim De Baets Feb 04 '20 at 20:43
  • Luckily I've been able to find a way for WER to display the old, familiar crash dialog in *all* cases. It's not just a simple registry tweak since it requires hooking the undocumented `WerUICreate` function exported by `werui.dll` and modifying one of the parameters. I'm planning to upload my source code to GitHub soon and will post a notification here when that has been done. – Tim De Baets Feb 04 '20 at 20:43
  • FYI, I've finally been able to put my source code online (as promised above): https://github.com/tdebaets/wertweak Feel free to give it a try :) – Tim De Baets Aug 03 '20 at 19:29
0

If you want your process to always show the error UI, you can call WerSetFlags with a value of WER_FAULT_REPORTING_ALWAYS_SHOW_UI. Or use any other applicable option offered by Windows Error Reporting, that suits your needs (like automatically creating a crash dump on unhandled exceptions).

IInspectable
  • 46,945
  • 8
  • 85
  • 181