Http Client Protocol Issues : WinHttp

WinHttp Proxy configuration on Windows 2003 x64

jpsanders — Tue, 21 Jul 2009 20:42:00 GMT

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!

How to enable WinHttp Tracing on Vista, 2008 and Windows 7

jpsanders — Thu, 28 May 2009 20:47:00 GMT

WinhttpTracecfg.exe for Vista does not exist, so how can you get a WinHttp trace in Vista and above?

WinHttpTraceCfg.exe has been replaced in Vista and above with the netsh winhttp command.
see this blog:
http://blogs.msdn.com/wndp/archive/2007/03/21/winhttp-configuration-for-windows-vista.aspx

A typical command to enable full tracing for WinHttp would look like this:

C:\Windows\system32>netsh winhttp set tracing trace-file-prefix="C:\Temp\WinHttpLog" level=verbose format=hex state=enabled

You would reproduce the issue and then turn off tracing like this:

C:\Windows\system32>netsh winhttp set tracing state=disabled

This would leave the other parameters you set previously to remain so the next time you want to enable tracing simply type:

C:\Windows\system32>netsh winhttp set tracing state=enabled

Other parameters are available:

C:\Windows\system32>netsh winhttp set tracing

will show you the options:

Parameters:

Tag                   Value
trace-file-prefix   - Prefix for the log file (can include a path)
                        specify "*" to delete an existing prefix
output              - Where the trace entries are written/displayed to
level               - How much information to log
format              - Display format of network traffic (hex or ansi)
max-trace-file-size - Maximum size of the trace file (in bytes)
state               - Enables or disables winhttp tracing

Examples:

set tracing trace-file-prefix="C:\Temp\Test3" level=verbose format=hex
set tracing output=debugger max-trace-file-size=512000 state=enabled

You can display the existing settings with this command:

C:\Windows\system32>netsh winhttp show tracing

Current WinHTTP Tracing settings:

Tracing is not enabled.

    Trace File Prefix: C:\Temp\Test3
    Trace Output: file
    Trace Level: verbose (headers, APIs, and entity body)
    Network Traffic Format: hex
    Maximum size of trace file (in bytes): 65535

Let me know if this helps!

Troubleshooting code that uses the HTTP protocol

jpsanders — Wed, 25 Jun 2008 21:02:00 GMT

Overview

You can solve issues encountered when using the HTTP protocol by applying the principles in this article. By simplifying the issue into a small reproducible problem you can effectively troubleshoot and resolve most problems encountered in code that uses the HTTP protocol. Crucial steps to troubleshooting code are: Gather Information, Simplify the Problem and Detailed Troubleshooting.

Technologies Covered

WinHttp, WinInet, Internet Explorer, XMLHTTP (MSXML), ServerXMLHTTP, System.Net classes such as WebClient, HttpWebRequest, SOAP classes, WebServices, System.Xml classes such as XmlUrlResolver, SoapHttpClientProtocol.

Error Messages Encountered (so search will find this document)

The operation timed out, 80072EE2, -2147954402, ERROR_WINHTTP_TIMEOUT, ERROR_WINHTTP_INVALID_SERVER_RESPONSE, The server name or address could not be resolved, 0x80072EE7, -2147012889, ERROR_WINHTTP_NAME_NOT_RESOLVED, 0x80072EFD

-2147012867, A connection with the server could not be established, -2146697208 (800c0008), The download of the specified resource has failed, Cannot connect to Remote server, Access is Denied, System error: -2146697191, 401, 500, 407, Server refused connection, Http protocol violation, Unauthorized, Cannot find server.

Step 1. Gather Information

You may solve the issue or get close to the root cause quickly by gathering information about the problem. Then you can continue to the Simplify the Problem section of this document to further isolate the issue and determine where the problem is occurring. Do this only after Gathering the information listed below.

1. What HTTP Verb are you using (EX: GET, POST, PUT)?

2. What is the destination URL?

3. Did this ever work? What changed if it did work previously (moved to production server, applied Service pack or Anti Virus update)?

4. What technology are you using to reach the URL that fails?

5. Can you reach the destination URL with another Technology such as Internet Explorer, other Browser, scripted Http Components, a simple console application?

6. Can you reach ANY URL from the computer (Perhaps DNS is not set, ports blocked, or you need a proxy setting)?

7. What is the failure (exact error message)?

8. What is the call stack of the failure?

9. Is this a Desktop or service based application (ASP and ASP.NET is a service)?

10. Are you running with the latest Service Packs and fixes etc…(Go to Windows Update)?

Step 2. Simplify the Problem

Armed with the answers from Step 1, reproduce the problem with the simplest code possible. In the process of simplifying the issue you may discover the issue is not in the technology you are using but a problem being obscured by your program’s logic or system configuration. For example, In one case I assisted in, numerous troubleshooting actions had been taken in the ASP pages to determine what was going wrong. When I was brought in to assist, I simply asked, “Can you hit the target URL in a Browser”? The answer (“no”) instantly revealed to all of us that the issue was the DNS server setting on that machine and not the code.

How to simplify the issue:

1. Duplicate the issue with a technology that is easier to troubleshoot such as the Web Browser or System.Net 2.0 which has the ability to log the HTTPS traffic.

2. If the problem occurs with HTTPS, see if you can reproduce with HTTP as well then troubleshoot HTTP traffic instead of HTTPS traffic (which is securely encoded). If you cannot duplicate the issue with HTTP then the problem may lie with your HTTPS configuration.

3. If this is a service based application, such as ASP or ASP.NET, move the code out of the Service and test. If it works, then the issue is not with the technology you are using. The issue is how you have your service configured or the context it is running in.

4. Try simple code from script or a command line application to see if that succeeds. Then use that same simple code in your application and test. If it fails in either case you have a much smaller problem to deal with.

5. Simplify the code by executing the simplest possible HTTP call in a command line script or console application. Start with using a HEAD or GET verb to a resource (perhaps an image or static file on the server) and add complexity until you get the failure.

Below are some code samples you can use to simplify the problem. Simplify! For example if your application is doing a POST verb, start with a GET verb to start your troubleshooting and then only if you cannot duplicate the issue using the GET verb, move to the POST verb.

VBScript samples:

Dim aRequest

Set aRequest = CreateObject ("Microsoft.XMLHTTP")

aRequest.Open "GET","http://www.microsoft.com/",False

aRequest.Send