Windows Error Reporting should create a crash dump file. The default location for dump files is "%LocalAppData%\CrashDumps". The file should be named either "python.exe.<pid>.dmp" (release build) or "python_d.exe.<pid>.dmp" (debug build).

You can analyze the crash dump in a debugger such as one of the SDK debuggers -- windbg (GUI) and cdb (console; cdb -z <dumpfile>). The 64-bit (x64) debuggers and associated tools such as gflags.exe should be in "%ProgramFiles(x86)%\Windows Kits\10\Debuggers\x64", if installed.

Make sure Python's debug symbols and debug binaries are installed. For an existing installation, you can change this from the Control Panel "Programs and Features". I assume you're testing with the 64-bit debug build, "python_d.exe".

Set a system environment variable named "_NT_SYMBOL_PATH" to configure the `cache` directory and Microsoft's public symbol server (`srv`). I use "C:\Symbols\Cache". For example:

    _NT_SYMBOL_PATH=cache*C:\Symbols\Cache;srv*https://msdl.microsoft.com/download/symbols

You may not have Python's symbol files already cached. In this case, you'll need to tell the debugger where it should look for the .pdb symbol files by extending the symbol path. For example, the following debugger command adds the base 64-bit Python 3.7 directories to the symbol path, assuming a standard all-users installation:

 .sympath+ C:\Program Files\Python37;C:\Program Files\Python37\DLLs

Or simply attach the debugger to a running python_d.exe process with the required extension modules loaded, and run `.reload /f` to cache the symbol files.

With the crash dump loaded in the debugger, run `!analyze -v` for a basic exception analysis. Also run `kn` to print the stack backtrace with frame [n]umbers for the current thread. If the backtrace doesn't included source files with line numbers, run `.lines` and rerun the `kn` command. Find the last Python frame just before the user-mode exception dispatcher (i.e. KiUserExceptionDispatch), and display its registers and local variables via `.frame /r [FrameNumber]` and then `dv /i /t /V`. 

That said, 0xC0000374 is STATUS_HEAP_CORRUPTION, which can be difficult to analyze with the default heap settings. To improve on this, enable full page-heap verification for "python_d.exe". Full page-heap verification ends every allocation with an inaccessible page, so the program will terminate on an unhandled STATUS_ACCESS_VIOLATION (0xC0000005 or -1073741819) at the exact line of code that tries to read or write beyond the allocation. 

You can configure full page-heap verification using gflags.exe if it's installed. From the command line, run `gflags /p /enable python_d.exe /full`. Or in the GUI, click on the "Image File" tab. Enter "python_d.exe" in the text box. Press tab. Select "Enable page heap", and click "OK". If you don't have gflags, you can configure the setting manually in the registry. (Even if you lack the tools to debug the problem yourself, at least you'll be able to send a more informative crash dump file to whoever has to analyze it.) Create a "python_d.exe" key in 
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options", and add the following two DWORD values: "GlobalFlag" with a hexadecimal value of 0x02000000 and "PageHeapFlags" with a value of 3. You'll probably want to disable full page-heap verification after the dump file is created, especially if you've enabled it for the release build, "python.exe".