Remote callstack symbol resolution and Dynamic PGO

[seanhalliday]

We distribute optimized .NET 8 dlls to our clients and would like to avoid sending pdbs (due to size and the frequency that some clients get new revisions). The application is a mix of managed and unmanaged code. When an exception occurs we would like the ability to resolve the callstack file and line numbers (as best as possible) on a remote server. We already have a solution for our C++ code. We also would like to resolve callstacks from paused threads - we do this when an exception occurs to get the callstacks of other running threads to help diagnose the crash in case it is concurrency related.

Currently we can do most of this by using the Microsoft.Dynamic.Runtime libraries which can attach to a running application or load a dmp file (which we can generate for the remote server). My concern is that once Dynamic PGO starts replacing methods, the dmp file will be out of sync with the running application and will not be able to resolve addresses accurately.

From an exception I can get ILOffsets, are these updated accurately when Dynamice PGO replaces methods?
Is there a way to get ILOffsets from addresses? Ie if I had an external application X that paused application A, could I get the ILOffsets of the paused threads in A?

If I have ILOffsets how would a remote server resolve these to file and line numbers (maybe Mono.Cecil?)

[AndyAyersMS]

Dynamic PGO doesn't change anything from a diagnostic standpoint... the runtime was already "replacing" methods with TieredCompilation (since .NET Core 3) and Dynamic PGO uses the exact same mechanism. The IL stays the same but the native code changes from one version to another. And each distinct native version of a method contains its own native->IL offset mapping, accurate for that version.

[seanhalliday]

Thank you so much for your answer. I was starting to suspect something like that. What confused me was that we were using the Microsoft.Diagnostic.Runtime.ClrThread.Address. I assumed it was native but it could be native for native code and an ILOffset for managed code. It’s not documented as such and the method ClrRuntime.GetMethodByInstructionPointer was not named …ByILOffset.

Is there a library that converts native methods to ILoffsets? I want to be able to have native code that calls managed code catch exceptions and parse the managed stack.

[AndyAyersMS]

I'm not sure. You might need to ask folks over in the CLRMD repo.