6.6.3.5 symsrv.dll doesn't work without using a WinHttp proxy when used with symproxy.dll

Discussion:

(too old to reply)

Skywing

2006-02-23 18:09:51 UTC

The 6.6.3.5 version of symsrv.dll is broken when used in conjunction with
symproxy.dll as a symbol server proxy (using Windows Server 2003/IIS 6).

In particular, if the system is NOT configured to use a proxy, symsrv.dll
improperly attempts to use a named proxy "symsrvbogusproxy" with "<local>"
as the bypass list. This causes the symbol server proxy to be unable to
connect to ANY http-based symbol stores because it tries and fails to
connect to "symsrvbogusproxy.default-dns-search-suffix".

So, unless you actually define a WinHttp proxy (instead of configuring
WinHttp to go direct) then you are sunk.

This is basically a showstopper for me with using symproxy.dll. Is there
any known workaround for this problem other than patching symsrv.dll itself?

The code path for this bug is:

.text:01D1C02C loc_1D1C02C: ; CODE XREF:
StoreWinHttp::connect(void)+156j
.text:01D1C02C ;
StoreWinHttp::connect(void)+163j
.text:01D1C02C lea ecx, [ebp+var_18]
.text:01D1C02F push ecx
.text:01D1C030 call
?GetProxyConfig@@YGHPAUWINHTTP_CURRENT_USER_IE_PROXY_CONFIG@@@Z ;
GetProxyConfig(WINHTTP_CURRENT_USER_IE_PROXY_CONFIG *) ; try to get proxy
settings from WinHttp. This function returns zero here.
.text:01D1C035 test eax, eax
.text:01D1C037 jz short loc_1D1C053

.
.
.

.text:01D1C053
.text:01D1C053 loc_1D1C053: ; CODE XREF:
StoreWinHttp::connect(void)+187j
.text:01D1C053 ;
StoreWinHttp::connect(void)+18Dj
.text:01D1C053 mov [ebp+var_22C], offset aSymsrvboguspro
; "SymSrvBogusProxy" ; this is broken!
.text:01D1C05D mov [ebp+var_230], offset aLocal ;
"<local>"
.text:01D1C067
.text:01D1C067 loc_1D1C067: ; CODE XREF:
StoreWinHttp::connect(void)+17Aj
.text:01D1C067 ;
StoreWinHttp::connect(void)+1A1j
.text:01D1C067 mov [ebp+var_4],
WINHTTP_ACCESS_TYPE_NAMED_PROXY ; this is also broken. It ALWAYS forces
WINHTTP_ACCESS_TYPE_NAMED_PROXY. (why??). Should use
WINHTTP_ACCESS_TYPE_NO_PROXY if the user has no proxy defined here...
.text:01D1C06E push 0
.text:01D1C070 mov ecx, [ebp+var_230]
.text:01D1C076 push ecx
.text:01D1C077 mov edx, [ebp+var_22C]
.text:01D1C07D push edx
.text:01D1C07E mov eax, [ebp+var_4]
.text:01D1C081 push eax
.text:01D1C082 push offset word_1D75540
.text:01D1C087 call ***@20 ;
WinHttpOpen(x,x,x,x,x)

GetProxyConfig() returns zero because the call to
WinHttpGetDefaultProxyConfiguration() suceeds and returns a
WINHTTP_PROXY_INFO that specifies
dwAccessType==WINHTTP_ACCESS_TYPE_NO_PROXY, lpszProxy==NULL,
lpszProxyBypass==NULL, but GetProxyConfig requires lpszProxy to be non-null
to succeed. As as result "symsrvbogusproxy" is used (incorrectly!).

Tom Stewart

2006-02-23 19:42:39 UTC

Permalink

Sadly, I have the exact same issue. :-(

A "Pat Styles" from MS stated back over a year ago that, "The next revision will handle this
in some other way." [1]

I guess we just haven't seen the "next revision" yet, even though the date on symproxy.dll
is 1/18/2006. Sigh...

[1] http://groups.google.com/group/microsoft.public.windbg/msg/c023150f4ff07546

--
Tom

The 6.6.3.5 version of symsrv.dll is broken when used in conjunction with symproxy.dll as
a symbol server proxy (using Windows Server 2003/IIS 6).
In particular, if the system is NOT configured to use a proxy, symsrv.dll improperly
attempts to use a named proxy "symsrvbogusproxy" with "<local>" as the bypass list. This
causes the symbol server proxy to be unable to connect to ANY http-based symbol stores
because it tries and fails to connect to "symsrvbogusproxy.default-dns-search-suffix".
So, unless you actually define a WinHttp proxy (instead of configuring WinHttp to go
direct) then you are sunk.
This is basically a showstopper for me with using symproxy.dll. Is there any known
workaround for this problem other than patching symsrv.dll itself?
StoreWinHttp::connect(void)+156j
.text:01D1C02C ; StoreWinHttp::connect(void)+163j
.text:01D1C02C lea ecx, [ebp+var_18]
.text:01D1C02F push ecx
.text:01D1C030 call
GetProxyConfig(WINHTTP_CURRENT_USER_IE_PROXY_CONFIG *) ; try to get proxy settings from
WinHttp. This function returns zero here.
.text:01D1C035 test eax, eax
.text:01D1C037 jz short loc_1D1C053
.
.
.
.text:01D1C053
StoreWinHttp::connect(void)+187j
.text:01D1C053 ; StoreWinHttp::connect(void)+18Dj
.text:01D1C053 mov [ebp+var_22C], offset aSymsrvboguspro ;
"SymSrvBogusProxy" ; this is broken!
.text:01D1C05D mov [ebp+var_230], offset aLocal ; "<local>"
.text:01D1C067
StoreWinHttp::connect(void)+17Aj
.text:01D1C067 ; StoreWinHttp::connect(void)+1A1j
.text:01D1C067 mov [ebp+var_4], WINHTTP_ACCESS_TYPE_NAMED_PROXY ; this
is also broken. It ALWAYS forces WINHTTP_ACCESS_TYPE_NAMED_PROXY. (why??). Should use
WINHTTP_ACCESS_TYPE_NO_PROXY if the user has no proxy defined here...
.text:01D1C06E push 0
.text:01D1C070 mov ecx, [ebp+var_230]
.text:01D1C076 push ecx
.text:01D1C077 mov edx, [ebp+var_22C]
.text:01D1C07D push edx
.text:01D1C07E mov eax, [ebp+var_4]
.text:01D1C081 push eax
.text:01D1C082 push offset word_1D75540
GetProxyConfig() returns zero because the call to WinHttpGetDefaultProxyConfiguration()
suceeds and returns a WINHTTP_PROXY_INFO that specifies
dwAccessType==WINHTTP_ACCESS_TYPE_NO_PROXY, lpszProxy==NULL, lpszProxyBypass==NULL, but
GetProxyConfig requires lpszProxy to be non-null to succeed. As as result
"symsrvbogusproxy" is used (incorrectly!).

Skywing

2006-02-23 19:57:07 UTC

Permalink

Well, for now, I just ended up patching symsrv.dll to never use an HTTP
proxy (always connect directly). It's definitely a nasty, ugly, hack but it
works until we get a fixed version of symsrv.dll. Naturally you will have
to keep updating the patch with each new symsrv.dll version you want to
deploy until Microsoft fixes the problem (or just not upgrade the symsrv.dll
on your symbol proxy server until they fix it).

E:\Program Files\Debugging Tools for Windows\symproxy>fc /b symsrv.dll
symsrvNoP
roxy.dll
Comparing files symsrv.dll and SYMSRVNOPROXY.DLL
00000160: 9A 06
00000161: 13 B7
00000162: 06 05
0001B459: 4C 00
0001B45A: 47 00
0001B45B: D0 00
0001B45C: 01 00
0001B463: 70 00
0001B464: 47 00
0001B465: D0 00
0001B466: 01 00
0001B46A: 03 01

This modifies the parameters passed to WinHttpOpen() to always use
WINHTTP_ACCESS_TYPE_NO_PROXY and a null proxy name / proxy bypass list. It
also updates the checksum in the image header to be correct after making
those changes. This is only valid for symsrv.dll 6.6.3.5.

(or the differences as assembler):

[old]

.01D1C053: C785D4FDFFFF4C47D001 mov
d,[ebp][-0000022C],001D0474
.01D1C05D: C785D0FDFFFF7047D001 mov
d,[ebp][-00000230],001D0477
.01D1C067: C745FC03000000 mov
d,[ebp][-04],000000003 ---

[new]

.01D1C053: C785D4FDFFFF00000000 mov
d,[ebp][-0000022C],00000000
.01D1C05D: C785D0FDFFFF00000000 mov
d,[ebp][-00000230],00000000
.01D1C067: C745FC01000000 mov
d,[ebp][-04],000000001 ---
.01D1C06E: 6A00 push 000

Post by Tom Stewart
Sadly, I have the exact same issue. :-(
A "Pat Styles" from MS stated back over a year ago that, "The next
revision will handle this in some other way." [1]
I guess we just haven't seen the "next revision" yet, even though the
date on symproxy.dll is 1/18/2006. Sigh...
[1]
http://groups.google.com/group/microsoft.public.windbg/msg/c023150f4ff07546
--
Tom

Post by Skywing
The 6.6.3.5 version of symsrv.dll is broken when used in conjunction with
symproxy.dll as a symbol server proxy (using Windows Server 2003/IIS 6).
In particular, if the system is NOT configured to use a proxy, symsrv.dll
improperly attempts to use a named proxy "symsrvbogusproxy" with
"<local>" as the bypass list. This causes the symbol server proxy to be
unable to connect to ANY http-based symbol stores because it tries and
fails to connect to "symsrvbogusproxy.default-dns-search-suffix".
So, unless you actually define a WinHttp proxy (instead of configuring
WinHttp to go direct) then you are sunk.
This is basically a showstopper for me with using symproxy.dll. Is there
any known workaround for this problem other than patching symsrv.dll itself?
StoreWinHttp::connect(void)+156j
.text:01D1C02C ;
StoreWinHttp::connect(void)+163j
.text:01D1C02C lea ecx, [ebp+var_18]
.text:01D1C02F push ecx
.text:01D1C030 call
GetProxyConfig(WINHTTP_CURRENT_USER_IE_PROXY_CONFIG *) ; try to get proxy
settings from WinHttp. This function returns zero here.
.text:01D1C035 test eax, eax
.text:01D1C037 jz short loc_1D1C053
.
.
.
.text:01D1C053
StoreWinHttp::connect(void)+187j
.text:01D1C053 ;
StoreWinHttp::connect(void)+18Dj
.text:01D1C053 mov [ebp+var_22C], offset
aSymsrvboguspro ; "SymSrvBogusProxy" ; this is broken!
.text:01D1C05D mov [ebp+var_230], offset aLocal ; "<local>"
.text:01D1C067
StoreWinHttp::connect(void)+17Aj
.text:01D1C067 ;
StoreWinHttp::connect(void)+1A1j
.text:01D1C067 mov [ebp+var_4],
WINHTTP_ACCESS_TYPE_NAMED_PROXY ; this is also broken. It ALWAYS forces
WINHTTP_ACCESS_TYPE_NAMED_PROXY. (why??). Should use
WINHTTP_ACCESS_TYPE_NO_PROXY if the user has no proxy defined here...
.text:01D1C06E push 0
.text:01D1C070 mov ecx, [ebp+var_230]
.text:01D1C076 push ecx
.text:01D1C077 mov edx, [ebp+var_22C]
.text:01D1C07D push edx
.text:01D1C07E mov eax, [ebp+var_4]
.text:01D1C081 push eax
.text:01D1C082 push offset word_1D75540
GetProxyConfig() returns zero because the call to
WinHttpGetDefaultProxyConfiguration() suceeds and returns a
WINHTTP_PROXY_INFO that specifies
dwAccessType==WINHTTP_ACCESS_TYPE_NO_PROXY, lpszProxy==NULL,
lpszProxyBypass==NULL, but GetProxyConfig requires lpszProxy to be
non-null to succeed. As as result "symsrvbogusproxy" is used
(incorrectly!).

Tom Stewart

2006-02-24 13:24:34 UTC

Permalink

You are a clever one, skywing, and more motivated than me. This edit works for me. Let's
indeed hope that MS actually fixes the problem...

--
Tom

Well, for now, I just ended up patching symsrv.dll to never use an HTTP proxy (always
connect directly). It's definitely a nasty, ugly, hack but it works until we get a fixed
version of symsrv.dll. Naturally you will have to keep updating the patch with each new
symsrv.dll version you want to deploy until Microsoft fixes the problem (or just not
upgrade the symsrv.dll on your symbol proxy server until they fix it).
E:\Program Files\Debugging Tools for Windows\symproxy>fc /b symsrv.dll symsrvNoP
roxy.dll
Comparing files symsrv.dll and SYMSRVNOPROXY.DLL
00000160: 9A 06
00000161: 13 B7
00000162: 06 05
0001B459: 4C 00
0001B45A: 47 00
0001B45B: D0 00
0001B45C: 01 00
0001B463: 70 00
0001B464: 47 00
0001B465: D0 00
0001B466: 01 00
0001B46A: 03 01
This modifies the parameters passed to WinHttpOpen() to always use
WINHTTP_ACCESS_TYPE_NO_PROXY and a null proxy name / proxy bypass list. It also updates
the checksum in the image header to be correct after making those changes. This is only
valid for symsrv.dll 6.6.3.5.
[old]
.01D1C053: C785D4FDFFFF4C47D001 mov d,[ebp][-0000022C],001D0474
.01D1C05D: C785D0FDFFFF7047D001 mov d,[ebp][-00000230],001D0477
.01D1C067: C745FC03000000 mov d,[ebp][-04],000000003 ---
[new]
.01D1C053: C785D4FDFFFF00000000 mov d,[ebp][-0000022C],00000000
.01D1C05D: C785D0FDFFFF00000000 mov d,[ebp][-00000230],00000000
.01D1C067: C745FC01000000 mov d,[ebp][-04],000000001 ---
.01D1C06E: 6A00 push 000

Post by Tom Stewart
Sadly, I have the exact same issue. :-(
A "Pat Styles" from MS stated back over a year ago that, "The next revision will handle
this in some other way." [1]
I guess we just haven't seen the "next revision" yet, even though the date on
symproxy.dll is 1/18/2006. Sigh...
[1] http://groups.google.com/group/microsoft.public.windbg/msg/c023150f4ff07546
--
Tom

The 6.6.3.5 version of symsrv.dll is broken when used in conjunction with symproxy.dll
as a symbol server proxy (using Windows Server 2003/IIS 6).
In particular, if the system is NOT configured to use a proxy, symsrv.dll improperly
attempts to use a named proxy "symsrvbogusproxy" with "<local>" as the bypass list.
This causes the symbol server proxy to be unable to connect to ANY http-based symbol
stores because it tries and fails to connect to
"symsrvbogusproxy.default-dns-search-suffix".
So, unless you actually define a WinHttp proxy (instead of configuring WinHttp to go
direct) then you are sunk.
This is basically a showstopper for me with using symproxy.dll. Is there any known
workaround for this problem other than patching symsrv.dll itself?
StoreWinHttp::connect(void)+156j
.text:01D1C02C ;
StoreWinHttp::connect(void)+163j
.text:01D1C02C lea ecx, [ebp+var_18]
.text:01D1C02F push ecx
.text:01D1C030 call
GetProxyConfig(WINHTTP_CURRENT_USER_IE_PROXY_CONFIG *) ; try to get proxy settings from
WinHttp. This function returns zero here.
.text:01D1C035 test eax, eax
.text:01D1C037 jz short loc_1D1C053
.
.
.
.text:01D1C053
StoreWinHttp::connect(void)+187j
.text:01D1C053 ;
StoreWinHttp::connect(void)+18Dj
.text:01D1C053 mov [ebp+var_22C], offset aSymsrvboguspro ;
"SymSrvBogusProxy" ; this is broken!
.text:01D1C05D mov [ebp+var_230], offset aLocal ; "<local>"
.text:01D1C067
StoreWinHttp::connect(void)+17Aj
.text:01D1C067 ;
StoreWinHttp::connect(void)+1A1j
.text:01D1C067 mov [ebp+var_4], WINHTTP_ACCESS_TYPE_NAMED_PROXY ;
this is also broken. It ALWAYS forces WINHTTP_ACCESS_TYPE_NAMED_PROXY. (why??).
Should use WINHTTP_ACCESS_TYPE_NO_PROXY if the user has no proxy defined here...
.text:01D1C06E push 0
.text:01D1C070 mov ecx, [ebp+var_230]
.text:01D1C076 push ecx
.text:01D1C077 mov edx, [ebp+var_22C]
.text:01D1C07D push edx
.text:01D1C07E mov eax, [ebp+var_4]
.text:01D1C081 push eax
.text:01D1C082 push offset word_1D75540
GetProxyConfig() returns zero because the call to WinHttpGetDefaultProxyConfiguration()
suceeds and returns a WINHTTP_PROXY_INFO that specifies
dwAccessType==WINHTTP_ACCESS_TYPE_NO_PROXY, lpszProxy==NULL, lpszProxyBypass==NULL, but
GetProxyConfig requires lpszProxy to be non-null to succeed. As as result
"symsrvbogusproxy" is used (incorrectly!).

Pat Styles

2006-02-24 15:59:49 UTC

Permalink

Tom is largely correct here. SymProxy was designed to work with proxy
servers and specifically avoids trying to work without one. I need to set a
bogus proxy so that it can work correctly with in intranet environments.
The plan was to remove this and allow the user to set the bogus proxy
through proxycfg.exe. However, because symsrv shares internet proxy
settings with all other WinHttp clients, we found that was not a workable
solution. So the last beta of the debugger was released with everything
operating the same. I am working on finding some other way to set up the
proxy, completely independant of proxycfg.exe. If you are interested in
getting a private copy of symsrv.dll, please email me at
***@microsoft.com.

.pat styles (microsoft)

"Tom Stewart" <***@community.nospam> wrote in message news:***@TK2MSFTNGP10.phx.gbl...
Sadly, I have the exact same issue. :-(

A "Pat Styles" from MS stated back over a year ago that, "The next revision
will handle this
in some other way." [1]

I guess we just haven't seen the "next revision" yet, even though the date
on symproxy.dll
is 1/18/2006. Sigh...

[1]
http://groups.google.com/group/microsoft.public.windbg/msg/c023150f4ff07546

--
Tom

The 6.6.3.5 version of symsrv.dll is broken when used in conjunction with symproxy.dll as
a symbol server proxy (using Windows Server 2003/IIS 6).
In particular, if the system is NOT configured to use a proxy, symsrv.dll improperly
attempts to use a named proxy "symsrvbogusproxy" with "<local>" as the bypass list. This
causes the symbol server proxy to be unable to connect to ANY http-based symbol stores
because it tries and fails to connect to
"symsrvbogusproxy.default-dns-search-suffix".
So, unless you actually define a WinHttp proxy (instead of configuring WinHttp to go
direct) then you are sunk.
This is basically a showstopper for me with using symproxy.dll. Is there any known
workaround for this problem other than patching symsrv.dll itself?
StoreWinHttp::connect(void)+156j
.text:01D1C02C ;
StoreWinHttp::connect(void)+163j
.text:01D1C02C lea ecx, [ebp+var_18]
.text:01D1C02F push ecx
.text:01D1C030 call
GetProxyConfig(WINHTTP_CURRENT_USER_IE_PROXY_CONFIG *) ; try to get proxy settings from
WinHttp. This function returns zero here.
.text:01D1C035 test eax, eax
.text:01D1C037 jz short loc_1D1C053
.
.
.
.text:01D1C053
StoreWinHttp::connect(void)+187j
.text:01D1C053 ;
StoreWinHttp::connect(void)+18Dj
.text:01D1C053 mov [ebp+var_22C], offset
aSymsrvboguspro ;
"SymSrvBogusProxy" ; this is broken!
.text:01D1C05D mov [ebp+var_230], offset aLocal ; "<local>"
.text:01D1C067
StoreWinHttp::connect(void)+17Aj
.text:01D1C067 ;
StoreWinHttp::connect(void)+1A1j
.text:01D1C067 mov [ebp+var_4],
WINHTTP_ACCESS_TYPE_NAMED_PROXY ; this
is also broken. It ALWAYS forces WINHTTP_ACCESS_TYPE_NAMED_PROXY.
(why??). Should use
WINHTTP_ACCESS_TYPE_NO_PROXY if the user has no proxy defined here...
.text:01D1C06E push 0
.text:01D1C070 mov ecx, [ebp+var_230]
.text:01D1C076 push ecx
.text:01D1C077 mov edx, [ebp+var_22C]
.text:01D1C07D push edx
.text:01D1C07E mov eax, [ebp+var_4]
.text:01D1C081 push eax
.text:01D1C082 push offset word_1D75540
WinHttpOpen(x,x,x,x,x)
GetProxyConfig() returns zero because the call to
WinHttpGetDefaultProxyConfiguration()
suceeds and returns a WINHTTP_PROXY_INFO that specifies
dwAccessType==WINHTTP_ACCESS_TYPE_NO_PROXY, lpszProxy==NULL,
lpszProxyBypass==NULL, but
GetProxyConfig requires lpszProxy to be non-null to succeed. As as result
"symsrvbogusproxy" is used (incorrectly!).

Tom Stewart

2006-02-24 20:39:38 UTC

Permalink

Hi Pat- I sent you a reply from my work email address which includes meditech dot com.

--
Tom

Post by Pat Styles
Tom is largely correct here. SymProxy was designed to work with proxy
servers and specifically avoids trying to work without one. I need to set a
bogus proxy so that it can work correctly with in intranet environments.
The plan was to remove this and allow the user to set the bogus proxy
through proxycfg.exe. However, because symsrv shares internet proxy
settings with all other WinHttp clients, we found that was not a workable
solution. So the last beta of the debugger was released with everything
operating the same. I am working on finding some other way to set up the
proxy, completely independant of proxycfg.exe. If you are interested in
getting a private copy of symsrv.dll, please email me at
.pat styles (microsoft)
Sadly, I have the exact same issue. :-(
A "Pat Styles" from MS stated back over a year ago that, "The next revision
will handle this
in some other way." [1]
I guess we just haven't seen the "next revision" yet, even though the date on symproxy.dll
is 1/18/2006. Sigh...
[1]
http://groups.google.com/group/microsoft.public.windbg/msg/c023150f4ff07546
--
Tom

The 6.6.3.5 version of symsrv.dll is broken when used in conjunction with symproxy.dll as
a symbol server proxy (using Windows Server 2003/IIS 6).
In particular, if the system is NOT configured to use a proxy, symsrv.dll improperly
attempts to use a named proxy "symsrvbogusproxy" with "<local>" as the bypass list. This
causes the symbol server proxy to be unable to connect to ANY http-based symbol stores
because it tries and fails to connect to
"symsrvbogusproxy.default-dns-search-suffix".
So, unless you actually define a WinHttp proxy (instead of configuring WinHttp to go
direct) then you are sunk.
This is basically a showstopper for me with using symproxy.dll. Is there any known
workaround for this problem other than patching symsrv.dll itself?
StoreWinHttp::connect(void)+156j
.text:01D1C02C ;
StoreWinHttp::connect(void)+163j
.text:01D1C02C lea ecx, [ebp+var_18]
.text:01D1C02F push ecx
.text:01D1C030 call
GetProxyConfig(WINHTTP_CURRENT_USER_IE_PROXY_CONFIG *) ; try to get proxy settings from
WinHttp. This function returns zero here.
.text:01D1C035 test eax, eax
.text:01D1C037 jz short loc_1D1C053
.
.
.
.text:01D1C053
StoreWinHttp::connect(void)+187j
.text:01D1C053 ;
StoreWinHttp::connect(void)+18Dj
.text:01D1C053 mov [ebp+var_22C], offset
aSymsrvboguspro ;
"SymSrvBogusProxy" ; this is broken!
.text:01D1C05D mov [ebp+var_230], offset aLocal ; "<local>"
.text:01D1C067
StoreWinHttp::connect(void)+17Aj
.text:01D1C067 ;
StoreWinHttp::connect(void)+1A1j
.text:01D1C067 mov [ebp+var_4],
WINHTTP_ACCESS_TYPE_NAMED_PROXY ; this
is also broken. It ALWAYS forces WINHTTP_ACCESS_TYPE_NAMED_PROXY.
(why??). Should use
WINHTTP_ACCESS_TYPE_NO_PROXY if the user has no proxy defined here...
.text:01D1C06E push 0
.text:01D1C070 mov ecx, [ebp+var_230]
.text:01D1C076 push ecx
.text:01D1C077 mov edx, [ebp+var_22C]
.text:01D1C07D push edx
.text:01D1C07E mov eax, [ebp+var_4]
.text:01D1C081 push eax
.text:01D1C082 push offset word_1D75540
GetProxyConfig() returns zero because the call to
WinHttpGetDefaultProxyConfiguration()
suceeds and returns a WINHTTP_PROXY_INFO that specifies
dwAccessType==WINHTTP_ACCESS_TYPE_NO_PROXY, lpszProxy==NULL,
lpszProxyBypass==NULL, but
GetProxyConfig requires lpszProxy to be non-null to succeed. As as result
"symsrvbogusproxy" is used (incorrectly!).