Mike McLaughlin

This failure could be (most likely # 1): 1) Catching the GC in a place that the heap isn't consistent when the dump is created. SOS is suppose to display...

Sorry, I gave you the wrong command to check the GC. It is `eeversion`.

Yes, I've repro'ed the `Error: Fail to initialize coreclr 80070008` error on our M1. Initializing the managed hosting layer is failing for some reason which means managed commands like `dumpheap`...

`dotnet-sos install --arch Arm64` is the command. I'm pretty sure this will fix your issue.

The current released SOS should work just fine with .NET 9. What exactly is the problem?

Sorry, you are right the released SOS tooling doesn't look for .NET 9 for hosting so if that is the only installed runtime you get that error message. The main...

Looking at the command examples like dumpasync in https://github.com/dotnet/diagnostics/blob/50a1ea135699ce5c5d10a49c49e672597b95c99c/src/Microsoft.Diagnostics.ExtensionCommands/DumpAsyncCommand.cs is probably the best way to start. There is a little documentation on SOS extensibility here: https://github.com/dotnet/diagnostics/blob/main/documentation/design-docs/dotnet-dump-extensibility.md

I'm assuming you are using windbg to debug these crash dumps (but most of this applies to lldb for linux/macos dumps too). The SOS commands themselves only load managed assembly...

It looks like my theory about what is happen to you may be incorrect. I tried it locally with the newest version of cdb (same engine as windbg) with !sym...

Of course my test involved a small test app with not that many modules (either native or managed).