CLR Symbols for Beta 2 release imminent

There was a problem with the original publication of the CLR Symbols for some binaries (mscoree, mscorwks, maybe others).  This was causing the profiler to be unable to load symbols for these binaries.  The end result was a lot of [mscoree.dll] function names in all profiling reports.  I have been informed that these should be up on the public symbol servers very soon (today or tomorrow).

Thanks for your patience.


UPDATE!! This is still broken.  More to come….


Comments (11)

  1. Will Dean says:

    Thanks for this – I look forward to seeing them there later.

    Just out of interest, what is the ‘proper’ way to report missing symbols on SymServ – for example (and not your remit at all, I’m sure), it doesn’t seem to have ole32.dll symbols for the version I have on this machine, which is presumably just some kind of oversight.

    SymServ is a fantastic concept, but it always looks as though it’s not really owned by anyone who cares.

    For example, I’m sure someone who really cared would change it to not return nearly 2K of style sheet, blather, etc, with every 404… That server must serve a LOT of 404’s, and for every one it does, there’s a developer somewhere in the world drumming his fingers on his desk waiting for a debug/profiling session.

    Can we have a SymServ team blog so we can whine at them (sorry, encourage continuous improvement) directly?

  2. Will Dean says:

    While I’m being boring about this, the profile people might also want to look at the number of times they apparently ask to load the symbols. The following is an HTTP Fiddler log of attempts at the symbols during the post-processing of a profiler run of Rico’s test app. Obviously, if SymServ had the right symbols, most of this would be silently coming from my local cache, but even so, is it significant that everything’s being tried at least twice? (And msvcr80 four times)“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>“>


  • scarroll says:

    Actually all of the symbol server functionality that causes all those reloads is implemented by symsrv.dll which is owned by the windbg guys. (Windows debugger team) We just give it a name and some identifying data and it goes chasing the files.

    Let’s try to dig down a little deeper on this issue. Use vsperfreport.exe with the -debugsympath switch. Does the number of tries listed there match up at all with number of calls out to I actually have some contacts on that team so we can see what we can do about this if its causing you pain. Toss me an email… (scarroll -at- microsoft, etc)

    The problem with symbol server is that each team is responsible for getting their own symbols up. Hence the overlapping responsibilities and the screw up. As a result of this exercise we now know exactly who is in charge of these symbols so we have been assured steps have been taken to make sure it doesn’t happen again. We’re real sorry about that.


  • Pavel Lebedinsky says:

    If you have problems with symbol server (missing symbols, bugs, feature requests etc) you can post them to the microsoft.public.windbg newsgroup.

  • Mike Dimmick says:

    Will – spot the underscore (_) which replaces the last character of the filename in the second request. I’d bet that the first request – for the file itself – gets a 404 response, whereupon SymSrv then tries the version with the underscore.

    Changing the last character to an underscore is a long-standing MS convention that indicates that the file has been compressed with the COMPRESS.EXE utility, decompressible with the LZ family of functions.

    Presumably the file.ptr file is an attempt to redirect if both of the above requests fail.

    If you knew that you were using the HTTP protocol, you’d probably use HTTP 1.1 ‘gzip’ compression rather than COMPRESS.EXE, and you’d use a 307 Redirect rather than the file pointer. That would require a web application, though, rather than just using the web server as a static data server.

  • Will Dean says:

    Mike – I wasn’t complaining about the three variants for each file – they’re as you describe, and have legitimate functions. It’s the fact that for each file, ALL THREE are repeated at least once.

    I’ll try and track-down why this happens for me with the profiler.

  • Will Dean says:

    Right, my last post on this subject in poor Steve’s blog…

    I think that the duplicate look-up might have been caused by having both the symbol path envvar set and the new symserv settings in VS2005.

    There is still a strange effect in that you get more symbols looked-up when running the profiler in VS2005 than when you run vsperfreport from the command line.

    And finally (honest), those missing symbols still haven’t made it to the server.

  • Willy Denoyette - MVP says:

    The public symbol servers aren’t updated yet, they still throw us the December CTP (Beta1) bits.

  • Visual Studio Team System

    Yesterday marked the one-year anniversary of the public announcement of…