How to debug WinHTTP API proxy detection

Hi @MSDN_userSince1994_newaccount2023 ,

Thanks for reaching out.

You’re not overlooking anything obvious here - WinHTTP proxy auto-detection is genuinely difficult to debug, and the available documentation doesn’t clearly describe how to observe what’s happening internally, especially on newer versions of Windows.

One important thing to set expectations upfront: WinHTTP largely behaves like a black box. The winhttp.dll used by both 32-bit and 64-bit processes does not expose public debug symbols, so stepping into it with a debugger won’t provide much insight. When proxy detection fails, it often does so silently, which makes it feel like the API is ignoring flags or configuration.

Before going deep into tracing, it’s worth validating the environment, since many failures turn out not to be code-related. Please ensure that the WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc) is running, that WPAD is actually reachable on the network (DNS/DHCP), and that the PAC file works when tested directly. Also note that WinHTTP does not use browser proxy settings - it has its own configuration and service path.

Since your scenario involves calling WinHttpGetProxyForUrl() from a 32-bit process running under WoW64, bitness does matter when debugging. While WinHTTP proxy settings are system-wide, a 32-bit client runs under a different execution context and may observe configuration differently due to redirection and policy application. For that reason, when validating configuration, it can be useful to query it using the same bitness as the application, for example:

%windir%\SysWOW64\netsh winhttp show proxy

This helps ensure you’re inspecting WinHTTP from the same perspective as the calling process.

Regarding logging, generic netsh trace sessions often don’t capture useful WinHTTP details, which aligns with what you observed. If ETW tracing is needed, you’ll need to enable specific WinHTTP ETW providers (for example via logman or the InternetClient tracing scenario). Even then, the traces are mainly useful for confirming that auto-detection or PAC download was attempted; they generally won’t explain why a particular flag combination disabled detection or how the PAC logic was evaluated internally.

When debugging API usage itself, it’s important to be very strict:

• Log all flags passed to WinHttpGetProxyForUrl
• Check return values and call GetLastError() immediately on failure
• Be mindful of differences between service and interactive contexts
• Avoid reusing handles in ways not explicitly documented

Small differences in flags or calling context can completely change WinHTTP behavior without producing obvious errors.

A practical approach that often helps is comparison testing: run the same call in a minimal test app, with the same bitness and flags, on a machine where WPAD is known to work. Comparing 32-bit vs 64-bit or service vs desktop behavior usually highlights the underlying difference quickly.

In short, there isn’t a single “enable verbose logging” switch for WinHTTP proxy detection. Debugging it is mostly about validating the environment, matching bitness, enabling the right ETW providers, and narrowing down differences through controlled testing rather than stepping through WinHTTP internals.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.