Title: Inconsistent crashing with an access violation
Type: crash Stage: resolved
Components: Windows Versions: Python 3.7, Python 3.6
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Cameron Mckain, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-03-26 03:53 by Cameron Mckain, last changed 2017-03-28 16:04 by steve.dower. This issue is now closed.

File name Uploaded Description Edit
Desctop screenshot.png Cameron Mckain, 2017-03-27 20:30 VS debugging of crash
Messages (12)
msg290504 - (view) Author: Cameron Mckain (Cameron Mckain) Date: 2017-03-26 03:53
Almost every time I attempt to run my Django server ("python runserver") from PyCharm, python.exe crashes with the error "Unhandled exception at 0x7647BD9E (ucrtbase.dll) in python.exe: 0xC0000005: Access violation reading location 0x03BF8000." and "Process finished with exit code -1073741819 (0xC0000005)" is printed in the console. These errors only happen about 90% of the time.
msg290537 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-03-26 16:08
The offset in ucrtbase.dll where it's crashing may hint at the culprit. The following command should print the full event log for the most recent crash:

wevtutil qe application /rd:true /c:1 /format:text /q:"*[System[Provider[@Name='Application Error']]][EventData[Data='python.exe'][Data='ucrtbase.dll']]"
msg290545 - (view) Author: Cameron Mckain (Cameron Mckain) Date: 2017-03-26 18:21
C:\Users\cmcka\PycharmProjects\test>wevtutil qe application /rd:true /c:1 /format:text /q:"*[System[Provider[@Name='Application Error']]][EventData[Data='python.exe'][Data='ucrtbase.dll']]"
  Log Name: Application
  Source: Application Error
  Date: 2017-03-26T01:46:20.230
  Event ID: 1000
  Task: Application Crashing Events
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: CAMERON-OMEN
Faulting application name: python.exe, version: 3.6.1150.1013, time stamp: 0x58d169bd
Faulting module name: ucrtbase.dll, version: 10.0.14393.0, time stamp: 0x57898db2
Exception code: 0xc0000005
Fault offset: 0x0003bd9e
Faulting process id: 0x4464
Faulting application start time: 0x01d2a60d6fdf23d2
Faulting application path: C:\Python36\python.exe
Faulting module path: C:\windows\System32\ucrtbase.dll
Report Id: 109058c0-4e02-4bb6-a799-d6a975fe0d6f
Faulting package full name:
Faulting package-relative application ID:

This is from Python's faulthandler as well:
Windows fatal exception: access violation

Thread 0x000044b0 (most recent call first):
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\", line 96 in _on_run
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\", line 291 in run
  File "C:\Python36\lib\", line 916 in _bootstrap_inner
  File "C:\Python36\lib\", line 884 in _bootstrap

Thread 0x000044ac (most recent call first):
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\", line 353 in _on_run
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\", line 291 in run
  File "C:\Python36\lib\", line 916 in _bootstrap_inner
  File "C:\Python36\lib\", line 884 in _bootstrap

Thread 0x000039d4 (most recent call first):
  File "C:\Python36\lib\", line 299 in wait
  File "C:\Python36\lib\", line 173 in get
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\", line 430 in _on_run
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\", line 291 in run
  File "C:\Python36\lib\", line 916 in _bootstrap_inner
  File "C:\Python36\lib\", line 884 in _bootstrap

Current thread 0x0000446c (most recent call first):
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydev_bundle\", line 380 in new_spawnve
  File "C:\Python36\lib\site-packages\django\utils\", line 290 in restart_with_reloader
  File "C:\Python36\lib\site-packages\django\utils\", line 304 in python_reloader
  File "C:\Python36\lib\site-packages\django\utils\", line 333 in main
  File "C:\Python36\lib\site-packages\django\core\management\commands\", line 106 in run
  File "C:\Python36\lib\site-packages\django\core\management\commands\", line 97 in handle
  File "C:\Python36\lib\site-packages\django\core\management\", line 345 in execute
  File "C:\Python36\lib\site-packages\django\core\management\commands\", line 58 in execute
  File "C:\Python36\lib\site-packages\django\core\management\", line 294 in run_from_argv
  File "C:\Python36\lib\site-packages\django\core\management\", line 359 in execute
  File "C:\Python36\lib\site-packages\django\core\management\", line 367 in execute_from_command_line
  File "C:/Users/cmcka/PycharmProjects/test/", line 22 in <module>
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydev_imps\", line 18 in execfile
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\", line 1015 in run
  File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\", line 1578 in <module>

Process finished with exit code -1073741819 (0xC0000005)
msg290553 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-03-27 01:06
Have you confirmed this occurring with 3.5? PyCharm has a very invasive debugger that is almost certainly responsible, but there's a significant difference between the 3.5 and 3.6 implementations that is probably relevant.
msg290562 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-03-27 04:41
Steve, I added 3.5 because the crash involved ucrtbase.dll. I'll remove it for now since the problem is only confirmed in 3.6.

Offset 0x3bd9e in 32-bit ucrtbase.dll is in wdupenv_s [1]. It's probably from calling new_spawnve in, as shown in the faulthandler output. I don't use PyCharm, so I can't confirm this, but we know wdupenv_s is called by the CRT's wspawnve function. For example:

    >>> os.spawnve(os.P_WAIT, sys.executable, ['python', '-V'], os.environ)

    Breakpoint 0 hit
    eax=01b412b0 ebx=00000000 ecx=01b41280 edx=01b412b2 esi=01b41280 edi=00000000
    eip=7672bd9e esp=013ef368 ebp=013ef380 iopl=0         nv up ei pl nz na po nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
    7672bd9e 668b08          mov     cx,word ptr [eax]        ds:002b:01b412b0=0070
    0:000> kc 7

msg290564 - (view) Author: Cameron Mckain (Cameron Mckain) Date: 2017-03-27 05:58
The problem was fixed after updating to Django 1.11; apparently, Django 1.10 is not fully compatible with Python 3.6. Thanks for your time.
msg290611 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-03-27 13:57
Do you have a reference to an issue from their side about this? Python should never crash due to pure Python code, so we'd like to be able to prevent this in the future.
msg290643 - (view) Author: Cameron Mckain (Cameron Mckain) Date: 2017-03-27 20:30
No, my PyCharm issue has not been responded to by any of their people. Here is the link: 
Also, I have uploaded a screenshot of VS's debugging of the crash if it will be helpful.
msg290667 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-03-27 23:28
I was thinking of a Django issue. It'd be nice to know what they fixed that prevents the problem occurring.
msg290676 - (view) Author: Cameron Mckain (Cameron Mckain) Date: 2017-03-28 02:01
See this here:
msg290692 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-03-28 10:00
I can confirm that the CRT function construct_environment_block() does cause an access violation sometimes when no "=x:" shell variables are defined in the current environment. These "=x:" environment variables are the way that Windows emulates DOS per-drive working directories in a shell. The API itself never sets these variables; it only uses them if they're defined.

You should be able to avoid this bug by defining the environment variable "=C:". The simplest way to do this in Python is via os.chdir. For example:

    import os

    cwd = os.getcwd()

The implementation of os.chdir calls SetCurrentDirectoryW, which, for a drive-relative path such as "C:", will first look for an "=x:" environment variable and otherwise default to the root directory. After it changes the process current working directory, chdir() calls GetCurrentDirectoryW and SetEnvironmentVariableW to set the new value of the "=x:" variable.
msg290736 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-03-28 16:04
Thanks for the link! I've reported it to the C Runtime team and they'll get it fixed. (Because this is an operating system component, the fix will come through normal Windows Updates and apply to any version of Python 3.5+, so I'd rather not build a workaround into the product for it.)
Date User Action Args
2017-03-28 16:04:17steve.dowersetmessages: + msg290736
2017-03-28 10:00:30eryksunsetmessages: + msg290692
2017-03-28 02:01:49Cameron Mckainsetmessages: + msg290676
2017-03-27 23:28:06steve.dowersetmessages: + msg290667
2017-03-27 20:30:45Cameron Mckainsetfiles: + Desctop screenshot.png

messages: + msg290643
2017-03-27 13:57:28steve.dowersetmessages: + msg290611
2017-03-27 05:58:06Cameron Mckainsetstatus: open -> closed
resolution: out of date
messages: + msg290564

stage: resolved
2017-03-27 04:41:18eryksunsetmessages: + msg290562
versions: - Python 3.5
2017-03-27 01:06:51steve.dowersetmessages: + msg290553
2017-03-26 18:21:13Cameron Mckainsetmessages: + msg290545
2017-03-26 16:08:42eryksunsetversions: + Python 3.5, Python 3.6, Python 3.7
nosy: + paul.moore, tim.golden, eryksun, zach.ware, steve.dower

messages: + msg290537

components: + Windows
2017-03-26 04:15:43Cameron Mckainsettype: crash
2017-03-26 03:53:33Cameron Mckaincreate