Eryk Sun <[email protected]> added the comment:
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".
----------
nosy: +eryksun
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue36319>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
