Basically I think this is a bug in Windows Server 2008, but I am not a COM ninja so it seems equally likely that I'm just doing something dumb. The question is: bug or programmer error?
We use WinHttpRequest (the ActiveX component of WinHttp) to read http:// and https://. The ProgID we are using to look up the component is WinHttp.WinHttpRequest.5.1
.
Our application worked fine on XP and Windows Server 2003. Under Windows Server 2008 we would get an error (0x800029C4A "Error loading type library/DLL"
) loading the type library. Re-registering winhttp fixes the issue. The question is, why?
After numerous deadends, I found the following in the registry.
Windows 2008 Server SP2 as installed:
Name=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{662901FC-6951-4854-9EB2-D9A2570F2B2E}\5.1\0\win32=%SystemRoot%\system32\winhttp.dll
Type=REG_SZ
Data=%SystemRoot%\system32\winhttp.dll
After calling regsvr32 %SystemRoot%\System32\WinHttp.dll
, this key changes value:
Name=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{662901FC-6951-4854-9EB2-D9A2570F2B2E}\5.1\0\win32
Type=REG_SZ
Data=C:\Windows\system32\winhttp.dll
My understanding is that keys of type REG_EXPAND_SZ
expand system paths like %SystemRoot%
but REG_SZ
do not. So either the type should be REG_EXPAND_SZ
, or the expanded path should be used. Re-registering WinHttp fixes the path and thus fixes WinHttpRequest. (As far as I can tell, XP used C:\Windows\System32\winhttp.dll
and Server 2003 used a SxS install that works for me>0
So I think this is a bug, and I filed a bug with Microsoft (or at least as much as I could do from the swamp that is connect.microsoft.com.) But here's the part I don't get: since Windows Server 2008 and Vista are very similar, it seems likely that this issue is present in Vista also. WinHttpRequest has got to be a commonly used object. The masses should be screaming, but after lots of googling I found only one thread where people encountered this problem.
Re-registering winhttp fixes the issue, so that's what we're doing. I'm posting this because a) I just can't believe that it is best practice to re-register this commonly-used component and b) if it is a bug, maybe this will help somebody else.
-Rob