Import win32ui broken on Python 3.9

[m-rossi]

Expected behavior and actual behavior

Importing win32ui fails on Python 3.9

Steps to reproduce the problem

Install a version of Python 3.9, I used that from conda-forge:

conda create -n py39 python=3.9
conda activate py39
pip install pywin32
python

import win32ui
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed while importing win32ui: The specified module could not be found.

Version of Python and pywin32

Python 3.9.0 | packaged by conda-forge | (default, Oct 10 2020, 20:35:00) [MSC v.1916 64 bit (AMD64)] on win32

pip show pywin32
Name: pywin32
Version: 228

[evandrix]

bump

[s-h-a-u-n]

Similar issue with python 3.9 when installing 228 64bit from binaries and with 228 & 225 via PIP + post install script. win32ui is found but fails to import.

[evandrix]

nvm, i switched over to uiautomation, which works brilliantly for my use case, so going to abandon pursuing this further and get on with the rest of 2020.

[char101]

windbg traceback for LoadLibraryEx loading win32ui.pyd.

(5518.5d50): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
python39!_PyObject_GC_Alloc+0x11 [inlined in python39!_PyObject_GC_Malloc+0x20]:
00007ffe`77f2a450 488b5f10        mov     rbx,qword ptr [rdi+10h] ds:00000000`00000010=????????????????
0:000> k
 # Child-SP          RetAddr           Call Site
00 (Inline Function) --------`-------- python39!_PyObject_GC_Alloc+0x11 [C:\A\31\s\Modules\gcmodule.c @ 2215] 
01 000000a9`881ff450 00007ffe`77f2c3d6 python39!_PyObject_GC_Malloc+0x20 [C:\A\31\s\Modules\gcmodule.c @ 2252] 
02 000000a9`881ff480 00007ffe`77f3d6a0 python39!_PyObject_GC_NewVar+0x3a [C:\A\31\s\Modules\gcmodule.c @ 2281] 
03 (Inline Function) --------`-------- python39!tuple_alloc+0x5a [C:\A\31\s\Objects\tupleobject.c @ 92] 
04 (Inline Function) --------`-------- python39!PyTuple_New+0x63 [C:\A\31\s\Objects\tupleobject.c @ 110] 
05 000000a9`881ff4b0 00007ffe`77f3e0ab python39!do_mktuple+0x94 [C:\A\31\s\Python\modsupport.c @ 260] 
*** WARNING: Unable to verify checksum for R:\test_load\39\win32ui.pyd
06 (Inline Function) --------`-------- python39!va_build_value+0xa3 [C:\A\31\s\Python\modsupport.c @ 564] 
07 000000a9`881ff510 00000000`550921e0 python39!Py_BuildValue+0xbb [C:\A\31\s\Python\modsupport.c @ 519] 
08 (Inline Function) --------`-------- win32ui!PyCCtrlView_Type::{ctor}+0x67 [t:\test\test_pywin32\pywin32\pythonwin\win32control.h @ 30] 
09 000000a9`881ff560 00007ffe`cbbcbc0e win32ui!`dynamic initializer for 'PyCRichEditView::type''+0x70 [t:\test\test_pywin32\pywin32\pythonwin\win32richedit.cpp @ 225] 
0a 000000a9`881ff5b0 00000000`5510203f ucrtbase!initterm+0x3e
0b 000000a9`881ff5e0 00000000`55102191 win32ui!dllmain_crt_process_attach+0xbb [f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 67] 
0c 000000a9`881ff610 00007ffe`ce825021 win32ui!dllmain_dispatch+0x5d [f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 190] 
0d 000000a9`881ff670 00007ffe`ce869385 ntdll!LdrpCallInitRoutine+0x65
0e 000000a9`881ff6e0 00007ffe`ce869178 ntdll!LdrpInitializeNode+0x1b1
0f 000000a9`881ff820 00007ffe`ce82aa17 ntdll!LdrpInitializeGraphRecurse+0x80
10 000000a9`881ff860 00007ffe`ce822511 ntdll!LdrpPrepareModuleForExecution+0xbf
11 000000a9`881ff8a0 00007ffe`ce822228 ntdll!LdrpLoadDllInternal+0x199
12 000000a9`881ff920 00007ffe`ce8216e4 ntdll!LdrpLoadDll+0xa8
13 000000a9`881ffad0 00007ffe`cbcd5630 ntdll!LdrLoadDll+0xe4
*** WARNING: Unable to verify checksum for R:\test_load\39\test.exe
*** ERROR: Module load completed but symbols could not be loaded for R:\test_load\39\test.exe
14 000000a9`881ffbc0 00007ff6`58f81016 KERNELBASE!LoadLibraryExW+0x170
15 000000a9`881ffc30 00007ff6`58f812e8 test+0x1016
16 000000a9`881ffc70 00007ffe`cd677bd4 test+0x12e8
17 000000a9`881ffcb0 00007ffe`ce86ce51 KERNEL32!BaseThreadInitThunk+0x14
18 000000a9`881ffce0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

So what causes initialization failure is this line: https://github.com/mhammond/pywin32/blob/master/Pythonwin/win32control.h#L30 . Verified that if I comment out that line, win32ui loads fine.

Unfortunately I have no idea what those lines are doing so I cannot propose a fix.

[mhammond]

That's very helpful, thanks, and I can reproduce this in visual studio - I didn't consider that an exception was being caught and ignored. Turns out we aren't holding the GIL when we call back into Python - I've no idea why this is different in 3.9 vs other versions, but the fix is simple and is safe in all versions.

[char101]

Thank you.

This is a wheel package I built for anyone that need it until an official package is released (rename .zip to .whl):

pywin32-299.9-cp39-cp39-win_amd64.zip

[mhammond]

This is a wheel package I built for anyone that need it until an official package is released (rename .zip to .whl):

Thanks! Note that I just enabled 3.9 on CI, so every push will end up with wheels available as the artifacts of the CI run.

[CristiFati]

The .whls can also be found here: [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/PyWin32/v228.