On my 64-bit Windows 10, the echo here would print -1073741571:
python -c "import faulthandler; faulthandler._fatal_error(b'a' * 2 ** 22)"
echo %errorlevel%

This is code c00000fd, which windbg describes as 'Stack overflow'.
This happens because Py_FatalError() (in Python/pylifecycle.c) does the following
(on Windows only):
    len = strlen(msg);

    /* Convert the message to wchar_t. This uses a simple one-to-one
    conversion, assuming that the this error message actually uses ASCII
    only. If this ceases to be true, we will have to convert. */
    buffer = alloca( (len+1) * (sizeof *buffer));
    for( i=0; i<=len; ++i)
        buffer[i] = msg[i];


Note that (IIUC) running the aforementioned cmd wouldn't cause a post-mortem
debugger to pop-up, because faulthandler_fatal_error_py()
(in Modules/faulthandler.c) first calls faulthandler_suppress_crash_report(),
and then calls Py_FatalError().

I proposed PR 3878 to replace alloca() with a fixed buffer of 256 bytes.

New changeset 8d5a3aad2f805dc0ea40829b751f58aa6c75305d by Victor Stinner in branch 'master':
bpo-31683: Py_FatalError() now supports long error messages (#3878)
https://github.com/python/cpython/commit/8d5a3aad2f805dc0ea40829b751f58aa6c75305d

IMHO this issue is theorical. I don't expect that anyone would call Py_FatalError() with a very long message, so I will not backport the fix to Python 2.7 and 3.6.

Thanks for the bug report Oren Milman!