SymProxy problem with compressed symbols and changing case

115 views
Skip to first unread message

P.

unread,
Apr 3, 2009, 2:55:56 PM4/3/09
to
Hi

I am experiencing two problems with SymProxy.
1. SymProxy 6.11 does not attempt to retrieve compressed symbols and this
breaks the Microsoft symbol server.
2. SymProxy changes the URI case and this breaks Google Chrome and Mozilla
Firefox symbol servers that run on case sensitive Linux servers.


SymProxy 6.11 fails to retrieve compressed symbols:

SymProxy 6.8:
The client will query for notepad.pdb, SymProxy will query for notepad.pdb
get a 404, SymProxy will then query for notepad.pd_ download and decompress
it, and then serve notepad.pdb to the client.

SymProxy 6.11:
The client will query for notepad.pdb, SymProxy will query for notepad.pdb.
The client will query for notepad.pd_, SymProxy will do nothing.
The client will query for file.ptr, SymProxy 6.11 will do nothing.


SymProxy makes the URI lowercase breaking Linux based symbol servers like
Google Chrome (build.chromium.org/buildbot/symsrv) and Mozilla Firefox
(symbols.mozilla.org/firefox) symbol servers:

Direct to server URI:
/buildbot/symsrv/chrome_exe.pdb/A931F873616F40A4972373FAD37D562D1/chrome_exe.pdb
Client to proxy URI:
/symbols/ch/chrome_exe.pdb/A931F873616F40A4972373FAD37D562D1/chrome_exe.pdb
Proxy to server URI: URI:
/symbols/ch/chrome_exe.pdb/A931F873616F40A4972373FAD37D562D1/chrome_exe.pdb


I reverted the the proxy back to 6.8 to get Microsoft symbols.
The case sensitive problem will require Microsoft to stop changing URI case.

Any other ideas?

Regards
P.

P.

unread,
Apr 3, 2009, 8:24:05 PM4/3/09
to
Oops, copy and paste error, the correct Proxy to server URI is:
/symbols/ch/chrome_exe.pdb/a931f873616f40a4972373fad37d562d1/chrome_exe.pdb

Colbert Zhou [MSFT]

unread,
Apr 6, 2009, 6:50:51 AM4/6/09
to
Hello Peter,

I have transferred your feedbacks to PG through an internal discussion
channel. I will update with you as soon as possible if I get any response
from them. Thanks for your patience.

Have a nice day!


Best regards,
Colbert Zhou (colb...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

pat styles [microsoft]

unread,
Apr 7, 2009, 5:16:17 PM4/7/09
to
Hello.

This is a known bug and will be fixed in the next debugger release.

.pat styles [microsoft]

"P." <al...@newsgroup.nospam> wrote in message
news:EDED37C1-71D6-435D...@microsoft.com...

P.

unread,
Apr 7, 2009, 9:02:01 PM4/7/09
to
Hi Pat

Thanks for your reply.

Just to confirm, when you say "this" is a known problem, does that include
the broken Microsoft Symbol Server (compressed symbols) and the broken Google
and Firefox symbols servers (lowercasing of URI)?

I'd be happy to test pre-relase builds (you know how to contact me).

Pieter

pat styles [microsoft]

unread,
Apr 9, 2009, 12:26:58 PM4/9/09
to
Oh, it's you, Pieter. I'll move this thread offline for the time being.

.pat styles [microsoft]

"P." <al...@newsgroup.nospam> wrote in message

news:D1A1262B-762F-4F30...@microsoft.com...

P.

unread,
Apr 9, 2009, 7:53:01 PM4/9/09
to
After a bit of digging and coding I have a working workaround for the problem.

Read about it here:
http://blog.insanegenius.com/2009/04/broken-symbol-proxy.html

pat styles [microsoft]

unread,
Apr 17, 2009, 11:37:41 AM4/17/09
to
Just to be crystal clear here.

The fact that SymProxy did not grab compressed files was a bug in SymProxy.

The fact that SymProxy did not work with the Google and Mozilla Symbol
Server Stores is due to a problem with the implementation of the symbol
stores and not SymProxy.

All tools written for Windows debugging that use dbghelp.dll, DIA, or any
other pdb or file-system calls to get access to symbols and binaries, have
the right to expect that all requests for any type of a file will be
case-insensitive. This includes Visual Studio, WinDbg, SymProxy, and any
other third-party-developed tool that uses the APIs I previously enumerated.
Because there are so many such tools, it is reasonable to expect that some
of them (including SymProxy) may chose to change the case of the file names
or paths to the files. There is no way around this. Even if a "fix" were
applied to SymProxy, it is likely you will be bitten by another program.
For example, I believe that Visual Studio is known to alter the case of
symbol files in its' internal code.

Furthermore, note that the name of a PDB file is normally obtained from the
CV record within the PE header of an executable image. There is no contract
that specifies that this file specification for the PDB is case sensitive.
Therefore there is a lot of code in the field that presumes it is not.

My immediate reaction to this post was to remove the code in question that
lower-cased the file request. However after more thought on the matter, I
have to say that SymProxy is fully within its' rights to change the case of
a filespec.

That said, I have been in contact with the people that administer the symbol
server stores for Google and Mozilla. They understand the problem and are
acting or have acted to resolve it from their ends. I have also been asked
if I can put them in contact with anyone that has experienced the problem.
My presumption is that they want to test the fix. I cannot test the fix for
obvious reasons.

If anyone would like to test the fix, please send an email to my email
address, pat.s...@microsoft.com, and I will forward your email address to
those in the know.

thanks,
.pat styles [microsoft]

"P." <al...@newsgroup.nospam> wrote in message

news:D1A1262B-762F-4F30...@microsoft.com...

Reply all
Reply to author
Forward
0 new messages