90

When an application crashes on Windows and a debugger such as Visual Studio is installed the following modal dialog appears:

[Title: Microsoft Windows]

X has stopped working

A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.

[Debug][Close Application]

Is there a way to disable this dialog? That is, have the program just crash and burn silently?

My scenario is that I would like to run several automated tests, some of which will crash due to bugs in the application under test. I don't want these dialogs stalling the automation run.

Searching around I think I've located the solution for disabling this on Windows XP, which is nuking this reg key:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

However, that did not work on Windows Vista.

Wolf
  • 9,679
  • 7
  • 62
  • 108
Chris Smith
  • 18,244
  • 13
  • 59
  • 81
  • Nuking the AeDebug\Debugger key had no effect for me under Windows XP, either on console apps compiled with debugging or non-debugging libraries. – rptb1 Jul 15 '13 at 14:41

11 Answers11

58

To force Windows Error Reporting (WER) to take a crash dump and close the app, instead of prompting you to debug the program, you can set these registry entries:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"ForceQueue"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent]
"DefaultConsent"=dword:00000001

After this is set, when your apps crash, you should see *.hdmp and *.mdmp files in:

%ALLUSERSPROFILE%\Microsoft\Windows\WER\
NicJ
  • 4,070
  • 1
  • 25
  • 18
  • 3
    DefaultConsent=1 seem to be the default. What about DontShowUI ? – Zitrax Mar 14 '11 at 15:31
  • Te documentation of ForceQueue is vague, I don't get exactly what it means. – Zitrax Mar 14 '11 at 15:38
  • Setting the three values worked for me: ForceQueue, DefaultConsent, and DontShowUI. That last one was needed. But I see none of the *.hdmp or *.mdmp files you mentioned. But the event log does have the errors as it always had. But at least now my service is not hung. – Daniel Williams Jul 12 '11 at 22:18
  • None of these had any effect for me on Windows XP. – rptb1 Jul 15 '13 at 14:41
  • 2
    @NicJ please add DontShowUI=1 to your answer, it is the essential one – Youda008 Dec 22 '14 at 10:47
  • Or from the command line: reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent" /v DefaultConsent /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" /v ForceQueue /t REG_DWORD /d 1 /f – jhclark Jan 07 '16 at 17:51
  • 1
    Can also be set under HKEY_CURRENT_USER, I believe – PJTraill Jan 11 '16 at 14:38
  • 2
    windows registry editing is the way to IT hell, better consider answer from armenzg – lowtech May 25 '17 at 14:59
  • @lowtech except not all versions of windows have the Group Policy Editor available. Registry edits effectively accomplish the same thing, are automatable and auditable, and universal. – Doktor J Dec 04 '19 at 18:00
50

See here:

http://msdn.microsoft.com/en-us/library/bb513638.aspx

regedit

DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"

will make WER silently report. Then you can set

DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"

to stop it from talking to MS.

36

I'm not sure if this refers to exactly the same dialog but here is an alternative approach from Raymond Chen:

DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
Luke Quinane
  • 16,447
  • 13
  • 69
  • 88
  • Yes, calling SetErrorMode like that prevents the WER dialog mentioned by the OP. – Roman Starkov Sep 03 '10 at 16:57
  • 2
    The problem I have with SetErrorMode and the SEM_NOGPFAULTERRORBOX flag is that it doesn't create a dump file and make an entry in the Windows Event Log. Your program will just disappear without a trace when it crashes. For this reason I think the registry solution is better. – Derek Jul 03 '12 at 19:13
  • This works also for outdated frameworks (since WinXP). – Wolf Jul 02 '15 at 10:06
  • 1
    Agreed that this isn't good to ship with. It's really useful to unblock unstable to automation tasks, however. – kayleeFrye_onDeck Jul 06 '17 at 21:11
32

I had to disable this for release automation work on Windows 64-bits for Firefox and I did the following:

  • gpedit.msc
  • Computer configuration -> Administrative Templates
  • Windows Components -> Windows Error Reporting
  • Set "Prevent display of the user interface for critical errors" to Enabled

It is similar what was accomplished for Customer Experience reporting in: http://www.blogsdna.com/2137/fix-windows-installer-explorer-update-has-stopped-working-in-windows-7.htm

armenzg
  • 370
  • 4
  • 8
13

In my context, I only want to suppress the popup for my unit tests and not for the entire system. I've found that a combination of functions are needed in order to suppress these errors, such as catching unhandled exceptions, suppressing run time checks (such as the validity of the stack pointer) and the error mode flags. This is what I've used with some success:

#include <windows.h>
#include <rtcapi.h>
int exception_handler(LPEXCEPTION_POINTERS p)
{
    printf("Exception detected during the unit tests!\n");
    exit(1);
}
int runtime_check_handler(int errorType, const char *filename, int linenumber, const char *moduleName, const char *format, ...)
{
    printf("Error type %d at %s line %d in %s", errorType, filename, linenumber, moduleName);
    exit(1);
}

int main()
{
    DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
    SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
    SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)&exception_handler); 
    _RTC_SetErrorFunc(&runtime_check_handler);

    // Run your tests here

    return 0;
}
Gearoid Murphy
  • 11,834
  • 17
  • 68
  • 86
9

In WPF application 

[DllImport("kernel32.dll", SetLastError = true)]
static extern int SetErrorMode(int wMode);

[DllImport("kernel32.dll")]
static extern FilterDelegate SetUnhandledExceptionFilter(FilterDelegate lpTopLevelExceptionFilter);
public delegate bool FilterDelegate(Exception ex);

public static void DisableChashReport()
{
 FilterDelegate fd = delegate(Exception ex)
 {
  return true;
 };
 SetUnhandledExceptionFilter(fd);
 SetErrorMode(SetErrorMode(0) | 0x0002 );
}
Francesco Germinara
  • 508
  • 5
  • 8
  • Doesn't look like there's anything WPF-specific in there, and it seems to work just fine in my Console Application, too (.NET 4.6.2 in Windows 10) – mookid8000 Apr 15 '19 at 09:28
4

This isn't a direct answer to the question since this is a workaround and the question is about how to disable that feature, but in my case, I'm a user on a server with limited permissions and cannot disable the feature using one of the other answers. So, I needed a workaround. This will likely work for at least some others who end up on this question.

I used autohotkey portable and created a macro that once a minute checks to see if the popup box exists, and if it does, clicks the button to close the program. In my case, that's sufficient, and leaves the feature on for other users. It requires that I start the script when I run the at-risk program, but it works for my needs.

The script is as follows:

sleep_duration = 60000 ; how often to check, in milliseconds.
                       ; 60000 is a full minute

Loop
{
    IfWinExist, ahk_class #32770 ; use autohotkey's window spy to confirm that
                ; ahk_class #32770 is it for you. This seemed to be consistent
                ; across all errors like this on Windows Server 2008
    {
        ControlClick, Button2, ahk_class #32770 ; sends the click.
                ; Button2 is the control name and then the following
                ; is that window name again
    }
    Sleep, sleep_duration ; wait for the time set above
}

edit: A quick flag. When other things are up, this seems to attempt to activate controls in the foreground window - it's supposed to send it to the program in the background. If I find a fix, I'll edit this answer to reflect it, but for now, be cautious about using this and trying to do other work on a machine at the same time.

Nick
  • 341
  • 3
  • 8
4

You have to implement an unhandled exception filter which simply quits your application, then set that filter function with SetUnhandledExceptionFilter().

If you're using the secure CRT, you also have to provide your own invalid parameter handler and set this with _set_invalid_parameter_handler().

This blog post has some information too: http://blog.kalmbachnet.de/?postid=75

Stefan
  • 43,293
  • 10
  • 75
  • 117
4

During test you can run with a 'debugger' like ADPlus attached which can be configured in many useful ways to collect data (minidumps) on errors and yet prevent the modal dialog problems you state above.

If you want to get some useful information when your app crashes in production you can configure Microsoft Error reporting to get something similar to ADPlus data.

Steve Steiner
  • 5,299
  • 4
  • 32
  • 43
3

After trying everything else on the internet to get rid of just in time debugger, I found a simple way that actually worked and I hope will help someone else.

Go to Control Panel Go to Administrative Tools Go to Services Look down the list for Machine Debug Manager Right Click on it and click on Properties Under the General Tab, look for Start Up Type Click on Disable. Click on Apply and OK.

I haven't seen the debugger message since, and my computer is running perfectly.

Vicki Mollenauer
  • 31
  • 1
1

Instead of changing values in the registry you can completly disable the error reporting on Windows Server 2008 R2, Windows Server 2012 and Windows 8 with: serverWerOptin /disable

https://technet.microsoft.com/en-us/library/hh875648(v=ws.11).aspx

Sven Mawby
  • 645
  • 6
  • 16