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, t...@probo.com
Providenza & Boekelheide, Inc.
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
