HEAP2 heap dumps missing PE metadata for ~75 types from non-R2R shared framework assemblies

[max-charlamb]

Summary

Commit c835d0f ("Change heap dumps to use HEAP2 as the default", #127321) causes ~75 types from non-R2R shared framework assemblies to have unresolvable names in heap dumps. These types have valid MethodTables, Modules, and mdTokens in the dump, but the PE metadata pages for their assemblies are missing, so TypeString::AppendType cannot read the type name.

Affected Assemblies

• Microsoft.Extensions.Options.dll
• Microsoft.Extensions.Logging.Debug.dll
• Microsoft.Extensions.Logging.EventLog.dll
• System.Private.CoreLib.dll (at least one type)

Evidence

Running !dumpmt on UNKNOWN types shows valid metadata except the name:

!dumpmt 00007ffa432fce58
EEClass:         00007FFA43145EB0
Module:          00007FFA42FB3EC0
Name:            <error>
mdToken:         0000000002000039
File:            Microsoft.Extensions.Options.dll

The old HEAP path enumerated these by iterating m_TypeDefToMethodTableMap → MethodTable::EnumMemoryRegions → Module/PEAssembly/PEImage::EnumMemoryRegions, which captured the PE metadata pages. HEAP2 relies on LoaderAllocator heap enumeration which captures the MethodTable bytes but not the referenced PE image metadata pages.

Impact

• !timerinfo crashes with Debug.Assert when it hits one of these types (fixed in [cDAC] Fix GetMethodTableName empty type name mismatch #127405)
• !dumpheap -stat shows ~75 types as UNKNOWN
• Any SOS command resolving type names may show <error> for these types

Related

• [cDAC] Fix GetMethodTableName empty type name mismatch #127405 — Fixes the native DAC E_OUTOFMEMORY for empty type names (separate bug exposed by this)
• Change heap dumps to use HEAP2 as the default #127321 — The commit that changed dumps to HEAP2

/cc @hoyosjs

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[max-charlamb]

Note

This comment was generated with the assistance of GitHub Copilot.

Correction: HEAP2 dumps are NOT the problem

Our earlier analysis used a mismatched DAC to read Rachel's CI dump — we used our locally-built DAC which didn't match the CI build's coreclr.dll. When we download the matching runtime artifacts from the CI build and use those to analyze the dump:

	Mismatched DAC	Matching DAC	Old HEAP (local)
Resolved	405	1594	1649
UNKNOWN	1264	75	70

With the correct DAC, HEAP2 resolves 1594 types — essentially identical to the old HEAP path (1649). The 75 remaining UNKNOWNs are normal (same as the 70 in old HEAP dumps — likely dynamically generated types).

The HEAP2 change (c835d0f) is not causing a regression in type name resolution. The dump data is complete. The real issue is just the E_OUTOFMEMORY vs S_OK mismatch for the few types that genuinely can't be resolved (the 75 UNKNOWNs), which is fixed in #127405.

I'll close this issue as the HEAP2 regression theory was incorrect.

[max-charlamb]

Closing — the HEAP2 regression theory was incorrect. The issue was a mismatched DAC during local analysis. With the correct DAC, HEAP2 dumps resolve the same number of types as old HEAP dumps. The actual fix for the SOS.WebApp3 test failure (E_OUTOFMEMORY handling) is in #127405.

[max-charlamb]

Note

This comment was generated with the assistance of GitHub Copilot.

Updated Analysis: HEAP2 regression IS real (for non-R2R assemblies)

My earlier correction was wrong — the issue IS a HEAP2 regression, but only for specific assemblies. With the matching DAC, there are 75 UNKNOWN types. Running !dumpmt on them shows they all have valid Module, mdToken, and assembly file paths, but Name: <error> — meaning the PE metadata pages for those assemblies aren't in the dump.

The affected assemblies include:

• Microsoft.Extensions.Options.dll
• Microsoft.Extensions.Logging.Debug.dll
• Microsoft.Extensions.Logging.EventLog.dll
• System.Private.CoreLib.dll (at least one type: mdToken 0x0200012F)

Example !dumpmt output for an UNKNOWN type:

!dumpmt 00007ffa432fce58
EEClass:         00007FFA43145EB0
Module:          00007FFA42FB3EC0
Name:            <error>
mdToken:         0000000002000039
File:            Microsoft.Extensions.Options.dll

The MethodTable is accessible, the Module is known, the token is valid — but the metadata pages of the PE image aren't in the dump, so TypeString::AppendType → IMDInternalImport::GetNameOfTypeDef fails.

The old HEAP path enumerated these by iterating m_TypeDefToMethodTableMap which triggered MethodTable::EnumMemoryRegions → Module::EnumMemoryRegions → PEAssembly::EnumMemoryRegions for each type, capturing the PE metadata pages. HEAP2 relies on LoaderAllocator heap enumeration which captures the MethodTable bytes but not the referenced PE image pages.

This is the root cause of the SOS.WebApp3 test failure — !timerinfo hits one of these types and gets an empty name, triggering the Debug.Assert.

[hoyosjs]

This is by design - heap dumps don't page metadata. DataTargets are supposed to map it in as needed.