> I don't understand why Python behaves differently in debug mode.
> For me, if Python is able to trigger an exception on EINVAL, we 
> should also get a regular Python exception in debug mode (and not 
> a crash)

The debug build's behavior isn't related to the invalid parameter handler, and it's not necessarily a crash. The default report mode for CRT_ERROR and CRT_ASSERT is CRTDBG_MODE_WNDW. This pops up a dialog asking whether to abort the process, ignore the error (fail and set errno), or retry if a debugger is attached (i.e. break into the debugger with a first-chance exception).

The mode can be changed to CRTDBG_MODE_DEBUG, which writes a message to the debugger, if one is attached to the process:

    msvcrt.CrtSetReportMode(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_MODE_DEBUG)

For example, in this case a message is written about the failed assertion in exec\spawv.cpp on line 276 (in this case the debugger is cdb, sharing the same console as Python, so the failed assertion message is inlined with Python's traceback):
    
    >>> os.spawnl(os.P_WAIT, '', 'non-empty')
    minkernel\crts\ucrt\src\desktopcrt\exec\spawnv.cpp(276) : Assertion failed: file_name[0] != '\0'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "C:\Program Files\Python37\lib\os.py", line 931, in spawnl
        return spawnv(mode, file, args)
    OSError: [Errno 22] Invalid argument

or set the report mode to CRTDBG_MODE_FILE with the file set to CRTDBG_FILE_STDERR:

    msvcrt.CrtSetReportMode(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_MODE_FILE)
    msvcrt.CrtSetReportFile(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_FILE_STDERR)