记一次 .NET 某工控PCB巡检系统 崩溃分析

一：背景

1. 讲故事

前些天训练营里的一位学员找到我，说他们的系统出现了崩溃，自己分析了遍也没找到是什么原因，让我帮忙看下怎么回事？dump拿到手后，接下来就上windbg分析。

二：崩溃分析

1. 为什么会崩溃

打开dump之后，windbg 会自动定位崩溃点，输出如下：

................................................................
................................................................
.........................................
Loading unloaded module list
...........................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1cec.1984): Access violation - code c0000005 (first/second chance not available)

+------------------------------------------------------------------------+
| This target supports Hardware-enforced Stack Protection. A HW based    |
| "Shadow Stack" may be available to assist in debugging and analysis.   |
| See aka.ms/userhsp for more info.                                      |
|                                                                        |
| dps @ssp                                                               |
|                                                                        |
+------------------------------------------------------------------------+

For analysis of this file, run !analyze -v
clr!WKS::gc_heap::find_first_object+0xea:
00007ff9`9faea3eb 833800          cmp     dword ptr [rax],0 ds:00000461`0000085a=????????

从卦中的 find_first_object 函数来看，这是GC在寻找需要标记的对象时出现了空地址，即经典的 托管堆损坏 问题。。。为了验证可以使用 !verifyheap 命令,输出如下：

0:016> !verifyheap 
Could not request method table data for object 00000296DB67CFC0 (MethodTable: 0000046100000858).
Last good object: 00000296DB67CEF0.

2. 为什么托管堆损坏了

从时间轴的角度来看，托管堆损坏 属于第二现场，第一现场是恶意的破坏现场，由于时间不能倒流，所以从dump中我们无法看到曾经发生过的事，那怎么办呢？有一个办法就是直接看 破坏现场，哈哈，这个是不是有点像法医学。。。 使用 dp 00000296DB67CFC0-0x80 L20 观察对象附近的破坏场所，输出如下：

0:016> dp 00000296DB67CFC0-0x80 L20
00000296`db67cf40  41816d40`414f1533 43202a65`41000000
00000296`db67cf50  414f1533`43202a65 41016d40`41016d40
00000296`db67cf60  40cf1533`40cf1533 414f1533`40cf1533
00000296`db67cf70  411fd70a`3f000000 43202a65`411fd70a
00000296`db67cf80  41016d40`43202a65 40800000`411b4fe6
00000296`db67cf90  41a00005`4247fffc 3f000000`41a00005
00000296`db67cfa0  4221c88f`41200000 00000000`411b4fe6
00000296`db67cfb0  000000be`00000000 00000523`000003ee
00000296`db67cfc0  00000461`0000085b 00000004`000007a6
00000296`db67cfd0  000003ee`000000be 0000085b`00000523
00000296`db67cfe0  000007a6`00000461 000000be`00000004
00000296`db67cff0  00000523`000003ee 00000461`0000085b
00000296`db67d000  00000004`000007a6 00000000`00000000
00000296`db67d010  00000000`00000000 00000000`00000000
00000296`db67d020  00000000`00000000 00000000`00000000
00000296`db67d030  00000000`00000000 00000000`00000000

再回头看下错误信息，说 00000296DB67CFC0 处应该是方法表，结果变成了现在的很多数字，看起来像是 C++ 写入的数组，为了防止误判，我让朋友又继续抓崩溃dump，看看dump是不是具有随机性，防止南辕北辙，朋友也顺利的抓到了第二个dump。

For analysis of this file, run !analyze -v
clr!WKS::gc_heap::find_first_object+0x83:
00007ff9`a077a388 833900          cmp     dword ptr [rcx],0 ds:000001cc`00000666=????????

0:094> !verifyheap 
Could not request method table data for object 000001C64B541738 (MethodTable: 000001CC00000664).
Last good object: 000001C64B53F758.

0:094> dp 000001C64B541738-0x80 L20
000001c6`4b5416b8  00000000`00000000 00000000`00000000
000001c6`4b5416c8  00000000`00000000 00000000`00000000
000001c6`4b5416d8  00000000`00000000 00000000`00000000
000001c6`4b5416e8  00000000`00000000 00000000`00000000
000001c6`4b5416f8  00000000`00000000 00000000`00000000
000001c6`4b541708  00000000`00000000 00000000`00000000
000001c6`4b541718  00000000`00001fe0 00000000`00000000
000001c6`4b541728  000000be`00000000 00000261`00000556
000001c6`4b541738  000001cc`00000666 00000004`000005c7
000001c6`4b541748  00000556`000000be 00000666`00000261
000001c6`4b541758  000005c7`000001cc 000000be`00000004
000001c6`4b541768  00000261`00000556 000001cc`00000666
000001c6`4b541778  00000004`000005c7 00000000`00000000
000001c6`4b541788  00000000`00000000 00000000`00000000
000001c6`4b541798  00000000`00000000 00000000`00000000
000001c6`4b5417a8  00000000`00000000 00000000`00000000

从卦中看，第二个dump也是出现了类似 C++ 数组的内容，到这里基本就能断定有人有意或者无意的往托管堆写入数组内容，导致托管堆对象破坏，让朋友关注下代码中的 fixed,pinvoke 之类，截图如下：

3. 后续花絮

几天之后，朋友给我带来了一个好消息，说它通过 assert 断言一步一步的试，最终还真给找到了。。。大概就是 C++ 写托管堆的时候越界了，参考代码如下：

int cadx = measure_info[i].posx;	
int cady = measure_info[i].posy;	
int samplex = cadx - nSamplePosInCADx;	
int sampley = cady - nSamplePosInCADy;	
if (samplex < 0 || samplex >= nWidthSample || sampley < 0 || sampley >= nHeightSample)	
{	
    continue;
}	
int offpos = sampley / grid_ver * 5 + samplex / grid_her;   //错误的 int offpos = cady / grid_ver * 5 + cadx / grid_her	
assert(offpos >= 0 && offpos < 25);	
int cad_offx = pnSubOffset[offpos * 2 + 0], cad_offy = pnSubOffset[offpos * 2 + 1];	

找到当然是开心的，也确实这种问题比较难搞，不过不知道朋友为什么没有使用我推荐的 ttd 方式，毕竟它的程序有一个重要的特征，即启动后1分钟之内必崩，完全可以尝试ttd，参考如下：

0:094> vertarget
Windows 10 Version 19044 MP (32 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Debug session time: Wed Mar 12 15:12:41.000 2025 (UTC + 8:00)
System Uptime: 32 days 4:35:52.688
Process Uptime: 0 days 0:00:41.000
  Kernel time: 0 days 0:01:21.000
  User time: 0 days 0:08:01.000

三：总结

这次事故是 C++ 操控 C# 托管对象时，C++这边数组越界导致的托管堆损坏引发崩溃，这种仅凭第二现场就能寻找蛛丝马迹的案例，真的少之又少。。。也算是不幸中的万幸吧，当然也在于朋友的不抛弃不放弃，终见曙光，调试难！