Open stjeong opened 1 month ago
This dump file is based on a basic console app.
If you open the dump file using this code,
using (DataTarget target = DataTarget.LoadDump(dmpFilePath))
{
ImmutableArray<ClrInfo> clrVersions = target.ClrVersions; // have to wait for so long time, because of the loop
}
You can't miss the problem.
For dump file in windows, Reader class is defined in ".\Microsoft.Diagnostics.Runtime\DataReaders\Minidump\MinidumpReader.cs" set "isVirtual" argument as true.
public IEnumerable<ModuleInfo> EnumerateModules()
{
return from module in _minidump.EnumerateModuleInfo()
select new PEModuleInfo(this, module.BaseOfImage, module.ModuleName ?? "",
true, // !!!! HERE
module.DateTimeStamp, module.SizeOfImage);
}
Description
At .\Microsoft.Diagnostics.Runtime\DataReaders\Core\CoreDumpReader.cs,
CreateModuleInfo always create PEModuleInfo instance with "virtualHint == false",
When dll image in memory dump file has 'export data directory', this code lead to almost infinite loop because of invalid ImageExportDirectory instance given by TryGetExportSymbol method.
At the code of "RvaToOffset" method,
Because _isVirtual is false, it doesn't run second if's "return virtualAddress", instead it calculates the value as RVA for PE offset, like loading from FILE directly.
Of course, the return value is incorrect address, the caller(TryGetExportSymbol) fills exportDirectory with garbage.
Other information
This problem is not a problem when loading memory dump for .NET 6 or later, because most .NET 6 DLL (for example: System.Private.CoreLib.dll) has no export data directory.
However, if the memory dump contains user DLL with export data directory, DataTarget.LoadDump and DataTarget.ClrVersions runs a lot of loop (because the loop count in TryRead method is filled from garbage). And for .NET 5 memory dump in linux, you can meet the problem, because System.Private.CoreLib.dll has export data directory, whose size is 0x43.