-
-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support full Windows PDB format for .NET #871
Comments
@jamescrosswell could you help with a sample build on Windows? The attached sample was lost due to the repo being deleted. We should be able to get those Windows PDBs by building a .NET Console app on a Windows machine. It should be generating Windows PDBs as opposed to on Mac and Linux where it uses Portable PDBs. |
This was referenced Oct 17, 2024
loewenheim
added a commit
to getsentry/symbolicator
that referenced
this issue
Nov 11, 2024
#1541) This adds a new `CacheError`/`ObjectFileStatus` variant for cases where a debug file is OK, but can't be used for the purpose for which it was requested. Currently the only such case is symbolicating .NET events with portable PDB files (see getsentry/symbolic#871). In addition, this also makes Symbolicator request both portable PDB and Windows PDB files for symbolicating .NET events. The reason for this is that although Windows PDB files can never be used for that purpose, at least this way we get a concrete error status we can report to the user. If we don't do that, we get cases like #1539.
loewenheim
added a commit
to getsentry/symbolicator
that referenced
this issue
Nov 20, 2024
#1554) This adds a new `CacheError`/`ObjectFileStatus` variant for cases where a debug file is OK, but can't be used for the purpose for which it was requested. Currently the only such case is symbolicating .NET events with portable PDB files (see getsentry/symbolic#871). In addition, this also makes Symbolicator request both portable PDB and Windows PDB files for symbolicating .NET events. The reason for this is that although Windows PDB files can never be used for that purpose, at least this way we get a concrete error status we can report to the user. If we don't do that, we get cases like #1539.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From: https://github.com/getsentry/team-ingest/issues/490
We have symbolication for the .NET Portable PDB format, and for the Windows PDB format with native code, but not for the Windows PDB format as used by .NET.
It would be useful to support this, so that we can symbolicate .NET Windows apps and libraries that are compiled using this debug format when symbols are not available client-side.
See https://learn.microsoft.com/dotnet/csharp/language-reference/compiler-options/code-generation#debugtype
Debug types full or pdbonly when compiled on Windows will generate a Windows PDB, not a Portable PDB. (The pdbonly option creates a variation which is more optimized for release builds, so both should be supported if possible.)
This applies both to .NET Framework and to .NET Core (and modern ".NET").
--
See attached zip containing two console app projects. One is .NET 6 and the other is .NET Framework 4.8.
FullPDBProjects.zipfile is lost, we'll find a replacement
In both projects, the Debug build was compiled with DebugType=full and the Release build was compiled with DebugType=pdbonly. (These are the default settings for .NET Framework out of the box.)
All .pdb files here are Windows format PDBs, not portable PDBs.
Also note that .NET 6 compiles a .dll containing the application code and a .exe "wrapper" program with the entrypoint. This is the new way since .NET Core 1.0. But .NET Framework compiles a single .exe containing all code and the entrypoint in a single file.
The text was updated successfully, but these errors were encountered: