runtime: Fatal error. Internal CLR error. (0x80131506) in .Net 7

Hi @mangod9,

Thanks for your response. Yes if there’s any way possible it would be very helpful - I’m hoping such a core/integral part might be able to expedite it? (As I’m sure other users may find this to be an obstacle to upgrading to .NET 7.0 - and more in the coming weeks?)

Hi @PeterSolMS,

Thanks for your message. The fixed-clrgc does indeed seem to fix the issue! Thank you very much.

My steps:

I installed the bare bones .NET Runtime 7.0.0 on a VM that had never had .NET core etc… installed on it previously. Plus I installed windbg from the Windows SDK installer.

So before I used ‘set DOTNET_GcName=clrgc.dll’ I ran it as usual and it bugged out exactly as previously described. (There was no ModLoad corresponding to a clrgc.dll which I made sure of as there was the original one in the C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0 folder.)

(I renamed the dlls you provided just to be absolutely certain.)

---

I then used ‘set DOTNET_GcName=clrgc_baseline.dll’ and it was loaded as expected:

ModLoad: 00007ffd664d0000 00007ffd6656c000 C:\Windows\System32\msvcp_win.dll ModLoad: 00007ffd3d070000 00007ffd3d11d000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0\clrgc_baseline.dll (12cc.1308): Unknown exception - code 04242420 (first chance) ModLoad: 00007ffd3c550000 00007ffd3d06a000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0\System.Private.CoreLib.dll

It bugged out exactly as previously described (with an additional bit about the checksum, as expected):

12cc.1308): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0\clrgc_baseline.dll clrgc_baseline!MethodTable::HasComponentSize [inlined in clrgc_baseline!WKS::gc_heap::mark_object_simple1+0x47c]: 00007ffd3d0b65ec 418b0a mov ecx,dword ptr [r10] ds:0000000000000000=??? 0:000> dt coreclr!g_pConfig iGCHeapVerify 0x00007ffd`3d808d30 +0x054 iGCHeapVerify : 0n1 0:000> !VerifyHeap

Some !do commands output the same DocumentFormat.OpenXml.Spreadsheet.Cell(s) and DocumentFormat.OpenXml.Spreadsheet.Row as previously encountered.

---

I then used ‘set DOTNET_GcName=clrgc_fixed.dll’ and it was loaded as expected:

ModLoad: 00007ffd664d0000 00007ffd6656c000 C:\Windows\System32\msvcp_win.dll ModLoad: 00007ffd3d8d0000 00007ffd3d97d000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0\clrgc_fixed.dll (da0.11c): Unknown exception - code 04242420 (first chance) ModLoad: 00007ffd3cdb0000 00007ffd3d8ca000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0\System.Private.CoreLib.dll

The program ran to completion successfully producing a readable xlsx of about 3MB in size, as expected.

I also expanded on the (same) record source to produce another readable xlsx of about 10MB in size and 230k rows 16 columns, as expected.

The process’s memory went to just under 2GB but OpenXml is known to be a memory hog (it’s a known issue on the GitHub page) - but it shows at least that the GC is handling a large amount of memory with millions of references, which is good! (In my limited understanding…)

I then expanded on the (same) record source to write 3 identical worksheets (230k rows each again) and it again produced another readable xlsx of about 31MB in size.

The process’s memory went to 6GB but again this doesn’t surprise me - I guess though that since there are, in my code, periodic calls to GC.Collect, that the issue is fixed!

Thank you very much!

---

A question please: I have no idea about how .NET is updated or released but can I bother to ask when you think your fix might make it into the downloadable .NET releases please?

(Please also let me know if you need anything else from me.)

Hi @Maoni0, whatever it takes! Please let me know. And thank you.