Blair Hall
2014-12-11 22:58:27 UTC
Thanks for your answer
Visual Studio 2008 still used the stupid "side-by-side" DLL installation
Walker log:
LoadLibraryExW("server.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH)
called from "c:\windows\syswow64\REGSVR32.EXE" at address 0x00B720FF by
thread 1.
Loaded "c:\proj_py\gtxl\vba\dist_a\SERVER.DLL" at address 0x10000000 by
thread 1. Successfully hooked module.
Loaded
"c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.DLL"
at address 0x74580000 by thread 1. Successfully hooked module.
I see this in the logs obtained when registering both versions of my DLL
(one complied on each machine).
However, in the log of the version that fails I see this a little later on
LoadLibraryA("msvcr90.dll") called from
"c:\proj_py\gtxl\vba\dist_b\_CTYPES.PYD" at address 0x1D1A9742 by thread 1.
Loaded "c:\program files (x86)\intel\icls client\MSVCR90.DLL" at
address 0x59090000 by thread 1. Successfully hooked module.
So, for some reason this other version is also being loaded. That leads to
subsequent errors.
When I hide the intel files I see this instead of the above (and, although
the second line shows an error, the DLL registration proceeds successfully)
LoadLibraryA("msvcr90.dll") called from
"c:\proj_py\gtxl\vba\dist_b\_CTYPES.PYD" at address 0x1D1A9742 by thread 1.
LoadLibraryA("msvcr90.dll") returned NULL by thread 1. Error: %1 is not
a valid Win32 application (193).
I don't know what to make of this. Why would the LoadLibrary call from
_ctypes.pyd not be directed to the DLL in winsxs as well?
Visual Studio 2008 still used the stupid "side-by-side" DLL installation
technique. What that means is that compiler doesn't just embed a link
to MSVCR90.dll -- it embeds a link to a specific version of
MSVCR90.dll. (As of today, there are SIX such versions.) Side-by-side
DLLs are intended to be installed centrally, in the \Windows\WinSxS
directory tree. If the version you need is in the central repository,
it will use that one. Otherwise, it looks elsewhere, including in a
subdirectory of the application, assuming the manifest allows that.
So, the likely story here is that one of your machines has the latest
Visual Studio 2008 Redistributable Runtime installed, and the other does
not.
I don't think this is the issue. Here is a excerpt from the Dependencyto MSVCR90.dll -- it embeds a link to a specific version of
MSVCR90.dll. (As of today, there are SIX such versions.) Side-by-side
DLLs are intended to be installed centrally, in the \Windows\WinSxS
directory tree. If the version you need is in the central repository,
it will use that one. Otherwise, it looks elsewhere, including in a
subdirectory of the application, assuming the manifest allows that.
So, the likely story here is that one of your machines has the latest
Visual Studio 2008 Redistributable Runtime installed, and the other does
not.
Walker log:
LoadLibraryExW("server.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH)
called from "c:\windows\syswow64\REGSVR32.EXE" at address 0x00B720FF by
thread 1.
Loaded "c:\proj_py\gtxl\vba\dist_a\SERVER.DLL" at address 0x10000000 by
thread 1. Successfully hooked module.
Loaded
"c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.DLL"
at address 0x74580000 by thread 1. Successfully hooked module.
I see this in the logs obtained when registering both versions of my DLL
(one complied on each machine).
However, in the log of the version that fails I see this a little later on
LoadLibraryA("msvcr90.dll") called from
"c:\proj_py\gtxl\vba\dist_b\_CTYPES.PYD" at address 0x1D1A9742 by thread 1.
Loaded "c:\program files (x86)\intel\icls client\MSVCR90.DLL" at
address 0x59090000 by thread 1. Successfully hooked module.
So, for some reason this other version is also being loaded. That leads to
subsequent errors.
When I hide the intel files I see this instead of the above (and, although
the second line shows an error, the DLL registration proceeds successfully)
LoadLibraryA("msvcr90.dll") called from
"c:\proj_py\gtxl\vba\dist_b\_CTYPES.PYD" at address 0x1D1A9742 by thread 1.
LoadLibraryA("msvcr90.dll") returned NULL by thread 1. Error: %1 is not
a valid Win32 application (193).
I don't know what to make of this. Why would the LoadLibrary call from
_ctypes.pyd not be directed to the DLL in winsxs as well?