[python-win32] A tale of two COM servers (same py code works differently)

[Tim Roberts]

Jim Bell wrote:
> I have two COM servers. One works, the other doesn't, using the same
> python client code, which seems to work differently behind the scenes.
> I'm profiling both with SysInternals' ProcMon. Windows7x64, running
> 32-bit python 2.7.3. The python code isn't much more than:
>
>     import sys, os
>     import win32.client
>
>     cli = win32.client.Dispatch('Server.Application.1') #
> 'Broken.Application.1')
>
> Profile for python client, working server:
> 1.  Looks for 'Working.Server.1' in HKCU\Software\Classes, doesn't
> find it.
> 2.  Looks for it in HKCR\Working.Server.1, finds it.
> 3. Gets CLSID from above CLSID subkey.
> 4.  Looks for CLSID in HKCU\Software\Classes\Wow6432Node, doesn't find it.
> *5. Looks for it in HKCR\Wow6432Node\CLSID\{8...}, finds it.*
> 6. Dispatch() succeeds and we carry on...
>
> Profile for python client, broken server:
> 1.  Looks for 'Broken.Application.1' in HKCU\Software\Classes, doesn't
> find it.
> 2.  Looks for it in HKCR\Broken.Application.1, finds it.
> 3. Gets CLSID from above CLSID subkey.
> 4. Looks for CLSID in HKCR\CLSID\{4...}, doesn't find it.
> *5. **Stops looking and gives up, **throwing pywintypes.com_error:
> (-2147221164, 'Class not registered', None, None)*
>
> So why does it stop looking for one but keep looking for the other?

Are you absolutely sure that the Python client on the broken server is
using a 32-bit Python?  64-bit processes are not subjected to the
registry redirection.

Is the broken server running the application as a service, or in an
elevated context, or in a scheduled task that is running as the system user?

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20131218/1ade70f4/attachment.html>