记一次 .NET 某发证机系统 崩溃分析
一：背景1. 讲故事
前些天有位朋友在微信上找到我，说他的系统有偶发崩溃，自己也没找到原因，让我帮忙看下怎么回事，我分析dump一直都是免费的，毕竟对这些东西挺感兴趣，有问题可以直接call我，好了，接下来我们就来分析dump吧。
二：程序为什么会崩
1. 观察崩溃上下文
windbg有一个厉害之处在于双击dump之后会自动定位到崩溃的线程，然后通过 .ecxr; k10 命令就可以看到崩溃点了，输出如下：
0:083> .ecxr; k10
rax=000000004bdefa50 rbx=00000c45ea960c80 rcx=000000ffffffffff
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=00000000773da365 rsp=0000000046d0fb50 rbp=000000004bde28d0
r8=000000004bde28c0r9=0000000000000001 r10=0000000000000000
r11=0000000000000206 r12=00000000006b0000 r13=000000004bde2950
r14=0000000000000000 r15=0000000000000001
iopl=0 nv up ei pl nz na pe nc
cs=0033ss=002bds=002bes=002bfs=0053gs=002b efl=00010202
ntdll!RtlFreeHeap+0x1a5:
00000000`773da365 488b7b08 mov rdi,qword ptr ds:00000c45`ea960c88=????????????????
# Child-SP RetAddr Call Site
00 00000000`46d0fb50 000007fe`feda10c8 ntdll!RtlFreeHeap+0x1a5
01 00000000`46d0fbd0 000007fe`ee66f126 msvcrt!free+0x1c
02 00000000`46d0fc00 000007fe`ee6556ae ksproxy!CStandardInterfaceHandler::KsCompleteIo+0x4e6
03 00000000`46d0fce0 000007fe`ee66bf5c ksproxy!CKsOutputPin::OutputPinBufferHandler+0x1e
04 00000000`46d0fd10 00000000`771a556d ksproxy!CAsyncItemHandler::AsyncItemProc+0x20c
05 00000000`46d0fd70 00000000`7740372d kernel32!BaseThreadInitThunk+0xd
06 00000000`46d0fda0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d从卦中可以看到，程序崩溃在 RtlFreeHeap 函数中，熟悉这玩意的朋友应该知道它是用来释放 堆块 的，签名如下：
NTSYSAPI LOGICAL RtlFreeHeap(
PVOID HeapHandle,
ULONG Flags,
_Frees_ptr_opt_ PVOID BaseAddress
);接下来就是寻找该堆块的首地址 BaseAddress，即 r8 寄存器值，使用 uf ntdll!RtlFreeHeap 即可，输出如下：
0:083> uf ntdll!RtlFreeHeap
ntdll!RtlFreeHeap:
00000000`773da1c0 4053 push rbx
00000000`773da1c2 55 push rbp
00000000`773da1c3 56 push rsi
00000000`773da1c4 57 push rdi
00000000`773da1c5 4154 push r12
00000000`773da1c7 4883ec50 sub rsp,50h
00000000`773da1cb 33f6 xor esi,esi
00000000`773da1cd 498be8 mov rbp,r8
00000000`773da1d0 8bfa mov edi,edx
00000000`773da1d2 4c8be1 mov r12,rcx
00000000`773da1d5 488bde mov rbx,rsi
00000000`773da1d8 4d85c0 test r8,r8
...
ntdll!RtlFreeHeap+0x179:
00000000`773da339 498b4008 mov rax,qword ptr
00000000`773da33d 498bd8 mov rbx,r8
00000000`773da340 48b9ffffffffff000000 mov rcx,0FFFFFFFFFFh
00000000`773da34a 4933dc xor rbx,r12
00000000`773da34d 4823c1 and rax,rcx
00000000`773da350 48c1eb04 shr rbx,4
00000000`773da354 4833d8 xor rbx,rax
00000000`773da357 48331d3a321000xor rbx,qword ptr
00000000`773da35e 48c1e304 shl rbx,4
00000000`773da362 0f0d0b prefetchw
00000000`773da365 488b7b08 mov rdi,qword ptr 根据卦中的汇编代码 mov rbp,r8 ，看样子是 rbp 保存了 BaseAddress 地址，接下来使用 !heap -x 000000004bde28d0 看看到底啥情况，输出如下：
0:083> !heap -x 000000004bde28d0
SEGMENT HEAP ERROR: failed to initialize the extention
List corrupted: (Blink->Flink = 0000000000000000) != (Block = 000000004bde28c0)
HEAP 00000000006b0000 (Seg 000000004bde0000) At 000000004bde28b0 Error: block list entry corrupted
List corrupted: (Flink->Blink = 900000004bdefa50) != (Block = 000000004bdefa50)
HEAP 00000000006b0000 (Seg 000000004bde0000) At 000000004bdefa40 Error: block list entry corrupted
Entry User Heap Segment SizePrevSizeUnused Flags
-------------------------------------------------------------------------------------------------------------
000000004bde28b0000000004bde28c000000000006b0000000000004bde0000 3740 800 0free 从卦中可以看到，当前的 000000004bde28c0 是一个 free 堆块，同时也抛了一个 堆块列表 的损坏错误，这就有点意思了。。。
2. doublefree 导致的吗
熟悉 win32 的朋友应该知道，在已经 free 的块上再次调用 RtlFreeHeap 释放会是一个经典的 doublefree，貌似这个问题已经定位了。。。但如果你修车经验丰富的话，你应该知道 堆管理器 检测到 doublefree 的时候会是这样的调用栈记一次 .NET 某医疗住院系统 崩溃分析
， 参考如下：
0:090> !heap -s
Details:
Heap address:000001c14fd20000
Error address: 000001ce25531c50
Error type: HEAP_FAILURE_BLOCK_NOT_BUSY
Details: The caller performed an operation (such as a free
or a size check) that is illegal on a free block.
Follow-up:Check the error's stack trace to find the culprit.
Stack trace:
Stack trace at 0x00007ffed7b82848
00007ffed7abe109: ntdll!RtlpLogHeapFailure+0x45
00007ffed7acbb0e: ntdll!RtlFreeHeap+0x9d3ce
00007ffeb093276f: OraOps12!ssmem_free+0xf
00007ffeb0943077: OraOps12!OpsMetFreeValCtx+0xd7
00007ffeb093cdd8: OraOps12!OpsDacDispose+0x2b8
00007ffe655e4374: +0x655e4374
...而我们这个dump是访问违例，虽然这个dump必崩无疑，但这段逻辑此时还没执行到，也就是在这块逻辑之前就崩掉了，那为什么会崩掉呢？到底经历了何样的惊魂时刻。。。
3. 突破口在哪里
要想寻找突破口，就得理解下面的这两句了，再次输出一下吧。
List corrupted: (Blink->Flink = 0000000000000000) != (Block = 000000004bde28c0)
HEAP 00000000006b0000 (Seg 000000004bde0000) At 000000004bde28b0 Error: block list entry corrupted
List corrupted: (Flink->Blink = 900000004bdefa50) != (Block = 000000004bdefa50)
HEAP 00000000006b0000 (Seg 000000004bde0000) At 000000004bdefa40 Error: block list entry corrupted要理解这个，需要你对 _HEAP 结构有一个深度的理解，这个在我的 .NET高级调试训练营 里有一个系统的解读。
大家要知道 堆管理器 对 Free 的管理采用的是 双向链表 的方式，其中 Flink 表示下一个(Forward)节点，BLink 表示前一个(Backward)结点，有朋友搞不清的话，我画个简图。
有了简图之后，接下来逐个解读下：
[*](Blink->Flink = 0000000000000000) != (Block = 000000004bde28c0)
这是经典的 一去一回 ，结果发现不再是自己了。。。即 0000000000000000 != 000000004bde28c0，我们用 ntdll!_LIST_ENTRY 来具象化一下，截图如下：
从卦中可以看到 Blink = 0x900000004bdefa50 时就报错了，由于报错windbg 就将结果显示为 0000000000000000，所以这一来一回居然不等于自己，所以堆管理器就觉得很奇葩。。。
[*](Flink->Blink = 900000004bdefa50) != (Block = 000000004bdefa50)
这是经典的 一回一去，结果发现 Blink 不对。。。本来应该是 0x000000004bdefa50 结果是 0x900000004bdefa50 截图如下：
到这里我相信很多人会有一个疑问，我也没看到 0x000000004bdefa50 地址呀，凭什么说0x900000004bdefa50 的前身是 0x000000004bdefa50 ？
要想找到这个答案，又是考你的 堆管理器 知识，所有的 free 都挂在 FreeLists 字段里，同样也是采用 双向链表 的方式，输出如下：
0:083> dt nt!_HEAP 00000000006b0000 -yFreeLists
ntdll!_HEAP
+0x158 FreeLists : _LIST_ENTRY [ 0x00000000`1f1d7f90 - 0x00000000`1f23dbf0 ]接下来写一段简单的脚本把这个list给遍历下，看看 0x000000004bde28c0 的BLink结点是不是 0x000000004bdefa50 即可，脚本如下：
$$ $$>a< D:\debugging\18.20250506\src\Example\scripts\while2.txt
r @$t0 = 0x00000000006b0000 ;
r @$t1 = poi(@$t0+0x158) ; $$ Flink
r @$t2 = poi(@$t0+0x158+8); $$ Blink
.if (@$t1 == @$t2)
{
.echo "@$t0+0x158 list is empty"
}
.else
{
.echo "Walking @$t0+0x128 list..."
r @$t3 = @$t0+0x158
r @$t4 = @$t1
.while (@$t4 != @$t3)
{
.printf "Entry at %p\n", @$t4
r @$t4 = poi(@$t4)
}
.echo "End of list reached"
}
哈哈，睁大眼睛看下卦哦，真的是 000000004bdefa50，而不是 0x900000004bdefa50，到这里基本就搞清楚了，由于地址的变化 000000004bdefa50 -> 0x900000004bdefa50 导致 双向链表 断裂，当 RtlFreeHeap 在解码这个错误的内存地址时，导致程序的崩溃，同样你了解底层的话，你会发现用户态怎么可能会有 0x900000004bdefa50 这样的内存地址呢？？？
4. 为什么地址变化了
这个问题真的问到我了，因为我也不知道为什么地址 突变了, 原因是我在 000000004bde28c0 周围也没发现有越界写入的情况，为啥高31和28位就硬生生的由0变1了，输出如下：
0:083> dp 000000004bde28b0
00000000`4bde28b000000000`00000000 0001a08c`44153f2e
00000000`4bde28c000000000`4bdf79e0 90000000`4bdefa50
00000000`4bde28d000000000`00000080 00000000`00000000
0:083> .formats 90000000`4bdefa50
Binary:10010000 00000000 00000000 00000000 01001011 11011110 11111010 01010000最后就是这种问题该如何解决呢？只能开启 页堆，可以用 Application Verifier 工具，截图如下：
能不能找到就看个人造化了，如何真的找不到，就当是神奇的 bit位翻转 吧，建议换机器尝试，或上 ECC 纠错的内存条。。。
三：总结
这次生产事故非常考察你对 Windows 堆管理器 的深度理解，这块在我的训练营里有系统而深入的讲解，dump分析就是这样的有趣，各种迷惑和幻境，全靠扎实的底层功力和丰富的经验来冲出迷雾！
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]