The same behavior occurs with string.Empty
**Investigation:**
The !do command ends up calling a few functions
[Strike.cs|DumpObj](https://github.com/dotnet/coreclr/blob/master/src/ToolBox/SOS/Strike/strike.cpp#L2011)
-> [Strike.cs|PrintObj](https://github.com/dotnet/coreclr/blob/master/src/ToolBox/SOS/Strike/strike.cpp#L1488)
-> [Util.cs|DisplayFields](https://github.com/dotnet/coreclr/blob/af46c514824aacd4d439eb1891d3d392c6894476/src/ToolBox/SOS/Strike/util.cpp#L1452)
-> [Util.cs|DisplaySharedStatic](https://github.com/dotnet/coreclr/blob/af46c514824aacd4d439eb1891d3d392c6894476/src/ToolBox/SOS/Strike/util.cpp#L1243)
This last function iterates on appdomains and calls [ClrDataAccess::GetDomainLocalModuleDataFromAppDomain](https://github.com/dotnet/coreclr/blob/af46c514824aacd4d439eb1891d3d392c6894476/src/debug/daccess/request.cpp#L3216) with a moduleID as an int (which is 32 bits even in x64)
This moduleID was an ULONG64 in DisplaySharedStatic but cast as an int
In .NET Framework, the moduleID seems to be an "index" like 1, 2 or 3 but in .NET Core, it looks like an address. The test on moduleID in GetDomainLocalModuleDataFromAppDomain will always fail:
if (appDomainAddr == 0 || **moduleID < 0** || pLocalModuleData == NULL)
return E_INVALIDARG;
I have tried to change the interface to pass a CLRDATA_ADDRESS instead of an int
(this change impacts src/debug/daccess/dacimpl.h, src/debug/daccess/request.cpp and src/pal/prebuilt/inc/sospriv.h)
but it is not really better:
The code below the test does not make sense to me:
`ModuleIndex index = Module::IDToIndex(moduleID);`
static ModuleIndex IDToIndex(SIZE_T ModuleID)
{
ModuleIndex index(**ModuleID >> 1**);
return index;
}
Why dividing an "address" by 2 to get an "index"?
And the next line crashes when trying to GetModuleSlot
DomainLocalModule* pLocalModule = pAppDomain->GetDomainLocalBlock()->GetModuleSlot(index);
Note: this is the same problem as https://github.com/Microsoft/clrmd/issues/214 with ClrMD.
Moved from coreclr #https://github.com/dotnet/coreclr/issues/22248. Submitted by @chrisnas.
Repro: