CDB.exe unable to download symbols when run from service

[Roman Ru]

Hi All. We've got an application that parses huge flow of our apllication
dumps. We intend it to work as a service and use CDB.exe to get crash stack.
The application is able to run as console utility or as a service. When it is
running from console it has no problem downloading missing symbols via https
from our symbol server. But when running as as service, it doesn't do that
(checked on the same dump file). Using procmon.exe utility from
Sysinternals, I've found the following first and main difference: in case of
console, CDB.exe uses wininet.dll to communicate, while in case of service
winhttp.dll used, not wininet.dll. I suppose it's because of WinInet Not
Supported for Use in Services (http://support.microsoft.com/kb/238425). But,
if CDB.exe is aware of this issue, why winhttp doesn't work well? Or there is
another cause that follows from difference between console and service
applications?
We use CDB version 6.8.4.0, and also tried 6.11.1.404 with the same result.
Any ideas are welcome...

[Satya]

What is the service account used ? Have you tried running your service under
a different account ?

Have you tried ntsd ?

Satya
http://www.winprogger.com

[Roman Ru]

Yes, I've tried both Administrator account under which console application
runs well and Local System account, result is the same. Also tried today ntsd
- result is the same.

Thinking on how do CDB.exe gets to know when to use winhttp or wininet...

Post by Satya
What is the service account used ? Have you tried running your service under
a different account ?
Have you tried ntsd ?
Satya
http://www.winprogger.com

[pat styles [microsoft]]

Hello Roman.

You are correct. WinInet does not work when called by an application that
is run as a service. Consequently we use WinHttp. There are different
requirements for using WinHttp. It does not use your IE proxy settings by
default as WinInet does. Also, it has a single set of communications
settings for the entire computer instead of user profile-specific stuff. I
would presume that your problem is related to this, and/or the fact that
your service account has different network (https) privileges than the user
account one might normally run through.

If you are going to run the debugger as a service, you need to involve
someone in your company that has network expertise on your security layout.
Here is a comment from symhttp.doc that contains some relevant data.

HTTP Proxies

When running as a service as SymProxy does, SymSrv uses the WinHTTP API to
access symbols over HTTP. (Normally it uses WinInet.) Consequently, you
may also need to set up HTTP proxy settings so that the service can access
outside network resources. You can do this using the netsh program. Type
“netsh.exe winhttp -?” for instructions. When using versions of Windows
that were released previous to Windows Vista and Windows Server 2008, you
should usethe proxycfg program. Type “proxycfg.exe -?” for instructions.

.pat styles [microsoft]

"Roman Ru" <Roman ***@discussions.microsoft.com> wrote in message news:F858667A-D014-4DB0-9448-***@microsoft.com...
Hi All. We've got an application that parses huge flow of our apllication
dumps. We intend it to work as a service and use CDB.exe to get crash stack.
The application is able to run as console utility or as a service. When it
is
running from console it has no problem downloading missing symbols via https
from our symbol server. But when running as as service, it doesn't do that
(checked on the same dump file). Using procmon.exe utility from
Sysinternals, I've found the following first and main difference: in case of
console, CDB.exe uses wininet.dll to communicate, while in case of service
winhttp.dll used, not wininet.dll. I suppose it's because of WinInet Not
Supported for Use in Services (http://support.microsoft.com/kb/238425). But,
if CDB.exe is aware of this issue, why winhttp doesn't work well? Or there
is
another cause that follows from difference between console and service
applications?
We use CDB version 6.8.4.0, and also tried 6.11.1.404 with the same result.
Any ideas are welcome...

[Roman Ru]

Hi pat. Thank you for putting me on the trail of this bug, though I haven't
got the result by now.
My OS is Windows XP x64 Professional 2003 Service Pack 2, so I tried
proxycfg.exe. The server running CDB.exe has no proxy settings for Internet
Explorer, it connects directly, so running proxycfg -d performed no changes.
I tried proxycfg with the following command:

proxycfg -p proxy_server "*.ourdomain.com"

proxy_server is dummy name, my aim was to have some proxy configuration set
up. According to http://msdn.microsoft.com/en-us/library/aa384069(VS.85).aspx
this made changes to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\WinHttpSettings. But looking into procmon output gave me
the fact CDB really looks to
HKLM\Software\Wow6432Node\Microsoft\windows\CurrentVersion\Internet
Settings\Connections, so I exported settings from the first node and imported
to the second one. Sad to say it didn't help.
I tried also adding .symopt-0x80000 command at the beginning of CDB script
to be sure CDB will try authenticate to our HTTPS symbols server. It didn't
help, too. At the end of this "adventure" I added !sym noisy to the CDB
script and saw the following:

SYMSRV: Assertion at d:\fbrel\sdktools\debuggers\symsrv\ini.cpp, line 258.
SYMSRV: WinHttp interface using proxy server: proxy_server
SYMSRV:
d:\RegDump\WinDbg\symbols\ourmodule.pdb\ACB4FBA56C294B3D90905F14900F3EEB1\ourmodule.pdb not found
SYMSRV:
https://symsrv.ourdomain.com/symbols/V6/ourmodule.pdb/ACB4FBA56C294B3D90905F14900F3EEB1/ourmodule.pdb not found

There are three questions for me in this output. First, what is the
assertion which I don't see when running from command line? Second, does
mentioning "proxy_server" means WinHTTP will try reaching
https://symsrv.ourdomain.com using it or just that is sees proxy settings
installed? (As you can see above, I added *.ourdomain.com to bypass list.)
The third and the last, why it says pdb on symbol server not found while it
is there (I checked this copypasting address to IE - downloading starts). I
get the same message after resetting proxy configuration in Wow6432Node to
direct access.

My last supposition is registry parameter "NoInternetProxy" mentioned in
HTTPS Proxies section of symhttp.doc. That section states that SymProxy has a
dummy proxy that it uses when to proxy configuration is set. This thing is
quite unclear to me. But setting "NoInternetProxy" to 1 seems to set up
SymProxy behaviour like I want to CDB. And I think, maybe CDB and SymProxy
use the same common DLL or just common logic and there is "NoInternetProxy"
parameter for CDB? But I don't know whether it is and where to set it.

Finishing experiments for today...

Post by pat styles [microsoft]
Hello Roman.
You are correct. WinInet does not work when called by an application that
is run as a service. Consequently we use WinHttp. There are different
requirements for using WinHttp. It does not use your IE proxy settings by
default as WinInet does. Also, it has a single set of communications
settings for the entire computer instead of user profile-specific stuff. I
would presume that your problem is related to this, and/or the fact that
your service account has different network (https) privileges than the user
account one might normally run through.
If you are going to run the debugger as a service, you need to involve
someone in your company that has network expertise on your security layout.
Here is a comment from symhttp.doc that contains some relevant data.
HTTP Proxies
When running as a service as SymProxy does, SymSrv uses the WinHTTP API to
access symbols over HTTP. (Normally it uses WinInet.) Consequently, you
may also need to set up HTTP proxy settings so that the service can access
outside network resources. You can do this using the netsh program. Type
“netsh.exe winhttp -?” for instructions. When using versions of Windows
that were released previous to Windows Vista and Windows Server 2008, you
should usethe proxycfg program. Type “proxycfg.exe -?” for instructions.
..pat styles [microsoft]

[pat styles [microsoft]]

Hello Roman.

It looks like you have an unsolvable problem.

When running as a service, cdb needs to use the WinHttp interface.
Cdb, when running the WinHttp interface does not support HTTPS connections
because WinHttp does not contain the facilities to poll for credentials that
WinInet has.

My only suggestion is that you set DBGHELP=WININET=1 in the environment of
the service account and see if you can force cdb to use WinInet. However
this is totally unsupported. I can't say this will cause cdb to use WinInet
and if it does, I cannot say that WinInet will work anyway from the service.

.pat styles [microsoft]

"Roman Ru" <***@discussions.microsoft.com> wrote in message news:AF98A8B1-9546-44B6-B582-***@microsoft.com...
Hi pat. Thank you for putting me on the trail of this bug, though I haven't
got the result by now.
My OS is Windows XP x64 Professional 2003 Service Pack 2, so I tried
proxycfg.exe. The server running CDB.exe has no proxy settings for Internet
Explorer, it connects directly, so running proxycfg -d performed no changes.
I tried proxycfg with the following command:

proxycfg -p proxy_server "*.ourdomain.com"

proxy_server is dummy name, my aim was to have some proxy configuration set
up. According to
http://msdn.microsoft.com/en-us/library/aa384069(VS.85).aspx
this made changes to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\WinHttpSettings. But looking into procmon output gave
me
the fact CDB really looks to
HKLM\Software\Wow6432Node\Microsoft\windows\CurrentVersion\Internet
Settings\Connections, so I exported settings from the first node and
imported
to the second one. Sad to say it didn't help.
I tried also adding .symopt-0x80000 command at the beginning of CDB script
to be sure CDB will try authenticate to our HTTPS symbols server. It didn't
help, too. At the end of this "adventure" I added !sym noisy to the CDB
script and saw the following:

SYMSRV: Assertion at d:\fbrel\sdktools\debuggers\symsrv\ini.cpp, line 258.
SYMSRV: WinHttp interface using proxy server: proxy_server
SYMSRV:
d:\RegDump\WinDbg\symbols\ourmodule.pdb\ACB4FBA56C294B3D90905F14900F3EEB1\ourmodule.pdb
not found
SYMSRV:
https://symsrv.ourdomain.com/symbols/V6/ourmodule.pdb/ACB4FBA56C294B3D90905F14900F3EEB1/ourmodule.pdb
not found

There are three questions for me in this output. First, what is the
assertion which I don't see when running from command line? Second, does
mentioning "proxy_server" means WinHTTP will try reaching
https://symsrv.ourdomain.com using it or just that is sees proxy settings
installed? (As you can see above, I added *.ourdomain.com to bypass list.)
The third and the last, why it says pdb on symbol server not found while it
is there (I checked this copypasting address to IE - downloading starts). I
get the same message after resetting proxy configuration in Wow6432Node to
direct access.

My last supposition is registry parameter "NoInternetProxy" mentioned in
HTTPS Proxies section of symhttp.doc. That section states that SymProxy has
a
dummy proxy that it uses when to proxy configuration is set. This thing is
quite unclear to me. But setting "NoInternetProxy" to 1 seems to set up
SymProxy behaviour like I want to CDB. And I think, maybe CDB and SymProxy
use the same common DLL or just common logic and there is "NoInternetProxy"
parameter for CDB? But I don't know whether it is and where to set it.

Finishing experiments for today...

Post by pat styles [microsoft]
Hello Roman.
You are correct. WinInet does not work when called by an application that
is run as a service. Consequently we use WinHttp. There are different
requirements for using WinHttp. It does not use your IE proxy settings by
default as WinInet does. Also, it has a single set of communications
settings for the entire computer instead of user profile-specific stuff.
I
would presume that your problem is related to this, and/or the fact that
your service account has different network (https) privileges than the user
account one might normally run through.
If you are going to run the debugger as a service, you need to involve
someone in your company that has network expertise on your security layout.
Here is a comment from symhttp.doc that contains some relevant data.
HTTP Proxies
When running as a service as SymProxy does, SymSrv uses the WinHTTP API to
access symbols over HTTP. (Normally it uses WinInet.) Consequently, you
may also need to set up HTTP proxy settings so that the service can access
outside network resources. You can do this using the netsh program. Type
“netsh.exe winhttp -?” for instructions. When using versions of Windows
that were released previous to Windows Vista and Windows Server 2008, you
should usethe proxycfg program. Type “proxycfg.exe -?” for instructions.
..pat styles [microsoft]

[Roman Ru]

Hi pat. Thank you very much for your advice, it works! It's what we really
need.

P.S. It's interesting Google finds nothing for DBGHELP_WININET and WinDbg
help does too. I can't imagine how could we know about this trick without
your help. :)

Post by pat styles [microsoft]
Hello Roman.
It looks like you have an unsolvable problem.
When running as a service, cdb needs to use the WinHttp interface.
Cdb, when running the WinHttp interface does not support HTTPS connections
because WinHttp does not contain the facilities to poll for credentials that
WinInet has.
My only suggestion is that you set DBGHELP=WININET=1 in the environment of
the service account and see if you can force cdb to use WinInet. However
this is totally unsupported. I can't say this will cause cdb to use WinInet
and if it does, I cannot say that WinInet will work anyway from the service.
..pat styles [microsoft]

[pat styles [microsoft]]

This post might be inappropriate. Click to display it.