'win32com.server.register.UseCommandLine(class)' InprocServer32 bug with office 64bit

[tsiank]

I use 'win32com.server.register.UseCommandLine(class)' to register COM server so that excel VBA can call python. But when I open excel with VBA code (excel workbook_open event), excel crash immediately. I serch Registry and find subkey InprocServer32 under registered python COM server of HKEY_CLASSES_ROOT\CLSID. According to https://docs.microsoft.com/en-us/windows/win32/com/inprocserver32 , it says InprocServer32 Registers a 32-bit in-process server and specifies the threading model of the apartment the server can run in. Because my python is 64bit and my excel is also 64bit, so I try to modify inprocserver32 to inprocserver , and it works!

Then I find related sorce code in register.py Line 234:

_set_subkeys(keyNameRoot + "\\InprocServer32", { None : dllName, "ThreadingModel" : threadingModel, }) else: # Remove any old InProcServer32 registrations _remove_key(keyNameRoot + "\\InprocServer32")

I modify InprocServer32 to InprocServer and register COM server again, this time I can normally open my excel and doesnot crash any more.

Please consider to fix it , thank you.

• Version of Python and pywin32:
  python 3.8 64bit , pywin32 228 64bit, office 365 64bit , office 2016 64bit, win10 64bit

[mhammond]

According to https://docs.microsoft.com/en-us/windows/win32/com/inprocserver32 , it says InprocServer32 Registers a 32-bit in-process server and specifies the threading model of the apartment the server can run in.

I think the reference to "32bit" there is because the page is very old. Further down it says "The InprocServer entry is needed only for backward compatibility. If it is missing, the class still works but it cannot be loaded in 16-bit applications." and discusses other differences between 16bit and 32bit objects - but nothing about 32bit vs 64bit.

Also, according to https://docs.microsoft.com/en-us/windows/win32/com/inprocserver, "The 32-bit and 64-bit in-process servers should use the InprocServer32 entry" and then also goes on to imply that inprocserver is actually for the ancient 16bit objects. Because of the registry redirection in 64bit systems (ie, the Wow6432Node node), it's possible for both 32bit and 64bit servers to register using InprocServer32 without conflict.

COM objects currently work fine on 64bit Windows, so I'm not sure what your problem is exactly, but I can't find any documentation or evidence that using InprocServer instead of InprocServer32 on 64bit system is the correct thing to do. I'm going to close this, but if you can find any further evidence that this should be changed, let me know and we can reopen it.

[Greedquest]

@mhammond See the comments on this SO question I posted;

Under HKCR\CLSID\{clsid}\LocalServer32 we have full path to pythonw.exe and full path to localserver.py whereas HKCR\CLSID\{clsid}\InprocServer32 only has the name of the pythoncomXX.dll without the full path.

IIUC the 64-bit inproc server is used by 64-bit clients (like Excel), whereas COM marshalling allows the out-of-proc server to be run under 32/64-bit. So if pythoncomXX.dll isn't on the path & the full path isn't given then deleting/renaming the InprocServer32 key to anything* (see #1691 second comment) will cause the 64 bit process to fall back to an out of proc server.

So if python / various dlls aren't on the PATH, the inproc server will fail, the out of proc server will succeed as it uses fully qualified paths. This may be true for particular python installations like Anaconda which require the environment to be activated to populate PATH at runtime.

*_{i.e. renaming specifically to InprocServer is a red herring}

[mhammond]

So if python / various dlls aren't on the PATH, the inproc server will fail, the out of proc server will succeed as it uses fully qualified paths.

Right! Thanks for opening #1704 - will be fixed in the next release.