| msg94467 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-25 23:29 |
| 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 |
|
|
| msg94468 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2009-10-25 23:57 |
| What is "LuaPriv" in that log? Something you installed? (sorry, not a Windows specialist) |
|
|
| msg94471 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-26 01:36 |
| 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 |
|
|
| msg94472 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-26 02:54 |
| 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. |
|
|
| msg94473 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-10-26 05:32 |
| What kind of action has triggered that crash? |
|
|
| msg94474 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-26 05:45 |
| 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. |
|
|
| msg94477 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-10-26 07:53 |
| > No action- the interpreter fails to start. How precisely do you start the interpreter (and what interpreter precisely)? |
|
|
| msg94532 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-26 22:36 |
| 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). |
|
|
| msg94533 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-26 22:40 |
| Nope- 2.6.4 fails in the same way. |
|
|
| msg94536 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-10-26 22:49 |
| FWIW, these all run fine on my copy of Windows 7. |
|
|
| msg94537 - (view) |
Author: Rich Healey (richo) |
Date: 2009-10-26 22:57 |
| 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. |
|
|
| msg94844 - (view) |
Author: Carey (pR0Ps) * |
Date: 2009-11-02 21:03 |
| 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 |
|
|
| msg94848 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-11-02 21:26 |
| 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)? |
|
|
| msg94849 - (view) |
Author: Carey (pR0Ps) * |
Date: 2009-11-02 21:37 |
| 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. |
|
|
| msg94850 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-11-02 21:44 |
| > 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. |
|
|
| msg94877 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-04 03:34 |
| 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? |
|
|
| msg94889 - (view) |
Author: Carey (pR0Ps) * |
Date: 2009-11-04 14:43 |
| yes, please do |
|
|
| msg94910 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-04 23:37 |
| 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 :) |
|
|
| msg94912 - (view) |
Author: Carey (pR0Ps) * |
Date: 2009-11-05 01:30 |
| 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 |
|
|
| msg94914 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-05 01:47 |
| 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. |
|
|
| msg94916 - (view) |
Author: Carey (pR0Ps) * |
Date: 2009-11-05 02:38 |
| python.exe works fine. It's IDLE that doesn't work and it uses pythonw.exe. |
|
|
| msg94918 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-11-05 04:46 |
| > 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. |
|
|
| msg94921 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-05 06:24 |
| 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. |
|
|
| msg94923 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-11-05 08:11 |
| > 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... |
|
|
| msg94929 - (view) |
Author: Carey (pR0Ps) * |
Date: 2009-11-05 13:48 |
| 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. |
|
|
| msg95410 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-18 05:38 |
| 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. |
|
|
| msg95412 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-18 05:46 |
| 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! |
|
|
| msg95413 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-11-18 06:13 |
| 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. |
|
|
| msg95462 - (view) |
Author: Rich Healey (richo) |
Date: 2009-11-19 02:57 |
| 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. |
|
|