64 bit python fails on Windows 7

[richo]

BPO	7206
Nosy	@loewis, @pitrou, @pR0Ps
Files	failedPython.log: windows debugger log of python 3.1

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-11-18.05:46:57.066>
created_at = <Date 2009-10-25.23:29:16.199>
labels = ['interpreter-core', 'build', 'OS-windows', 'type-crash']
title = '64 bit python fails on Windows 7'
updated_at = <Date 2009-11-19.02:57:36.455>
user = 'https://bugs.python.org/richo'

bugs.python.org fields:

activity = <Date 2009-11-19.02:57:36.455>
actor = 'richo'
assignee = 'none'
closed = True
closed_date = <Date 2009-11-18.05:46:57.066>
closer = 'richo'
components = ['Build', 'Interpreter Core', 'Windows']
creation = <Date 2009-10-25.23:29:16.199>
creator = 'richo'
dependencies = []
files = ['15197']
hgrepos = []
issue_num = 7206
keywords = []
message_count = 29.0
messages = ['94467', '94468', '94471', '94472', '94473', '94474', '94477', '94532', '94533', '94536', '94537', '94844', '94848', '94849', '94850', '94877', '94889', '94910', '94912', '94914', '94916', '94918', '94921', '94923', '94929', '95410', '95412', '95413', '95462']
nosy_count = 4.0
nosy_names = ['loewis', 'pitrou', 'richo', 'pR0Ps']
pr_nums = []
priority = 'critical'
resolution = None
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue7206'
versions = ['Python 2.6', 'Python 3.1']

[richo]

64 bit pythons fail on 64 bit Windows 7.

The crash happens with python 2.6 and 3.1 in 64 bit mode. 3.1 was a
clean install after the issue presented itself.

I'm not 100% sure how best to help with the problem, I've attached the
dump from windows debugger, please let me know if there's anything else
I can do to help.

It used to work but I'm not sure what changed, as near as I can tell
nothing system wide did, except perhaps the installation of new
compilers, my thought is that it could alter some dll search path?

Thanks in advance

richo

[pitrou]

What is "LuaPriv" in that log? Something you installed?
(sorry, not a Windows specialist)

[richo]

I'm not 100% sure.

I have a x64 machine running Windows 2008. I will check if it's in the
log now.

I will also check if it's in the debug trace for x86 python (which works).

RESULTS:

I get the LuaPriv initialised line on x86 python on my win7 machine
(which works).
I don't get that line on any python builds on x64 windows server 2008.

I did some googling on what it is- it's a mechanism for restricting
access. It seems that it could be causing the crash because it thinks
the application is overflowing the stack (ie, it's a DEP related issue?).
http://msdn.microsoft.com/en-us/library/dd371695(VS.85).aspx
That is a M$ link about it.

I'm fully willing to help but don't know how, I am quite novice.

Thanks

richo

[richo]

I think that dump may be incorrect because it does not have all the
symbols. I will checkout source for latest 3.x trunk and attempt to
build 64 bit binaries.

[loewis]

What kind of action has triggered that crash?

[richo]

No action- the interpreter fails to start.

Or do you mean what changed to make it break? I'm not sure. It used to
work but I don't believe I changed anything on my system.

[loewis]

No action- the interpreter fails to start.

How precisely do you start the interpreter (and what interpreter precisely)?

[richo]

By running the python.exe (either by double clicking it, typing it's
path into a cmd shell or by opening it in a debugger).

I tried to create a 64 bit build of the source tree which DID start, but
the hoops I had to jump through to build it with VC++ Express Edition
were so convoluted that I'm not convinced it's meaning.

I've tried this with 2.6.3 and 3.1.1 from the amd64 .msi's at
http://www.python.org/download/

(2.6.3 was the current release when I tried. I will install 2.6.4 and
let you know- although I'm not convinced it will help).

[richo]

Nope- 2.6.4 fails in the same way.

[loewis]

FWIW, these all run fine on my copy of Windows 7.

[richo]

They did at first for me, and then something changed.

They now don't start. I don't have the skills to properly diagnose why,
all I can get out of my debuggers is that something is happening in
ntdll.dll

Not necessarily pointing fault at Python per se, but as it's the only
application I can find this bug in, and it's present in every amd64
version of Dolphin I try this is my first port of call.

What other info can I provide to help? I can set up a remote desktop to
this machine for a developer if they would like.

[pR0Ps]

I am having the exact same problem with both the AMD64 and 32 bit
installs. The python shell just will not open. For now I am running it
in the virtual XP machine but it is extremely slow and a fix would be
very helpful. I have tried uninstalling and reinstalling with no effect.
I too am willing to set up a remote desktop connection if it would help.

Windows 7 Pro RTM, Intel Core 2 Duo

[loewis]

By "exactly the same problem", do you mean that your installation also
runs into a break instruction in ntdll!CsrSetPriorityClass+0x40? Can you
please also attach the debugger log (unless it's byte-for-byte identical
with the one from richo)?

[pR0Ps]

i don't know how to do that. Is there an integrated debugger within
Windows 7? My program just doesn't open, it doesn't display any error
messages at all.

[loewis]

i don't know how to do that. Is there an integrated debugger within
Windows 7? My program just doesn't open, it doesn't display any error
messages at all.

Ok. So I'm skeptical that this is the same bug (having roughly the same
symptom is not convincing). If you want it studied, please report it
separately.

[richo]

Carey I can send you the steps I used to create the dump if you like so we
can check if it's the same issue?

[pR0Ps]

yes, please do

[richo]

Download the debugging suite from
http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx#

Open windbg
Press Ctrl + E to load an executable
Select your python binary
Step through by typing g in the text box at the bottom of the Command
window.

The application will fail to crash completely as windbg will catch the
exception, however you should notice that it's spitting out duplicate
errors after a few breaks.

Paste up your log :)

[pR0Ps]

I dont know if what i did was right but heres my log

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Python31\pythonw.exe
Symbol search path is: srv*
Executable search path is:
ModLoad: 00000001d000000 000000001d00b000 pythonw.exe
ModLoad: 000000076f20000 00000000770cb00 ntdll.dll
ModLoad: 000000076e00000 0000000076f1f000
C:\Windows\system32\kernel32.dll
ModLoad: 000007fefd1e0000 000007fefd24b000
C:\Windows\system32\KERNELBASE.dll
ModLoad: 00000001e000000 000000001e2b0000
C:\Windows\system32\python31.dll
ModLoad: 000000076d00000 0000000076dfa000
C:\Windows\system32\USER32.dll
ModLoad: 000007feff1c0000 000007feff227000 C:\Windows\system32\GDI32.dll
ModLoad: 000007feff1b0000 000007feff1be000 C:\Windows\system32\LPK.dll
ModLoad: 000007fefd380000 000007fefd44a000 C:\Windows\system32\USP10.dll
ModLoad: 000007fefdb30000 000007fefdbcf000
C:\Windows\system32\msvcrt.dll
ModLoad: 000007fefda50000 000007fefdb2b000
C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fefdd00000 000007fefdd1f000
C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fefd250000 000007fefd37e000
C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fefdf00000 000007fefec86000
C:\Windows\system32\SHELL32.dll
ModLoad: 000007fefec90000 000007fefed01000
C:\Windows\system32\SHLWAPI.dll
ModLoad: 0000000730a0000 000000007313d000
C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_08e1a05ba83fe554\MSVCR90.dll
(1284.19dc): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
000000076fd1220 cc int 3 0:000> g ModLoad: 000007fefcd50000 000007fefcda7000 C:\Windows\system32\apphelp.dll ModLoad: 000007fefd810000 000007fefd83e000 C:\Windows\system32\IMM32.DLL ModLoad: 000007fefed90000 000007fefee99000 C:\Windows\system32\MSCTF.dll ntdll!NtTerminateProcess+0xa: 0000000076f7017a c3 ret
0:000> g
^ No runnable debuggees error in 'g'
0:000> g
^ No runnable debuggees error in 'g'

It seems it cant find a file that it needs, but i dont know why.
Obviously this is a different issue

[richo]

Carey: You need to run python.exe, pythonw.exe does not create a console
window and is for running python scripts that have their own GUI.

[pR0Ps]

python.exe works fine. It's IDLE that doesn't work and it uses pythonw.exe.

[loewis]

python.exe works fine. It's IDLE that doesn't work and it uses pythonw.exe.

So please report this as a separate bug. For the OP, python.exe crashes.

[richo]

Precisely.

Martin: What more can I do to help? I really need 64 bit Python working
on this machine but am running out of things I can do.

Am happy to put in the hard yards, just need clarification about what I
should be doing.

[loewis]

Am happy to put in the hard yards, just need clarification about what I
should be doing.

The only thing I can think of is debugging. Install visual studio,
create a debug build of Python, hope that it will still crash, and
debug why it does. Alternatively, run the release build in a debugger...

[pR0Ps]

In the other issue there was a fix that involved unhiding the recent
files list. I unhid the files in the .idlerc folder and everthing works now.

[richo]

I've done some more fiddling with the debugger, once I discovered the
Windows symbol servers, and a tool called application verifier some
things started to fall into place.

LuaPriv takes care of user privelidges, the program runs fine when I run
it as administrator. I believe that disabling UAC has caused the issue.

I will attempt 2 things
a) Create a new user account on this machine to see if the issue is
ongoing.
b) Try to fiddle more with the debugger to find the last python call in
the stack.

[richo]

I have an apology to make for wasting your time.

Further investigation demonstrates that it was evidently fiddling with
the Application Verifier that broke everything (although I installed it
during my debugging attempts- I'm guessing that something else in VS has
the same capabilities).

By disabling all tests the application runs, by reenabling them it stops
again.

I now have a few questions

1. How can the verifier add the flags to the loading mechanism to add
   the breaks? In that when I installed different versions/clean reinstall
   of the same version it was still broken. Clearly it doesn't patch the
   binary, but leaves a flag somewhere (???) about the binary?

2. OK by the looks of it I only had one question ;)

thanks for all your help!

[loewis]

See the section "How Does AppVerifier Work?" in

http://msdn.microsoft.com/en-us/library/aa480483.aspx

This doesn't answer your question fully, as it fails to explain how
precisely they hook into the app.

ISTM that they use the HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Image File Execution Options registry hook. For each
executable (such as python.exe), you can specify an alternative binary
that gets launched whenever somebody is asking to launch python.exe
(IIUC, by setting the "Debugger" value on the registry key). In case of
appverifier, they probably then load the original binary, do their entry
point rewriting, and start the binary.

There actually *is* a second question: what is it that AppVerifier
complains about? It may be useful to run Python in AppVerifier to detect
bugs - but any outcome of this is out of scope of this report, it seems.
If you are curious to look into this further, that would be much
appreciated.

[richo]

I looked into it a bit further.

With some trial and error I narrowed the source of the problem to be the
'KernelModeDriverInstall' option under compatibility. I believe this
isn't a problem, because python shouldn't be trying to install drivers,
and even if it needed to presumably that would be nested in something
loaded dynamically, rather than the original image so it could catch the
issue and deal with it.

I will try to reproduce this on another machine to double check my
logic. Thanks again for all your help Martin.