.NET proxy detection

Question

I am having an issue with .NET detecting the proxy settings configured through internet explorer.

I'm writing a client application that supports proxies, and to test I set up an array of 9 squid servers to support various authentication methods for HTTP and HTTPs. I have a script that updates IE to whichever configuration I choose (which proxy, detection via "Auto", PAC, or hardcode).

I have tried the 3 methods below to detect the IE configuration through .NET. On occassion I notice that .NET picks up the wrong set of proxy servers. IE has the correct settings, and if I browse the web with IE, I can see I am hitting the correct servers via wireshark.

WebRequest.GetSystemWebProxy().GetProxy(destination);

GlobalProxySelection.Select.GetProxy(destination);

WebRequest.DefaultWebProxy

Here are the following tips I have:

• My script sets a PAC file on a webserver, and updates the configuration in IE, then clears IE's cache
• .NET seems to get "stuck" on a certain proxy configuration, and I have to set another configuration for .NET to realize there was a change. Occasionally it seems to pick some random set of servers (I'm sure they're not random, just a set of servers I used once and are in some cached PAC file or something). As in, I will check the proxy for the destination "https://www.secure.com" and I may have IE configured for and thus expect to get "http://squidserver:18" and instead it will return "http://squidserver:28" (port 18 runs NTLM, 28 runs without authentication). All the squid servers work.
• This does not appear to be an issue on XP, only Vista, 2003, and windows 7.
• Hardcoding the proxy servers in IE ALWAYS works
• Time always solves the issue - if I leave the computer for about 20 or 30 minutes and come back, .NET picks up the correct proxy settings, as if a cached PAC script expired.

Answer 1

I found the solution.

.NET uses the "WinHttp Web Proxy Auto Discovery Service" to perform PAC script execution, and probably caches the results. Simply stopping and restarting this service does the trick. The following command line does this for me.

NET STOP WinHttpAutoProxySvc
NET START WinHttpAutoProxySvc

http://wiki.blackviper.com/wiki/WinHTTP_Web_Proxy_Auto-Discovery_Service

I found this by following James Kovacs' suggestion of attaching the debugger. I had already reflected through the code and made a failed attempt to attach a debugger before I ever posted the question, but could not decipher exactly what was happening. Running out of options, I tried debugging again, and after several hours found the following comment in _AutoPWebProxyScriptEngine.cs on line 76 that led me to this discovery

        // In Win2003 winhttp added a Windows Service handling the auto-proxy discovery. In XP using winhttp
        // APIs will load, compile and execute the wpad file in-process. This will also load COM, since 
        // WinHttp requires COM to compile the file. For these reasons, we don't use WinHttp on XP, but
        // only on newer OS versions where the "WinHTTP Web Proxy Auto-Discovery Service" exists.