Attached is a patch which adds skip_unless_unattended, which ideally would be used with at least test_faulthandler when running on Windows.

Running the tests on a Windows desktop results in the user having to click through Windows Error Reporting dialogs in order to continue. Build slaves disable or handle WER dialogs in order to continue running without manual intervention. The patch looks in the common registry keys [0,1] to see the status of WER and skips tests when it finds that WER is enabled and would require user intervention.

We may want to additionally hook this up to a regrtest command line parameter to override the registry setting.

Maybe there's a better name for the decorator - I'm not stuck with what I suggested. I consider build slaves as running in "unattended" mode as opposed to a human kicking off the tests.

[0] http://www.spyany.com/program/registry-disable-error-reporting.htm
[1] http://msdn.microsoft.com/en-us/library/bb513638(v=vs.85).aspx

Attached is an example of how this might be used with Lib/test/test_faulthandler.py

Ah yes, I have also issues with the Windows fault handler (the popup). I disabled this popup manually in my Windows XP box.

Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key).

faulthandler causes fatal errors, but test_capi does also test a crash (I don't know which test exactly). I always have to click on the popup to continue to execute the test suite :-(

Ubuntu has also a fault handler: Apport.
https://wiki.ubuntu.com/Apport

Fedora has abrt.
https://fedorahosted.org/abrt/wiki
http://fedoraproject.org/wiki/Features/ABRT

If we should to disable the Windows fault handler, we may also disable these tools.

test_faulthandler already disable another fault handler: it disables the creation of core files. prepare_subprocess() calls setrlimit(RLIMIT_CORE, (0, 0)).

Disabling and re-enabling is another possibility, and it's probably more likely to help in the long run. Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually, so the only place tests would be run with my first patch would be on build slaves.

I don't currently have a Ubuntu or Fedora machine, but I could look into it. I'll write up a patch that disables/re-enables for Windows and see how it works.

Issue bpo-12481 has been marked as duplicate: "I'm getting the dreaded "python_d.exe has stopped working" popups in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64"."

"Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually"

It is disabled on all Windows buildbots. test_capi does also test a crash (I don't know/remember which test exactly).

For test_capi the patch in bpo-9116 works. For test_faulthandler it
doesn't, unfortunately.

"Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key)."

Do you mean that the user should change/restore the key or that the
Python tests should do that? I think we shouldn't mess with system
settings, even if we restore them.

BTW, it would be a great help to print a warning (also in test_capi)
that the popups are expected.

Do you mean that the user should change/restore the key
or that the Python tests should do that?

Python can change temporary the registry value for the duration of the test.

To avoid messing with system registry settings it sounds like WerRegisterRuntimeExceptionModule could also work, at least on Windows7 http://msdn.microsoft.com/en-us/library/windows/desktop1/dd408167%28v=VS.85%29.aspx

There could be a dll which would do nothing when receiving the crash report for expected crashes (test_capi and test_faulthandler). WerRegisterRuntimeExceptionModule doesn't exist in the headers of the SDK that comes with VS2008 but it could be retrieved at runtime with GetProcAddress. It's more work than the registry setting but seems cleaner since it avoids changing system settings.

That would certainly be preferable when available on Windows 7. I'll look into how we can incorporate that.

Thanks for the idea!

Here is a proof of concept patch that defines a context manager that disables the crash popups using SetErrorMode 0. I tested it only on Windows 7 (and Linux, where it's a no-op). As an example, the patch fixes the crash popup caused by test_capi.

FWIW I attempted to use WerRegisterRuntimeExceptionModule too, and I was able to access it from ctypes.windll.kernel32.WerRegisterRuntimeExceptionModule on Win7, but then it wanted me to define a DLL with 3 functions, so I tried to find a simpler solution.

Attached an updated patch:

• renamed the context manager from no_crash_popups to suppress_crash_popup, as suggested by Brian (I also made it singular, because there shouldn't be more than one crash/popup per call);
• used the context manager on all the crashing tests (test_capi and test_faulthandler);
• added documentation;

I tested it on Windows 7 and Linux (where it's a no-op), and according to MSDN it should work even on Windows XP. If there aren't other comments I'll commit this soon. If test_capi is also crashing on 2.7/3.2, I will probably backport it there too.

New changeset 834a451f1cdb by Ezio Melotti in branch '3.3':
bpo-11732: add a new suppress_crash_popup() context manager to test.support.
http://hg.python.org/cpython/rev/834a451f1cdb

New changeset b87123015fb0 by Ezio Melotti in branch 'default':
bpo-11732: merge with 3.3.
http://hg.python.org/cpython/rev/b87123015fb0

I applied this only on 3.3/3.x because I didn't manage to test on 2.7/3.2.
If test_ctypes and/or other tests are failing there I can backport it, but the patch needs to be tweaked there because it doesn't apply cleanly (and there's no test_faulthandler there).

Attached an untested patch against 3.2.
On 2.7 and 3.2 there's no test_faulthandler, and the crashing test in test_ctypes seems to be in 3.x only.

Unless I'm missing something:

1. no crash popups should appear while running the 2.7 test suite;
2. only test_ctypes should show a crash popup on 3.2 and the attached patch should fix it;

Brian, if you can confirm this I'll go ahead, backport the patch on 3.2, and null merge it on 3.3/default.

New changeset 6ccefddc13fd by Ezio Melotti in branch '3.3':
bpo-11732: make suppress_crash_popup() work on Windows XP and Windows Server 2003.
http://hg.python.org/cpython/rev/6ccefddc13fd

New changeset 831035bda9b7 by Ezio Melotti in branch 'default':
bpo-11732: merge with 3.3.
http://hg.python.org/cpython/rev/831035bda9b7

New changeset c0c440dcb8dd by Ezio Melotti in branch '3.2':
bpo-11732: add a new suppress_crash_popup() context manager to test.support that disables crash popups on Windows and use it in test_ctypes.
http://hg.python.org/cpython/rev/c0c440dcb8dd

New changeset 89d62bc81e47 by Ezio Melotti in branch '3.3':
bpo-11732: null merge with 3.2.
http://hg.python.org/cpython/rev/89d62bc81e47

New changeset 7e818490d297 by Ezio Melotti in branch 'default':
bpo-11732: null merge with 3.3.
http://hg.python.org/cpython/rev/7e818490d297

GetErrorMode wasn't available on XP/2k3, so I changed the patch to use only SetErrorMode. I also backported it to 3.2, since ctypes has the same crashing test of 3.3/default.
If I got everything right there shouldn't be anymore crash popups while running the tests, however I haven't tested this on 2.7/3.2, so there might be other popups that I missed. If there are, feel free to reopen the issue.

I just noticed that regrtest also has a --nowindows flag that uses SetErrorMode (see Lib/test/regrtest.py:490).
The implementation is a bit different:

1. it uses msvcrt instead of going through ctypes.windll.kernel32;
2. it specifies SEM_FAILCRITICALERRORS, SEM_NOALIGNMENTFAULTEXCEPT, and SEM_NOOPENFILEERRORBOX in addition to SEM_NOGPFAULTERRORBOX;
3. it doesn's seem to save and restore the previous error mode;
4. it has additional calls to CrtSetReportMode and CrtSetReportFile;
5. it doesn't check the platform and thus raises an ImportError if msvcrt is missing;

Do you think this flag should be removed?
Should I improve my context manager with any of these things?