cloud9342111.autos

Building a COM Proxy Wrapper for Visual Basic 6

Written by

admin

in

Troubleshooting Proxy Connections in VB6 ApplicationsWhen a Visual Basic 6 (VB6) application fails to connect through a proxy, the problem can stem from many layers: system settings, application configuration, COM components or third-party libraries, authentication, networking, or code bugs. This article walks through systematic troubleshooting steps, common causes, diagnostic techniques, and concrete fixes you can apply to get your VB6 app working reliably through proxies.

1. Understand how your VB6 app uses the network

Start by identifying what part of your app performs network access:

  • Is it using WinInet APIs (InternetOpen/InternetConnect/InternetOpenUrl)?
  • Is it using WinHTTP (WinHttpOpen/WinHttpConnect)?
  • Is it using Microsoft XML (MSXML2.XMLHTTP or ServerXMLHTTP)?
  • Is it using Winsock control, third‑party HTTP/FTP libraries, or COM components (e.g., Chilkat, Indy, cURL wrappers)?

Different stacks respect proxy settings differently. For example:

  • WinInet generally uses system (IE) proxy settings and supports automatic configuration and authentication.
  • WinHTTP uses its own proxy configuration (can import from WinInet but must be configured for services).
  • MSXML2.XMLHTTP (client-side) typically uses WinInet; MSXML2.ServerXMLHTTP uses WinHTTP and ignores WinInet.

Knowing which one you use determines the troubleshooting path.

2. Reproduce the problem and gather evidence

Before changing settings, reproduce the failure and collect details:

  • Exact error messages, VB6 error numbers, HRESULTs, or COM error descriptions.
  • The code snippet performing the request. Include object creation lines and any option flags.
  • Whether the issue occurs for all proxy targets or only specific hosts.
  • Whether direct connections (no proxy) succeed.
  • Whether other apps on the same machine (browser, curl, PowerShell, another client) can access the same endpoint via the proxy.
  • Proxy type: HTTP proxy, HTTPS (CONNECT) proxy, SOCKS, NTLM/Negotiate/Kerberos authentication, authenticated vs anonymous.
  • Whether the proxy requires explicit configuration (address/port) or uses WPAD/auto-config (PAC) file.
  • OS and service context: interactive desktop app vs service/Windows Service/COM+.

Record these facts; they guide the next steps.

3. Check system and proxy settings

  • Verify Internet Explorer / Windows Proxy settings (Settings → Network & Internet → Proxy on modern Windows; Control Panel / Internet Options for older UI). If your stack uses WinInet, incorrect system proxy prevents connections.
  • If using WinHTTP (or ServerXMLHTTP), run netsh winhttp show proxy to view WinHTTP proxy. If empty and your app needs it, import from IE with:
    netsh winhttp import proxy source=ie
  • If a PAC/WPAD script is used, fetch the PAC URL in a browser to ensure it’s reachable and returns a valid JS function findProxyForURL().
  • Confirm proxy address and port are correct and that the proxy is reachable from the machine (ping/traceroute/telnet to proxy:port). For HTTP proxies, use:
    telnet proxy.example.com 8080
    or curl –proxy proxy:port http://example.com
  • If the proxy uses authentication, check username/domain/password and authentication scheme (Basic, Digest, NTLM, Negotiate). Browsers may negotiate automatically; programmatic clients may need explicit handling.

4. Match client library behavior to proxy requirements

  • WinInet (InternetOpen / URLDownloadToFile / InternetOpenUrl): honors system proxy and can do automatic logon for NTLM in interactive sessions. For programmatic credentials, use InternetSetOption or include credentials in URL (discouraged).
  • WinHTTP / ServerXMLHTTP: often used by services; needs explicit proxy settings via WinHttpSetOption or netsh import. ServerXMLHTTP does not perform user interactive/auto logon by default.
  • MSXML2.XMLHTTP vs MSXML2.ServerXMLHTTP: choose XMLHTTP for WinInet behavior (interactive), ServerXMLHTTP when you need WinHTTP for services.
  • Winsock / sockets / third‑party libs: many do not support HTTP proxy or authentication out of the box; you may need to implement the HTTP CONNECT and tunnelling logic or use a wrapper library.

5. Common problems and fixes

  1. Application ignores system proxy
  • Cause: Using WinHTTP or a library that doesn’t read WinInet settings.
  • Fix: Configure WinHTTP proxy (netsh winhttp set proxy proxy-server=“proxy:port”) or change code to use WinInet-based APIs.
  1. Authentication fails (401 / proxy authentication required)
  • Cause: Proxy requires NTLM/Negotiate and client doesn’t provide credentials or cannot do challenge-response.
  • Fixes:
    • For WinInet/MSXML XMLHTTP: enable automatic logon (use INTERNET_OPTION_SUPPRESS_BEHAVIOR flags cautiously) or call InternetSetOption to set credentials.
    • For ServerXMLHTTP: call setProxy and setProxyCredentials (if supported) or implement NTLM with a library that supports it (e.g., WinHTTP with proper credentials).
    • As a debug step, set proxy to allow Basic auth temporarily to confirm auth is the issue.
  1. PAC/WPAD not evaluated
  • Cause: Client library doesn’t support PAC or WPAD, or PAC fetch fails.
  • Fix: Resolve PAC URL access, or configure explicit proxy for the app (WinHTTP import) or use a library that supports PAC evaluation.
  1. TLS/SSL / CONNECT issues (HTTPS through proxy)
  • Cause: Proxy CONNECT handshake failing or server certificate issues.
  • Fixes:
    • Ensure the client uses CONNECT to the proxy for HTTPS and sends hostname in the CONNECT line.
    • Check proxy logs for blocked CONNECT destinations.
    • Validate root CA chain on the client if the proxy performs TLS interception (corporate proxies often do). Add the proxy’s CA to the Windows Trusted Root if needed (with caution).
  1. Service/Session differences
  • Cause: Services run under different accounts (LocalSystem) and lack user profile or proxy settings. WinInet proxy is per-user; services won’t pick up interactive user’s settings.
  • Fix: Configure WinHTTP proxy for system account (netsh winhttp import proxy source=ie while running as that account or supply explicit netsh commands), or run the service under a user account with proper settings.
  1. Timeouts or partial data
  • Cause: Proxy buffering, chunked encoding mishandling, or incorrect Content-Length handling.
  • Fix: Inspect raw HTTP with a proxy debugger (Fiddler, mitmproxy) and ensure your code reads until EOF or honors chunked responses. For VB6 winsock code, ensure correct parsing of HTTP headers and body.

6. Diagnostic techniques and tools

  • Fiddler or mitmproxy: intercept HTTP/HTTPS (requires installing root cert for HTTPS). Use to see exactly what the client sends and how the proxy responds.
  • Wireshark / tcpdump: capture network packets to see TCP/TLS handshake and proxy CONNECT exchanges.
  • netsh winhttp show proxy: inspect WinHTTP settings.
  • Event Viewer and application logs: check for errors from services or COM components.
  • Create minimal reproducible code: isolate the network call to a small VB6 sample that uses the same library—this helps pinpoint whether the problem is app logic or network stack. Example simple MSXML code to test WinInet path: 
    
Dim xhr As Object Set xhr = CreateObject("MSXML2.XMLHTTP") xhr.Open "GET", "http://example.com", False xhr.Send MsgBox xhr.Status & " " & xhr.StatusText
  • For ServerXMLHTTP: 
    
Dim xhr As Object Set xhr = CreateObject("MSXML2.ServerXMLHTTP.6.0") xhr.Open "GET", "http://example.com", False xhr.setProxy 2, "proxy.example.com:8080" xhr.Send MsgBox xhr.Status

7. Code examples and specific fixes

  • Using WinInet via MSXML2.XMLHTTP (interactive):

    Dim xhr As Object Set xhr = CreateObject("MSXML2.XMLHTTP.6.0") xhr.Open "GET", "http://internal.service.local/api", False xhr.setRequestHeader "User-Agent", "MyVB6Client/1.0" xhr.Send If xhr.Status <> 200 Then MsgBox "HTTP error: " & xhr.Status & " - " & xhr.StatusText End If

  • Using ServerXMLHTTP with explicit proxy and basic credentials:

    Dim xhr As Object Set xhr = CreateObject("MSXML2.ServerXMLHTTP.6.0") xhr.setProxy 2, "proxy.corp.local:8080" ' 2 = proxy setting manual xhr.Open "GET", "https://api.example.com", False xhr.setRequestHeader "Proxy-Authorization", "Basic " & Base64Encode("user:pass") xhr.Send

    (Implement Base64Encode in VB6 or use ADODB.Stream + MSXML DOM utilities.)

  • Using WinHTTP via WINHTTP COM (example pseudocode; VB6 requires declaring functions or using a wrapper):

    • Prefer calling WinHttpOpen/WinHttpSetCredentials in a wrapper DLL or use ServerXMLHTTP which can leverage WinHTTP features.

8. When to change architecture or use a helper

If VB6 libraries lack required proxy/auth features, consider:

  • Adding a small modern proxy-aware helper service (written in .NET, Go, or Node) on the same machine that your VB6 app calls locally; the helper performs authenticated proxy calls.
  • Using a supported COM wrapper (e.g., Chilkat ActiveX, which has built-in proxy and NTLM support).
  • Migrating critical networking parts to a newer component while keeping the main app in VB6.

9. Checklist to resolve most proxy issues

  • Confirm which network stack your code uses.
  • Verify system (WinInet) and WinHTTP proxy settings.
  • Test connectivity to proxy and target with curl/PowerShell/Fiddler.
  • Verify authentication method and supply credentials appropriately.
  • Check PAC/WPAD behavior and accessibility.
  • Use Fiddler/Wireshark to inspect request/response, including CONNECT lines for HTTPS.
  • For services, configure WinHTTP proxy or run service under an account with correct settings.
  • If using third‑party libraries, consult their docs for proxy/auth support or switch to one that supports your proxy.

10. Example troubleshooting scenario

Symptom: VB6 app using MSXML2.ServerXMLHTTP.6.0 gets 407 Proxy Authentication Required, while the same machine’s browser works. Steps:

  1. Confirm ServerXMLHTTP uses WinHTTP — it does. Run netsh winhttp show proxy; it’s empty.
  2. Import IE proxy: netsh winhttp import proxy source=ie.
  3. If proxy requires NTLM, set credentials in your code or run the application under a user that can authenticate; consider using WinHTTP with proper credential calls or switch to MSXML2.XMLHTTP if interactive credentials are acceptable.
  4. Retest; monitor with Fiddler to confirm the proxy handshake now completes.

11. Final notes and best practices

  • Prefer small isolated tests to rule out app-level logic errors.
  • Keep credentials and certificates secure; avoid embedding plaintext passwords in code.
  • Document which proxy method your app expects (WinInet vs WinHTTP) to prevent surprises when deploying as a service.
  • When possible, move network logic into a replaceable module to simplify future fixes or migration.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts