MSXML3.dll 80072efd and 800c0005 errors executing ServerXMLHTTP.send in classic ASP on Windows 7

Question

I have a classic ASP page that I am trying to debug on IIS on Windows 7. The page works fine on another machine running Windows Server 2003 on a different network. Also, on the Windows 7 machine I can successfully open the URL in question in a browser.

The page fails when executing ServerXMLHTTP.send() with the error:

msxml3.dll error '80072efd'
A connection with the server could not be established 

The code in question looks like this (the last line is failing):

set xmlHTTP = server.CreateObject("MSXML2.ServerXMLHTTP")
xmlHTTP.open "get", "http://stackoverflow.com", False
xmlHTTP.send

I have searched around and the most helpful looking suggestion was to use NetSh to set a proxy for winHTTP. The machine with problems is on a network which does use a proxy server. However, even after setting the proxy and rebooting I still get the same error.

Changing

set xmlHTTP = server.CreateObject("MSXML2.ServerXMLHTTP")

to

set xmlHTTP = server.CreateObject("MSXML2.XMLHTTP")

yields a slightly different error:

msxml3.dll error '800c0005'
The system cannot locate the resource specified.

I've also tried installing MSXML4 SP3 and explicitly creating a v4 object using:

set xmlHTTP = server.CreateObject("MSXML2.ServerXMLHTTP.4.0")

I still get the same errors except with msxml4.dll in the message.

Finally I tried turning off my Forefront TMG proxy client, telling my browser not to use a proxy, and using netsh to reset the proxy for winHTTP. Still the same errors even though the browser can still access the internet.

From what I've found I reckon this must be an issue with connectivity from this particular machine over the particular network it is on. However, I have no idea what the problem is. Any suggestions gratefully received.

Answer 1

Solved it for my case, there are plenty of other reasons you might get this error though. The short answer for me was: Check the user the Classic .Net AppPool is running as and make sure your network allows them internet access.

I downloaded Microsoft Network Monitor and looked at the traffic during a failure. The only traffic that might have been related was all going to our proxy server and consisted of a failed attempt to authenticate.

I then checked the app pools in IIS and sure enough the Classic .Net AppPool was set to use a local machine account that wasn't being recognised by the proxy. Changing the account to use to a domain account fixed the error.