`win32process.GetWindowThreadProcessId` returning `[0, 0]` when `ctypes.windll.user32.GetWindowThreadProcessId` works fine

[huntfx]

Expected behavior and actual behavior

I've found a case where pywin32 fails to get a process ID when ctypes manages. I've been running this code for 6+ years and have never seen it happen before, so I'm afraid the only way I know how to reproduce this is with Helldivers 2.

Passing the window handle of Helldivers 2 to win32process.GetWindowThreadProcessId to get its process ID will return [0, 0], but with ctypes.windll.user32.GetWindowThreadProcessId it returns the correct process ID.

For any other process these two values are always the same.

Steps to reproduce the problem

>>> def get_pid_ctypes(hwnd):
...     process_id = ctypes.c_ulong()
...     ctypes.windll.user32.GetWindowThreadProcessId(hwnd, ctypes.byref(process_id))
...     return process_id.value

>>> def get_pid_pywin32(hwnd):
...     return win32process.GetWindowThreadProcessId(hwnd)[1]

>>> hwnd = win32gui.FindWindow(None, 'HELLDIVERS™ 2')
>>> hwnd
5245634 
>>> get_pid_ctypes(hwnd)
210628 
>>> get_pid_pywin32(hwnd)
0

1. Load Helldivers 2
2. Get its window handle
3. Attempt to get the PID via win32process.GetWindowThreadProcessId
4. It returns [0, 0]

For the sake of linking issues, I created huntfx/mousetracks#65 on my own project before finding that the ctypes method worked.

System information

Python version and distribution:

Python 3.7.9 Python 3.11.8

pywin32 version:

300 for 3.7 308 for 3.11

Windows Version:

10.0.19045 Build 19045

DLL locations:

C:\Users\Peter\AppData\Roaming\Python\Python311\site-packages\pywin32_system32\pywintypes311.dll C:\Users\Peter\AppData\Roaming\Python\Python311\site-packages\pywin32_system32\pythoncom311.dll

[mhammond]

That's odd. That's defined by "swig", so I think a build will have a win32process_module.cpp or similar - I don't have access to that file currently 😅 But I can't see an obvious reason this might be broken.

[huntfx]

I found that if the script is built as an executable with pyinstaller, then ctypes also breaks. The game has anti cheat, so perhaps it could be related to that?

It's weird how pywin32 has slightly different behaviour, but I'm not sure if it's in your control, so if not then feel free to close this.