[python-win32] COM server registering, but getting "The specified module could not be found" on dispatch

[Mark Hammond]

On 19/12/2012 2:39 AM, Russell Warren wrote:
> On Mon, Dec 17, 2012 at 10:25 PM, Mark Hammond
> <mhammond at skippinet.com.au <mailto:mhammond at skippinet.com.au>> wrote:
>
>     The VS2008 redistributables should probably be in the same directory
>     (ie, msvc*90*.dll in system32) or else they might not be loaded.  If
>     you use the "depends" tool from MS/sysinternals, you will see both
>     Python itself and pythoncom depend on this.
>
>
> I ran the depends tool [1] and sure enough, pythoncom27.dll has 3
> missing dependencies: MSVCR90.DLL; IESHIMS.DLL; and WER.DLL
>
> Screencap with additional errors here:
> http://static.inky.ws/image/3530/Selection_249.png
>
> Strangely, you can see in the screencap that MSVCR90.DLL is picked up
> with no issues at all by python27.dll (version issues, maybe?!).
>   Separate depends analysis of python27.dll does show the other 2 missing.
>
>     Actually, assuming you are using a recent pywin32, pycomloader27.dll
>     should also exist in that dir and should actually be used internally
>     to load the COM object - this was done primarily as a work-around
>     for exactly this problem.
>
>
> Nope - no pycomloader27.dll.  Possibly this has not made it into the
> latest ActiveState release?  I'll try a full install from pip.  The only
> other python dll was pywintypes27.dll.

Maybe try a stand-alone pywin32 - as mentioned, pycomloader27.dll exists 
purely to work around this kind of problem.

>     What matters is the complexity in how dependent DLLs are loaded - as
>     the DLL COM object is loaded by some other app, the rules as applied
>     to that app gets used for resolving DLL references.  The COM object
>     as a .exe is its own app.
>
>
> Thanks - I think I get it.  To paraphrase: You're saying that the
> dependency issues still exist in the internals of the localserver.py
> LocalServer32 implementation, but dependency loading is deferred and
> there are no pre-checks.  ie: it may fall flat during runtime at some
> point when a dependency is truly needed.  For the inproc version, the
> windows internals that are loading the pythoncom27.dll are pre-loading
> (or pre-checking) dependencies and crashing before it even gets started.
>   Correct?

Sadly it is a little more complicated than that.  Each .exe has its own 
"context" for resolving DLLs, and this context is inherited by other 
DLLs loaded in the process.  The Python DLL (and the pycomloader DLL) 
jump through alot of hoops to arrange for their own context to be setup 
so we don't depend on the context of the loading .exe.  When a inproc 
impl is used without pycomloader, the context of the embedding process 
is used (which is hard to predict).  A localserver impl has its own 
context (as it is a .exe) so doesn't strike the same problem.

Indeed, pycomloader exists purely to jump through those context hoops - 
all it does is setup the context appropriately then call the pythoncom 
DLL (and those hoops can't be put into pythoncomxx.dll or things would 
go pear-shaped when that DLL is loaded by python itself).

Cheers,

Mark
>
> Thanks very much for the tips.  I'll try and chase down these weird DLL
> issues now.
>
> Russ
>
> [1] For anyone else landing here, 'depends' is available here (not
> sysinternals): www.dependencywalker.com <http://www.dependencywalker.com/>
>