Unable to debug dll source code with symbol server

I’ve blogged in the past about using a Symbol server and I recommend to all people to use symbol servers whenever possible, to helping people troubleshooting problem on dependencies. Basically with a symbol server you can reference a dll in your project, but you can debug original source code as if you have the original project linked instead of having the dll.

Sometimes this process just don’t work. Recently I’have a customer that had problem with this scenario, and the real strange stuff is: I’m able to step in dll source code without problem from any machine, but noone of the customer’s developers are able to make it work. After I’ve sent them detailed instruction it worked, and we were able to track down the problem.

Visual Studio has a nice option to cache symbols in local directory to avoid downloading each time from the server. Here are my usual settings.

Visual Studio options to use local folder as a symbol cache

Figure 1: Visual Studio symbols settings

Developers in customer sites decided to use a subfolder of %TEMP% directory and this was the cause. As soon as they moved symbol cache to something like c:\symbols everything starts working. The underling cause is probably due to long paths.

If you have problem using symbol server, try using a really short path for your Symbols Local Cache directory.

In this specific situation we are using free symbols server in conjunction with MyGet nuget package feeds. In my machine here is the location for a source file during debugging.

Z:\Symbols\src\pdbsrc\MyGet\alkampfer\11111111-1111-1111-1111-111111111111\BIGEND\GianMariaRicci\Jarvis.Framework.Kernel\2C5AB5CBD1C74688974B2DDB55F51EDA1\Jarvis.Framework.Kernel\ProjectionEngine\ConcurrentProjectionEngine.cs

Usual %TEMP% variable is something like c:\users\gianmaria.ricci\appdata\local\temp (this is my system and it is long 44 characters), so it is not a good idea to use it for symbol source cache.

Since it is really easy to have really long path for your source when you use a symbol server, it is always a good idea using a short path for symbols cache directory, something like x:\SymSrc is probably the best solution.

If this does not solves your problem, another suggestion is using Fiddler to inspect the traffic between your Visual Studio and the Source Server to understand what is happening.

Gian Maria.

Published by

Ricci Gian Maria

.Net programmer, User group and community enthusiast, programmer - aspiring architect - and guitar player :). Visual Studio ALM MVP

8 thoughts on “Unable to debug dll source code with symbol server”

  1. Via my feedly I came to read this post and started checking my settings, because I couldn’t debug into my libraries either.

    Turned out the cache path was completely empty for me. So I put in a path, turn on some flags (enable source server support + 3 under that), but symbols aren’t loaded. ‘Enable just my code’ is disabled. The cache folder remains empty. (VS is run as Admin)

    I checked the symbols server/unc/path where the build puts the files and those have the latest version.
    VS is trying to look for E:\Builds\5673\…, which is the path of the file on the build server at built time.

    I know this used to work some time back. Had a few reinstalls of my box since then.

    Could this be related to the fact that the assemblies are referenced via a NuGet package? I actually have the pdb files in the package, but that seems to do nothing at all.
    Do you have any ideas?

    If you don’t have any, I might try creating symbols packages as per https://docs.nuget.org/create/creating-and-publishing-a-symbol-package

  2. You should give me a little bit more information. It seems that you are using a TFS build to use symbol server, and at the same time you are publishing your dll with Nuget.
    In such a scenario, the problem could be originated by a wrong build, that creates nuget package before indexing the sources, it happened to a couple of customers in the past.
    Are you the only people that is using symbol server? Any other member of the team is able to use them?

  3. The TFS build copies the symbols to the UNC.
    After the build, I manually run a powershell to packages up the dll (and pdb) file into a nuget package that gets copies to another UNC (the internal nuget server).

    I had a colleague try and he couldn’t break into the symbols either. He also recalled it used to work.

    After some more testing, I found one internal package where I can step into the symbols/source. So something is working.

    Right now I’m at the point of asking my boss for a private MyGet feed which has SymbolSource.org support. Cheaper than wasting time to figure this out.

  4. From what you told me, it seems that something in the build is changed, and source were not indexed correctly. You should open PDB with some editor (it is binary, but some part can be read as text) to verify that it contains information about sources in TFS.

    Have you tried with fiddler to check requests issued by Visual Studio, both with the package where symbol source works and for the package that does not work?

  5. So I opened up a PDB. An example of what I see:
    e:\Builds\5761\NatchOS\Natch.Base_Main_Full\src\Source\src\Natch.Base\ArgumentValidation.cs

    This was the file’s path on the build server. It’s Team Build (xaml), on prem , 5761 is build agent id I believe.
    The sources are actually on VSO now. Migrated a few weeks back.
    So what path should I see there? Ant tips on how I can fix it?

    Also trying out myget and symbolsource.org, when upload .symbols.nupkg it throws an error, also because it can’t access the source files, which apparently need to be included in the nupkg :-(

  6. You should see in pdb some reference to the original TFS address of the file. You should double-check build logs to verify the publishing symbols did not generates some errors.

    If you want to use myget you should be aware that you should include all sources inside the symbols.nupkg package, it is more suitable approach for open source project.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.