search_for_prefix in PC/getpathp.c sets the wrong path when Python is started with a \\?\ path on Windows, which results in the following crash:
>>> subprocess.call(r'"\\?\C:\Program Files\Python36\python.exe"')
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'
Current thread 0x00000b40 (most recent call first):
3221226505
The problem is due to the implementation of join(), which calls PathCchCombineEx, which strips the \\?\ prefix from the joined path. Consequently in gotlandmark(), setting `prefix[n] = '\0'` nulls the wrong index because the value of n includes the original \\?\ prefix.
Breakpoint 0 hit
python36_d!gotlandmark:
00000000`6cc1a920 48894c2408 mov qword ptr [rsp+8],rcx
ss:000000c2`9a9ee920={python36_d!prefix (00000000`6cf697d0)}
1:005> du python36_d!prefix
00000000`6cf697d0 "\\?\C:\Program Files\Python36"
1:005> pc
python36_d!gotlandmark+0x15:
00000000`6cc1a935 e8e60a0000 call python36_d!wcsnlen_s (00000000`6cc1b420)
1:005> pc
python36_d!gotlandmark+0x2b:
00000000`6cc1a94b e890010000 call python36_d!join (00000000`6cc1aae0)
1:005> p
python36_d!gotlandmark+0x30:
00000000`6cc1a950 33d2 xor edx,edx
1:005> du python36_d!prefix
00000000`6cf697d0 "C:\Program Files\Python36\lib\os"
00000000`6cf69810 ".py"
1:005> pt
python36_d!gotlandmark+0x7b:
00000000`6cc1a99b c3 ret
1:005> du python36_d!prefix
00000000`6cf697d0 "C:\Program Files\Python36\lib"
I think the simplest solution is to remove the \\?\ prefix from the executable path that's returned by GetModuleFileNameW in get_progpath(). AFAIK, no version of Windows can reliably run programs from long paths, and the current MAXPATHLEN (256) doesn't allow it anyway. The only reason to use \\?\ for the executable path would be to avoid the normal DOS/Windows path normalization rules -- e.g. removing trailing dots and spaces or using DOS device names such as "con.exe". That's not really a practical concern.
|