[SOLVED] ERROR_WINHTTP_NAME_NOT_RESOLVED when using dbghelp as a service

ERROR_WINHTTP_NAME_NOT_RESOLVED when using dbghelp as a service

I am trying to setup a symbol proxy server that targets both our own internal symbol stores (UNC) and http servers (microsofts being one). I want it to run as a service, or as IIS (which runs as a service of course).

I have tried Micrsoft SymProxy, and am now trying pySymProxy. pySymProxy works just fine when I run it from desktop, but has this WINHTTP error when run as a service (/via IIS).

I have tried every fix mentioned here, including using the DBGHELP_WININET, and setting the registry settings. These have no effect at all. I believe this information is out of date now, but I can't find anywhere that suggests what the latest recommendation for this is. I also don't understand what the underlying problem is either. Every method I have tried so far tells me I am NOT behind a proxy. WinHttp says it is not using a proxy in the log entry, so why can it not simply resolve a name like it can when run from the desktop?

Example from my log when it fails, while running from a service:

SYMSRV:  BYINDEX: 0x4
         C:\SymProxy\cache*http://msdl.microsoft.com/download/symbols
         kernelbase.pdb
         0C3B0BCF250566567FA913502B5677C81
SYMSRV:  UNC: C:\SymProxy\cache\kernelbase.pdb\0C3B0BCF250566567FA913502B5677C81\kernelbase.pdb - path not found
SYMSRV:  UNC: C:\SymProxy\cache\kernelbase.pdb\0C3B0BCF250566567FA913502B5677C81\kernelbase.pd_ - path not found
SYMSRV:  UNC: C:\SymProxy\cache\kernelbase.pdb\0C3B0BCF250566567FA913502B5677C81\file.ptr - path not found
SYMSRV:  WinHttp interface using proxy server: none
SYMSRV:  HTTPGET: /download/symbols/index2.txt
SYMSRV:  WinHttpSendRequest: 800C2EE7 - ERROR_WINHTTP_NAME_NOT_RESOLVED
SYMSRV:  HTTPGET: /download/symbols/kernelbase.pdb/0C3B0BCF250566567FA913502B5677C81/kernelbase.pdb
SYMSRV:  WinHttpSendRequest: 800C2EE7 - ERROR_WINHTTP_NAME_NOT_RESOLVED
SYMSRV:  RESULT: 0x800C2EE7

Example of it working totally fine when run from desktop:

SYMSRV:  BYINDEX: 0x4
         C:\SymProxy\cache*http://msdl.microsoft.com/download/symbols
         kernelbase.pdb
         0C3B0BCF250566567FA913502B5677C81
SYMSRV:  UNC: C:\SymProxy\cache\kernelbase.pdb\0C3B0BCF250566567FA913502B5677C81\kernelbase.pdb - path not found
SYMSRV:  UNC: C:\SymProxy\cache\kernelbase.pdb\0C3B0BCF250566567FA913502B5677C81\kernelbase.pd_ - path not found
SYMSRV:  UNC: C:\SymProxy\cache\kernelbase.pdb\0C3B0BCF250566567FA913502B5677C81\file.ptr - path not found
SYMSRV:  HTTPGET: /download/symbols/index2.txt
SYMSRV:  HttpQueryInfo(HTTP_QUERY_CONTENT_LENGTH): 800C2F76 - ERROR_HTTP_HEADER_NOT_FOUND
SYMSRV:  HttpQueryInfo: 80190194 - HTTP_STATUS_NOT_FOUND
SYMSRV:  HTTPGET: /download/symbols/kernelbase.pdb/0C3B0BCF250566567FA913502B5677C81/kernelbase.pdb
SYMSRV:  HttpQueryInfo: 801900c8 - HTTP_STATUS_OK
SYMSRV:  kernelbase.pdb from http://msdl.microsoft.com/download/symbols: 7687168 bytes -

Solution

A (not particularly nice) work around for this issue is to use an OLD version of dbghelp.dll and symsrv.dll, which still supports the DBGHELP_WININET flag.

This is also confirmed by the original dbg author as an unsolvable problem here. As MS symbol servers are automatically redirecting to https, there is no way using WinHTTP for the SymProxy to work with them from what I understand.

I have confirmed this working with dbghelp version 6.11.1.404. I have confirmed it NOT working with dbghelp 10.0.15063.400 (or newer presumably). I don't know anything about the intervening versions.