Lee Culver

Same problem. The issue seems to be that `RichCodeNav.EnvVarDump` is missing? Here's what the package manager output looks like when attempting to add the "DllExport" nuget package: ``` GET https://api.nuget.org/v3-flatcontainer/richcodenav.envvardump/index.json...

One note here: We always expect ThreadStore data to be placed into well-formed CLR dumps (even down to triage dumps). This means that if the dac request for ThreadStoreData fails...

Maybe related to #675?

`build -c release` will generate an x64 release version. Any SOS will debug .Net 6 dumps, but SOS itself is compiled against desktop framework, not .Net 6.

@Moonfish Thanks for the info/investigation! Maybe this issue should be titled: "Single File module scan takes a very long time" or something similar. Is it ok if I rename/repurpose this...

ClrMD 2.0 does work on Unix (both linux and os x), and overall it's a much better product. I think some of those specific apis (IsThreadpool*) are missing, but IIRC...

Ah I forgot about this issue. It wasn't assigned to me so it wasn't on my radar. The missing pieces should be there in ClrMD 3.1. They are just under...

This should already be fixed in ClrMD. If the diagnostics team is still picking up daily builds then the fix is already in the diagnostics repo, it's just waiting for...

Oh, this is about ClrMD specifically. Yes it's fixed in our devbranch. I'll push a new build to NuGet tomorrow.

I ran into this today. It would have been really nice to have had this feature in SOS for something I'm investigating in AzureWatson. (Yep, it was ConcurrencyBag.) I'm assigning...