4

We are setting up a local SymbolSource server for our development team. We followed a nice article written on SymbolSource server. We use TeamCity for building. For each build .symbols.nupkg is pushed to local SymbolSource using nuget push command and nuget package is pushed to local NuGet server.

Problems we are experiencing:

For nuget package MyPackage.1.1.0 if we push same to symbol server it creates hash and that's how it associates for each version folder to load .pdb files and .cs files. (That's my understanding. Please correct me if I am wrong).

After setting up the symbol server configuration in Visual Studio we try to debug the project. What we are experiencing is that the hash generated by Visual Studio to load the symbols is completely different than the hash generated while registering using nuget push on symbol server which ends up in 404. (Please see attached file with fiddler status code.) If we create a folder manually with the same hash on Symbol server we get the desired outcome i.e. step into code.

Why are there two different hash for the same version of dll/nuget file?

Two different guid's generated Fiddler output

Community
  • 1
  • 1
David Karen
  • 137
  • 1
  • 5

1 Answers1

2

The values you are getting are not hashes (as in they are not file content hashes), they are GUIDs. Each DLL - PDB pair is assigned a GUID when they are build. Each build of a DLL has a different GUID, even if they are build from exactly the same source code! This means that the only way you will get the PDB's from the symbol server is if you use exactly the same DLL. The fact that you are getting a completely different GUID indicates to me that you aren't using the same DLL. So the scenario's that I can come up with in that case are:

  • Your symbol nuget package has a different dll from your normal nuget package. This seems unlikely if you generate both at the same time, however if you build the package and the binaries more than once, that is possible.
  • You are not using the dlls from a nuget package that has had its symbol package registered with your symbol server
  • You are not using the dll from a nuget package at all

The reason your 'fix' works is because Visual Studio apparently only uses the GUID to create the symbol search path but doesn't check the PDB GUID when it loads it. In other words, it assumes (fairly) that the symbol server puts the symbols in the correct location.

The best way to fix your problem would be to find out where you are getting the different DLLs from. You can use the dumpbin utility to find out which PDB is linked to which DLL by using 

dumpbin.exe /headers mypackage.dll

That should produce an output that contains somewhere the path of the PDB file and(!) the GUID that links the DLL and the PDB. If you compare the GUIDs and the timestamps of the DLL on your computer with the ones in the DLL / PDB on the symbol server you should be able to figure out where things went wrong.

Petrik
  • 1,961
  • 13
  • 23
  • It's not a GUID, it's a timestamp. You can convert the timestamp to a date time value in WinDbg using `.formats `, e.g. `.formats 5011B05E` will output `Thu Jul 26 23:02:22 2012`. – Thomas Weller Apr 16 '14 at 06:33
  • Maybe I was wrong. It seems they have a GUID *and* a timestamp. – Thomas Weller Apr 16 '14 at 07:35
  • Wow !! Such a detail answer without even me putting images. Appreciate you taking time and putting me on right path. Thanks Thomas for reading my question and try to help me out !! I looked at details and found that both dll's are having different guid generated. It has made my problem more interesting now "Why such behaviour?". I will try out possible options and will ask community if I don't reach conclusion. Thanks again !! – David Karen Apr 16 '14 at 13:40
  • @ThomasW. As I recall, a timestamp signature was initially used to identify the binary. However, this had many draw backs and did not scale well. The fix was to use GUIDs, which is the primary option now. – Dono Apr 17 '14 at 01:17