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

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

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

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.

What kind of action has triggered that crash?

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.

> No action- the interpreter fails to start.

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

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).

Nope- 2.6.4 fails in the same way.

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

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.

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

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)?

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.

> 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.

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?

yes, please do

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 :)

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: 00000000`1d000000 00000000`1d00b000   pythonw.exe
ModLoad: 00000000`76f20000 00000000`770cb000   ntdll.dll
ModLoad: 00000000`76e00000 00000000`76f1f000  
C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd1e0000 000007fe`fd24b000  
C:\Windows\system32\KERNELBASE.dll
ModLoad: 00000000`1e000000 00000000`1e2b0000  
C:\Windows\system32\python31.dll
ModLoad: 00000000`76d00000 00000000`76dfa000  
C:\Windows\system32\USER32.dll
ModLoad: 000007fe`ff1c0000 000007fe`ff227000   C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`ff1b0000 000007fe`ff1be000   C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fd380000 000007fe`fd44a000   C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fdb30000 000007fe`fdbcf000  
C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fda50000 000007fe`fdb2b000  
C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fdd00000 000007fe`fdd1f000  
C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fd250000 000007fe`fd37e000  
C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fdf00000 000007fe`fec86000  
C:\Windows\system32\SHELL32.dll
ModLoad: 000007fe`fec90000 000007fe`fed01000  
C:\Windows\system32\SHLWAPI.dll
ModLoad: 00000000`730a0000 00000000`7313d000  
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:
00000000`76fd1220 cc              int     3
0:000> g
ModLoad: 000007fe`fcd50000 000007fe`fcda7000  
C:\Windows\system32\apphelp.dll
ModLoad: 000007fe`fd810000 000007fe`fd83e000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fed90000 000007fe`fee99000   C:\Windows\system32\MSCTF.dll
ntdll!NtTerminateProcess+0xa:
00000000`76f7017a 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

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.

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

> 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.

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.

> 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...

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.

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.

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!

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.

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.