Freigeben über

WinHttp Proxy configuration on Windows 2003 x64

  • Artikel

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!

Comments

  • Anonymous
    April 09, 2010
    In 2008 proxycfg has been assimilated into netsh. The rest of this blog entry still applies.

  • Anonymous
    July 22, 2010
    Thanks, your post really helped me.

  • Anonymous
    February 09, 2012
    So using netsh winhttp will make all the the calls going through 80 and 443 use the proxy? I have a windows application that needs to go through the proxy for internet facing domains, but the application doesn't have an option for proxy.

  • Anonymous
    February 09, 2012
    netsh or proxycfg sets the WinHttp proxy for applications that don't explicitly set the proxy in code themselves.

  • Anonymous
    February 26, 2012
    Will IE inherit the porxy settings too from WinHttp, without explicitly defining the Proxy in the IE Options.

  • Anonymous
    November 08, 2013
    No. IE is WinInet. WinHTTP is a separate API. You use netsh for Windows Server 2008+ while proxycfg for Windows Server 2003.