由于.NET运行时内部错误（退出代码0x80131506），我一直在追究我们的.NET服务之一间歇性崩溃的原因。有问题的服务不会执行通常会导致此类错误的任何操作（不安全代码，PInvoke等）。我已经尝试按照KB2679415中所述禁用并发GC，以及尝试切换到服务器GC，但是间歇性崩溃仍然存在。当以 debug模式进行编译时，该问题会在.NET 4.7.2和更早版本中显现。
该服务大量使用了旧版本的NHibernate（2.0.1），当我在调试器中检查了故障转储时，发生错误时，调用堆栈中总会有NHibernate代码，尽管NHibernate本身就是全部托管代码，因此不应导致此类崩溃。
我设法在调试器下并且启用了GC压力日志和堆验证的情况下重现了崩溃，尽管它似乎指向了JIT / GC中的问题，但我不确定我是否在解释输出正确。
查看发生崩溃的线程，在这种情况下，它发生在clr!JIT_Stelem_Ref：
clr!JIT_Stelem_Ref+0x18: cmp r9,qword ptr [r8] ds:aaaaaaaa`aaaaaaaa=????????????????
在这种情况下，字符串0xaa似乎是启用了HeapVerify的结果，这可能导致GC填充了收集的内存区域，大概是为了便于识别，并建议我们仍然可以参考收集/重定位对象的旧位置。
回溯到堆栈中，有许多0xaaaaaaaaaaaaaaaa条目，但是当最近的GC发生时，这些条目不再出现在调用堆栈顶部的方法中，在本例中为{{ 3}}，根据该线程上最新的GC的GC压力日志：
（注意：为了方便阅读，我从SOS的!dumplog输出中颠倒了记录行的顺序）：
2404 12445.672380360 : `GC`GCROOTS` Starting scan of Thread 000000001EF4DED0 ID = 20 {
2404 12445.672380963 : `GCROOTS` Scanning ExplicitFrame 000000001E6ED3B8 AssocMethod = 0000000000000000 frameVTable = 000007FEF365B640 (clr!RedirectedThreadFrame::`vftable')
2404 12445.672386397 : `GCROOTS` Scanning Frameless method 000007FE93F43460 (NHibernate.Loader.Loader.GetRow(System.Data.IDataReader, NHibernate.Persister.Entity.ILoadable[], NHibernate.Engine.EntityKey[], System.Object, NHibernate.Engine.EntityKey, NHibernate.LockMode[], System.Collections.IList, NHibernate.Engine.ISessionImplementor)) ControlPC = 000007FE945E3095
2404 12445.672388208 : `GC`GCROOTS` GC Root 000000001E6ED4C0 RELOCATED 000000003B1A7708 -> 000000003AC89F08 MT = 000007FE93DDF5C8 (...)
2404 12445.672388510 : `GC`GCROOTS` GC Root 000000001E6ED4D8 RELOCATED 000000003B1A73A0 -> 000000003AC89D00 MT = 000007FEF1FD6EA8 (System.Object[])
2404 12445.672388510 : `GC`GCROOTS` GC Root 000000001E6ED4E8 RELOCATED 000000003B1A7358 -> 000000003AC89CB8 MT = 000007FE9491D7C8 (NHibernate.Engine.EntityKey)
2404 12445.672388510 : `GC`GCROOTS` GC Root 000000001E6ED4F8 RELOCATED 000000003B1A73A0 -> 000000003AC89D00 MT = 000007FEF1FD6EA8 (System.Object[])
此方法的堆栈区域如下：
00000000`1e6ed470 000000003b1a7358 ✕
00000000`1e6ed478 000000000291e3d0
00000000`1e6ed480 0000000000000000
00000000`1e6ed488 0000000000000000
00000000`1e6ed490 000000000662a900
00000000`1e6ed498 0000000006523c80
00000000`1e6ed4a0 0000000000000000
00000000`1e6ed4a8 0000000000000000
00000000`1e6ed4b0 0000000000000000
00000000`1e6ed4b8 0000000000000000
00000000`1e6ed4c0 000000003ac89f08 ✔
00000000`1e6ed4c8 0000000000000000
00000000`1e6ed4d0 0000000006524248
00000000`1e6ed4d8 000000003ac89d00 ✔
00000000`1e6ed4e0 0000000000000000
00000000`1e6ed4e8 000000003ac89cb8 ✔
00000000`1e6ed4f0 0000000000000000
00000000`1e6ed4f8 000000003ac89d00 ✔
00000000`1e6ed500 0000000100000000
00000000`1e6ed508 0000000c0000000b
00000000`1e6ed510 0000000006621660
00000000`1e6ed518 000000001e6ed690
00000000`1e6ed520 000000001e6ed6a0
我已指出GC压力日志中提到的4个条目已重定位，这些条目已使用其新地址正确更新，但是第一个堆栈条目（000000003b1a7358-一个NHibernate.Engine.EntityKey）却已重新定位是已重定位的对象之一未未使用新地址进行更新。如果不再使用它，这当然是完全正常的，但是实际上它将作为参数传递给NHibernate.Loader.Loader.GetRow()到call。
InstanceNotYetLoaded()接受9个参数（加上this），我在下面的程序集清单上标记了每个参数装入堆栈/寄存器的位置。我还包括了SOS !gcinfo的相关输出，因为它与堆栈上的每个参数有关：
Param Address Instruction GC Info
000007fe`945e3071 mov r9,qword ptr [rbp-38h]
P4> 000007fe`945e3075 mov qword ptr [rsp+20h],r9
000007fe`945e307a mov r9d,dword ptr [rbp-18h] +sp+20
000007fe`945e307e mov rcx,qword ptr [rbp+40h]
000007fe`945e3082 cmp r9,qword ptr [rcx+8]
000007fe`945e3086 jb 000007fe`945e308d
000007fe`945e3088 call clr!JIT_RngChkFail
000007fe`945e308d lea rcx,[rcx+r9*8+10h] -sp+20
000007fe`945e3092 mov r9,qword ptr [rcx]
-- GC Occurred Here --
P5> 000007fe`945e3095 mov qword ptr [rsp+28h],r9
000007fe`945e309a mov r9,qword ptr [rbp+38h] +sp+28
P6> 000007fe`945e309e mov qword ptr [rsp+30h],r9
000007fe`945e30a3 mov r9,qword ptr [rbp+30h] +sp+30
P7> 000007fe`945e30a7 mov qword ptr [rsp+38h],r9
000007fe`945e30ac mov r9,qword ptr [rbp+48h] +sp+38
P8> 000007fe`945e30b0 mov qword ptr [rsp+40h],r9
000007fe`945e30b5 mov r9,qword ptr [rbp+50h] +sp+40
P9> 000007fe`945e30b9 mov qword ptr [rsp+48h],r9
000007fe`945e30be mov r9d,dword ptr [rbp-18h] +sp+48
000007fe`945e30c2 mov rcx,qword ptr [rbp+20h]
000007fe`945e30c6 cmp r9,qword ptr [rcx+8]
000007fe`945e30ca jb 000007fe`945e30d1
000007fe`945e30cc call clr!JIT_RngChkFail
000007fe`945e30d1 lea rcx,[rcx+r9*8+10h] -sp+48 -sp+40 -sp+38 -sp+30 -sp+28
P3> 000007fe`945e30d6 mov r9,qword ptr [rcx]
this> 000007fe`945e30d9 mov rcx,qword ptr [rbp+10h]
P1> 000007fe`945e30dd mov rdx,qword ptr [rbp+18h]
P2> 000007fe`945e30e1 mov r8d,dword ptr [rbp-18h]
000007fe`945e30e5 call InstanceNotYetLoaded(...)
崩溃之前的GC发生在000007fe945e3095，这是在将参数4加载到堆栈上之后（在000007fe945e3075），而且也是在该堆栈条目已失效之后（在{{ 1}}），这将解释GC迁移阶段为何不更新此引用的原因。
参数5-9的GC信息似乎还错误地将它们标记为过早失效，也许可以说，这两种情况在看起来像数组索引范围检查之后都立即将它们标记为失效。
对我来说，这看起来像是一个JIT错误，这些堆栈参数的生存期未正确跟踪。这种分析是否正确，如果可以，那么最好在哪里报告。如果不是JIT错误，那我想念的是什么可以解释纯托管代码上的这些意外崩溃？
我相信以下代码段将重现该问题，至少可以在 debug模式下生成错误的GC信息。
000007fe945e308d从本质上讲，必须有一个方法调用该方法：
满足这些条件时，第4个 参数将被加载到调用堆栈中，并且堆栈条目正确标记为包含引用。但是，在确定参数5的值时，将进行数组索引范围检查，并且在此之后将参数4的堆栈条目标记为无效。
如果GC检查发生在范围检查的之后，但发生在 before 之前，则发生了实际调用，并且GC导致通过重定位参数4传递的对象，方法恢复后，调用会将旧的（无效的）地址传递给参数4，而不是新的地址。
答案 0 :(得分：5)
虽然不能解决问题，但我将其视为是错误，因此应将其视为.NET团队进行修复。
在.NET Framework 4.7.1（clrjit.dll版本4.7.2xxx）上运行代码段时，会生成正确的GCInfo（实际上+sp+20仅在调用ReproHelper之前被写入） ：
00007ffb`99450630 55 push rbp
00007ffb`99450631 4883ec40 sub rsp,40h
00000003 is a safepoint:
00007ffb`99450635 488d6c2440 lea rbp,[rsp+40h]
00007ffb`9945063a 33c0 xor eax,eax
00007ffb`9945063c 488945f8 mov qword ptr [rbp-8],rax
00007ffb`99450640 48894d10 mov qword ptr [rbp+10h],rcx
00007ffb`99450644 895518 mov dword ptr [rbp+18h],edx
00007ffb`99450647 4c894520 mov qword ptr [rbp+20h],r8
00007ffb`9945064b 4c894d28 mov qword ptr [rbp+28h],r9
interruptible
+rbp+28 +rbp+20 +rbp+10 +rbp-8
00007ffb`9945064f 833d3a3fefff00 cmp dword ptr [00007ffb`99344590],0
00007ffb`99450656 7405 je 00007ffb`9945065d
00007ffb`99450658 e863eaab5f call clr!JIT_DbgIsJustMyCode (00007ffb`f8f0f0c0)
00007ffb`9945065d 90 nop
00007ffb`9945065e 8b5518 mov edx,dword ptr [rbp+18h]
00007ffb`99450661 4c8b4538 mov r8,qword ptr [rbp+38h]
+r8
00007ffb`99450665 413b5008 cmp edx,dword ptr [r8+8]
00007ffb`99450669 7205 jb 00007ffb`99450670
-rbp-8
00007ffb`9945066b e8f015ac5f call clr!JIT_RngChkFail (00007ffb`f8f11c60)
-r8
00007ffb`99450670 488b5538 mov rdx,qword ptr [rbp+38h]
+rdx
00007ffb`99450674 448b4518 mov r8d,dword ptr [rbp+18h]
00007ffb`99450678 4d63c0 movsxd r8,r8d
00007ffb`9945067b 4a8b54c210 mov rdx,qword ptr [rdx+r8*8+10h]
00007ffb`99450680 488955f8 mov qword ptr [rbp-8],rdx
+rbp-8
00007ffb`99450684 488b55f8 mov rdx,qword ptr [rbp-8]
00007ffb`99450688 4889542428 mov qword ptr [rsp+28h],rdx
+sp+28
00007ffb`9945068d 8b5518 mov edx,dword ptr [rbp+18h]
-rdx
00007ffb`99450690 4c8b4520 mov r8,qword ptr [rbp+20h]
+r8
00007ffb`99450694 4c8b4d28 mov r9,qword ptr [rbp+28h]
+r9
00007ffb`99450698 488b4d30 mov rcx,qword ptr [rbp+30h]
+rcx
00007ffb`9945069c 48894c2420 mov qword ptr [rsp+20h],rcx
+sp+20
00007ffb`994506a1 488b4d10 mov rcx,qword ptr [rbp+10h]
-rbp-8
但是在升级到.NET Framework 4.7.2（clrjit.dll版本4.7.3062）之后，它不再正确（+sp+20已被写入数组索引范围检查之前，已正确设置，但突然出现）之后仍未设置，但仍在ReproHelper调用中使用）：
00007ffe`62290630 55 push rbp
00007ffe`62290631 4883ec30 sub rsp,30h
00007ffe`62290635 488d6c2430 lea rbp,[rsp+30h]
00000007 is a safepoint:
00007ffe`6229063a 48894d10 mov qword ptr [rbp+10h],rcx
00007ffe`6229063e 895518 mov dword ptr [rbp+18h],edx
00007ffe`62290641 4c894520 mov qword ptr [rbp+20h],r8
00007ffe`62290645 4c894d28 mov qword ptr [rbp+28h],r9
interruptible
+rbp+28 +rbp+20 +rbp+10
00007ffe`62290649 833d483fefff00 cmp dword ptr [00007ffe`62184598],0
00007ffe`62290650 7405 je 00007ffe`62290657
00007ffe`62290652 e869f7aa5f call clr!TranslateSecurityAttributes+0x857b0 (00007ffe`c1d3fdc0) (JitHelp: CORINFO_HELP_DBG_IS_JUST_MY_CODE)
00007ffe`62290657 90 nop
00007ffe`62290658 488b4d30 mov rcx,qword ptr [rbp+30h]
+rcx
00007ffe`6229065c 48894c2420 mov qword ptr [rsp+20h],rcx
+sp+20
00007ffe`62290661 8b4d18 mov ecx,dword ptr [rbp+18h]
-rcx
00007ffe`62290664 488b5538 mov rdx,qword ptr [rbp+38h]
+rdx
00007ffe`62290668 483b4a08 cmp rcx,qword ptr [rdx+8]
00007ffe`6229066c 7205 jb 00007ffe`62290673
00007ffe`6229066e e8ed22ab5f call clr!TranslateSecurityAttributes+0x88350 (00007ffe`c1d42960) (JitHelp: CORINFO_HELP_RNGCHKFAIL)
-sp+20
00007ffe`62290673 488d54ca10 lea rdx,[rdx+rcx*8+10h]
-rdx +rdx(interior)
00007ffe`62290678 488b0a mov rcx,qword ptr [rdx]
+rcx
00007ffe`6229067b 48894c2428 mov qword ptr [rsp+28h],rcx
+sp+28
00007ffe`62290680 488b4d10 mov rcx,qword ptr [rbp+10h]
00007ffe`62290684 8b5518 mov edx,dword ptr [rbp+18h]
-rdx(interior)
00007ffe`62290687 4c8b4520 mov r8,qword ptr [rbp+20h]
+r8
00007ffe`6229068b 4c8b4d28 mov r9,qword ptr [rbp+28h]
+r9
00007ffe`6229068f e804faffff call 00007ffe`62290098 (GCInfoBug.Bug.ReproHelper(Int32, System.Object, System.Object, System.Object, System.Object), mdToken: 0000000006000004)
-sp+28 -r9 -r8 -rcx
00007ffe`62290694 90 nop
00007ffe`62290695 90 nop
not interruptible
-rbp+28 -rbp+20 -rbp+10
00007ffe`62290696 488d6500 lea rsp,[rbp]
00007ffe`6229069a 5d pop rbp
00007ffe`6229069b c3 ret
答案 1 :(得分：3)
感谢您提供此详细调查以及此错误报告。
Microsoft将在即将发布的服务版本4.7.2中修复此问题。