Jeff Sanders Technical Blog

I am a Microsoft employee that has worked on all aspects of the Web Stack for a long time. I hope these blogs are useful to you! Use this information at your own risk.


<< Go Back

Winhttp Proxy Configuration On Windows 2003 X64

- 21 Jul 2009

You may get an error similar to this when running your WinHttp application:

Error: The server name or address could not be resolved
Code: 80072EE7
Source:  WinHttp.WinHttpRequest

The familiar ProxyCfg application allows you to set the proxy settings for WinHttp.  However in this case, your  application is not picking up the proxy settings.  You verify this by setting the Proxy settings to the current user by typing “proxycfg -p myproxyhere” at the command line and you see from a Netmon trace that the proxy is not being utilized. 

Further research shows your application is loading the 32 bit version of WinHttp.  In Windows 2003 x64, there is a directory for the 32 versions of the system components.  You need to run this version for your 32 bit application: c:\windows\sysWow64\proxycfg -p myproxyhere.  This fixes the issue.  In general, on this platform when using proxycfg.exe, you should run the version in system32 and the version in sysWow64 to ensure you set the proxy setting for both versions of WinHttp on the system.

Side note on WinHttp COM registration on Windows 2003 x64

One thing interesting in the default installation of the 64 bit OS is that you will notice WinHttp.dll does not live in either the system32 or the sysWow64 directories.  Also, if you look in the registry under HKCR\CLSID you will see no entry for WinHttp.WinHttpRequest.5.1.  So how does a script succeed that calls CreateObject() on your progId?  The magic here is the SideBySide (SxS) registration of WinHttp.  You will notice there are WinHttp Dlls in the C:\WINDOWS\WinSxS\ subdirectories.  You will also see in C:\WINDOWS\WinSxS\Manifests there are manifest files and the file names contain WINHTTP in them.  Without going into a ton of detail, what happens is CLSIDFromProgID will take the name of the object you are creating and based on the Bitness of the application (64 or 32) there are internal system calls to find the latest version of winhttp and use that for the creation of the object.

That is why you cannot find the ProgID in the registry!

Let me know if this blog helped you out by dropping me a comment please!

<< Go Back