Symbol Server id issue

[it_9582]

Hi there,

I currently want to evaluate the possibility to of using a nuget Feed as Symbol-Server (configured as Mixed) for our self compiled applications.
To do this I attached the *.pdb File into a simple nuget package based on the following sample nuspec File:

<?xml version="1.0"?>
<package >
  <metadata>
    <id>Sample Tool</id>
    <version>1.0.0</version>
    <authors>Our Company</authors>
    <description>Native C++ Application</description>
  </metadata>
  <files>
    <file src="sample_tool.pdb" target="lib" />
  </files>
</package>

I uploaded this package into the feed, which shows me the package and also on the Symbols tab the pdb file with Id (58544d524263363572307558336f79534a39392b45413d3d) and Age (1).

Now I configured the windbg to interact with the Feed Symbol-Server (set Symbol path to <Server-URL>/symbols/<feed-name>) and open the Executable for this pdb File.
I activated than the noisy symbol loading (!sym noisy) because there are some issues while loading the symbols. The Log shows me that windbg want to download the pdb File from the a different URL, because the id is different (/symbols/<feed-name>/sample_tool.pdb/0511335DB9CE4BAF97DE8C9227DF7E101/sample_tool.pdb
).

I analysed our PDB File and it seems that the ID generation of ProGet has possibly a issue because a call of llvm-pdbutil dump --summary sample_tool.pdb results in the following Information:

• Age = 1
• GUID = {0511335D-B9CE-4BAF-97DE-8C9227DF7E10}

After combining this data (GUID + Age) the result is 0511335DB9CE4BAF97DE8C9227DF7E101 which is the same as Windbg want to download 0511335DB9CE4BAF97DE8C9227DF7E101.

Do you have any suggestions what I can do to use this feature?

Best regards

[atripp]

Hi @it_9582 ,

What version of ProGet are you using? There was a recent regression (PG-3204) that was fixed in ProGet 2025.19 with regards to symbol server. S hopefully upgrading will fix the issue.

Cheers,
Alana

[it_9582]

Hi @atripp,

currently we are using ProGet 2025.14, so we first check if an upgrade of ProGet 2024.19 or higher would fix the Issue.
I will reply to this topic if the Issue always exists.

Best regards

[it_9582]

Hi @atripp,
we have upgraded our ProGet Version to v2025.22 (Build 14) but the issue seems to be persist.
I have also repackage and reupload the package but the result is still the same.

The Information on windbg is also the same (it attempts to download the pdb-file with the ID 0511335DB9CE4BAF97DE8C9227DF7E101 but the Symbol on ProGet-Symbol shows me the ID 58544d524263363572307558336f79534a39392b45413d3d).
The Log in Windbg looks like the following:

SYMSRV:  BYINDEX: 0x2
         c:\symcache*<ProGet-Base-URL>/symbols/<feed-name>
         <pdb-name>.pdb
         0511335DB9CE4BAF97DE8C9227DF7E101
SYMSRV:  HTTPGET: /symbols/<feed-name>/<pdb-name>.pdb/0511335DB9CE4BAF97DE8C9227DF7E101/<pdb-name>.pdb
SYMSRV:  HttpQueryInfo: 80190194 - HTTP_STATUS_NOT_FOUND
DBGHELP: <pdb-name> - no symbols loaded

I have tested to manually download the file (over both IDs) but each time I get a 404 from the ProGet-Server with:

• <ProGet-Base-URL>/symbols/<feed-name>/<pdb-name>.pdb/0511335DB9CE4BAF97DE8C9227DF7E101/<pdb-name>.pdb
• <ProGet-Base-URL>/symbols/<feed-name>/<pdb-name>.pdb/58544d524263363572307558336f79534a39392b45413d3d/<pdb-name>.pdb

Best regards

[atripp]

Hi @it_9582 ,

If I'm understanding correctly, the issue is that windbg is attempting to download the symbol with an ID of 0511335..., but the only symbol you're seeing in ProGet is 58544d5...?

Since this is for C++, this is the Windows/PortablePdb format. In that case, ProGet is using the built-in class called MetadataReader to parse this information. I mean it's possible there's a bug in there, but I think it's more likely that it's the wrong file getting uploaded or something to that effect.

As far as the URLS... I'm not sure what the correct one is, but windbg seems to try a whole bunch of URLS before it lands on the correct one in ProGet. But if you're seeing that 58544d5... symbol in ProGet, then it would be downloadable.

Thanks,
Alana

[it_9582]

Hi @atripp,

yes, this is correct. Windbg wants to download the symbol with ID 0511335... but ProGet shows me Symbol 58544d5... for the pdb in my uploaded nupkg.

I have now dumped now the pdb file header which shows me that our pdb is a Windows PDB (Full) not a PortablePdb. Could it be possible that the MetadataReader is impossible to read the Windows PDB Files, because it reads the metadata defined by ECMA 335 instead of MSF?

Why the Download of the 58544d5... Symbol file is impossible although it is listed, remains a mystery to me too. Is it possible to get more debug informations from the System to analyse it deeper?

Best regards

[atripp]

Hi @it_9582 ,

I'm not really sure the differences between the files to be honest. But that could be possible?

I know some of the PDB code is really ancient (like 30+ years) and it uses old .exe files that no other program can read. I'm not sure if that is true.

This is the code we use, by the way:

var provider = MetadataReaderProvider.FromPortablePdbStream(source, MetadataStreamOptions.LeaveOpen);
var reader = provider.GetMetadataReader();
if (reader.MetadataKind != MetadataKind.Ecma335)
    return null;
reader.DebugMetadataHeader.Id //<-- that is how we get the PDB ID

If that function is returning the wrong Id, then I don't know if we can solve the problem. It doesn't seem very feasible to write our own PDB parsing, and I don't think there's another way to do it...

Thanks,
Alana