That sounds good. I will check it out. The "last-writer-wins" policy does not seem to be in effect because I can just recompile the client in 32 or 64-bit mode and it always calls the matching bit-ness version of the COM EXE.
I will make sure there is no 64-bit COM adapter with that name/CLSID/GUID and see what happens.
Thanks!
Ed
Main Topics
Browse All Topics





by: Gideon7Posted on 2009-08-10 at 05:14:58ID: 25059163
There is no magic call. The choice of COM process server is determined solely by the registry (HKEY_CURRENT_USER\CLSID and HKEY_LOCAL_MACHINE\CLSID). You might be running into some confusion because multiple 32-bit and 64-bit proxy server DLLs for the same CLSID might be registered different hives of HKEY_CLASSES_ROOT with registry reflection in coming into play.
Registry reflection occurs on on W2K3 x64, Vista x64 and W2K8 x64. It copies the LocalServer32 entry between the 64-bit and 32-bit registry hives. It uses a last-writer-wins policy. So whichever side (32-bit or 64-bit) last wrote the LocalServer32 value will get reflected into the other hive and 'win'. See http://msdn.microsoft.com/ en-us/libr ary/aa3841 82.aspx and http://msdn.microsoft.com/ en-us/libr ary/aa3841 82.aspx
To add to the confusion HKEY_CURRENT_USER\CLSID can also be reflected and can override HKLM keys.
(Registry reflection is a confusing hack. It has been removed from WIndows 7 x64 and W2K8R2 x64.)
Carefully check HKEY_LOCAL_MACHINE\Softwar e\CLSID\{G UID} and HKEY_LOCAL_MACHINE\Softwar e\Wow6432N ode\CLSID\ {GUID}. Verify that the both point to the desired target server path. Also check under HKEY_CURRENT_USER. If you are using a custom proxy DLL also check its GUID for InprocServer32 to make sure it is pointing to the right DLL.
Good luck!