记一次 .NET某汽车零件采集系统 卡死分析

  • 记一次 .NET某汽车零件采集系统 卡死分析已关闭评论
  • 267 次浏览
  • A+
所属分类：.NET技术
摘要

前段时间有位朋友在微信上找到我，说他的程序会出现一些偶发卡死的情况，让我帮忙看下是怎么回事，刚好朋友也抓到了dump，就让朋友把 dump 丢给我，接下来用 windbg 探究下到底咋回事。
便宜好用的国外VPS推荐

一：背景

1. 讲故事

前段时间有位朋友在微信上找到我，说他的程序会出现一些偶发卡死的情况，让我帮忙看下是怎么回事，刚好朋友也抓到了dump，就让朋友把 dump 丢给我，接下来用 windbg 探究下到底咋回事。

二：WinDbg 分析

1. 程序真的卡死吗

因为是一个 winform 程序，验证起来很简单，观察 主线程此时在做什么即可。

 0:000:x86> kb CvRegToMachine(x86) conversion failure for 0x14f X86MachineInfo::SetVal: unknown register 0 requested  # ChildEBP RetAddr      Args to Child               00 018fe0a8 77413ff9     00000918 00000000 00000000 ntdll_77530000!NtWaitForSingleObject+0xc 01 018fe0a8 77413f52     00000918 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x99 02 018fe0bc 1000fe9c     00000918 ffffffff 1000fec0 KERNELBASE!WaitForSingleObject+0x12 WARNING: Stack unwind information not available. Following frames may be wrong. 03 018fe338 03d7808a     00000000 00000000 00000000 USB3101A!USB3101A_AUX_getch+0xdc 04 018fe358 03d7803a     00000000 00000000 00000000 0x3d7808a 05 018fe378 6ff87596     046e1928 03f02970 03f02db0 0x3d7803a ...

从主线程的线程栈看，托管代码调用了非托管的 USB3101A!USB3101A_AUX_getch 方法，然后在 NtWaitForSingleObject 方法上等待，熟悉 NtWaitForSingleObject 方法的朋友都知道，它的第一个参数是 句柄 类型，签名如下：

 NTSTATUS NtWaitForSingleObject(   [in] HANDLE         Handle,   [in] BOOLEAN        Alertable,   [in] PLARGE_INTEGER Timeout );

有了这个信息，我们可以用 windbg 提取 ntdll_77530000!NtWaitForSingleObject 方法的第一个参数 00000918 。

 0:000:x86> !handle 00000918 f Handle 00000918   Type         	Mutant   Attributes   	0   GrantedAccess	0x1f0001:          Delete,ReadControl,WriteDac,WriteOwner,Synch          QueryState   HandleCount  	2   PointerCount 	59730   Name         	Sessions9BaseNamedObjectsUSB3101ALOCK-0   Object specific information     Mutex is Owned     Mutant Owner 1334.1ec0

从输出信息的 Mutant Owner 1334.1ec0 来看，这是一个 mutex 锁，当前这个锁被 1134 号进程中的 1ec0 线程持有，我们都知道 mutex 是可以跨进程的，接下来疑问就来了，难道这个锁被 其他的进程 持有后不释放吗？ 那到底是不是其他进程呢？ 可以用 ~ 看下当前进程的进程号。

0:000:x86> ~ .  0  Id: 1334.1e74 Suspend: 0 Teb: 016ee000 Unfrozen    1  Id: 1334.1354 Suspend: 0 Teb: 016fa000 Unfrozen    2  Id: 1334.2c30 Suspend: 0 Teb: 016fd000 Unfrozen    3  Id: 1334.db4 Suspend: 0 Teb: 01706000 Unfrozen    4  Id: 1334.2ac4 Suspend: 0 Teb: 0170f000 Unfrozen    5  Id: 1334.d54 Suspend: 0 Teb: 01718000 Unfrozen    6  Id: 1334.4fc Suspend: 0 Teb: 0171b000 Unfrozen    7  Id: 1334.241c Suspend: 0 Teb: 01727000 Unfrozen    8  Id: 1334.2464 Suspend: 0 Teb: 01733000 Unfrozen    9  Id: 1334.1ec0 Suspend: 0 Teb: 0175d000 Unfrozen   10  Id: 1334.3bc4 Suspend: 0 Teb: 01790000 Unfrozen   11  Id: 1334.2844 Suspend: 0 Teb: 01799000 Unfrozen   12  Id: 1334.2a88 Suspend: 0 Teb: 0179c000 Unfrozen   13  Id: 1334.2190 Suspend: 0 Teb: 0179f000 Unfrozen

从输出看 1334.1ec0 来看，mutex 是被本进程的 9号 线程持有，是本进程就好办了。

2. 为什么 9 号线程不释放

带着好奇心立刻切到 9 号线程上观察它的托管和非托管栈。

 0:009:x86> !clrstack OS Thread Id: 0x1ec0 (9) Child SP       IP Call Site 0395ec00 0000002b [InlinedCallFrame: 0395ec00]  0395ebfc 0dbfc91d DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Int16[], UInt32, UInt32 ByRef, UInt32 ByRef, Double) 0395ec00 0dbfc3e0 [InlinedCallFrame: 0395ec00] xxxx.USB3101A_AI_ReadBinary(IntPtr, Int16[], UInt32, UInt32 ByRef, UInt32 ByRef, Double)  0:009:x86> kb CvRegToMachine(x86) conversion failure for 0x14f X86MachineInfo::SetVal: unknown register 0 requested  # ChildEBP RetAddr      Args to Child               00 0395e4c0 77447a94     00000910 00000000 00000000 ntdll_77530000!NtWaitForSingleObject+0xc 01 0395e4c0 7665fc4b     00000910 0022004b 0395e524 KERNELBASE!DeviceIoControl+0x35404 02 0395e4ec 1000c5bb     00000910 0022004b 0395e524 kernel32!DeviceIoControlImplementation+0x4b WARNING: Stack unwind information not available. Following frames may be wrong. 03 00000910 1000f7ea     000107e7 00100001 00220009 USB3101A!USB3101A_SetPassword+0x24b 04 0403a7b4 7292cc68     0438b5d4 00000000 0000000c USB3101A!USB3101A_E2P_UpdateToFirmware+0x10a 05 00000000 775a2b1c     77413ff9 00000918 00000000 clr!StringObject::NewString+0x4c 06 00000000 77413ff9     00000918 00000000 77414016 ntdll_77530000!NtWaitForSingleObject+0xc 07 00000000 10022e61     0395e7a0 00000000 e9c915c7 KERNELBASE!WaitForSingleObjectEx+0x99

从输出信息看， DeviceIoControl 是一个非常底层的 Win32API 接口，看了下文档说是给指定的驱动设备下达指令，??了，那它在等待什么呢？ 用同样的方式提取 00000910 参数。

 0:009:x86> !handle 00000910 f Handle 00000910   Type         	File   Attributes   	0   GrantedAccess	0x12019f:          ReadControl,Synch          Read/List,Write/Add,Append/SubDir/CreatePipe,ReadEA,WriteEA,ReadAttr,WriteAttr   HandleCount  	2   PointerCount 	59992   No object specific information available

从输出信息看，这是一个 file 类型的句柄，既然朋友说卡死，那就说明 9 号线程在这个 handle 上一直等待或者由于各种情况出不来，那为什么出不来呢？

3. 为什么不能全身而退

既然 9 号线程不能很好的退出非托管操作，内部可能发生了什么错误，要想提取当前线程在 win32 层面是否发生错误，可以用 windbg 的 !gle 命令，

 0:009:x86> !gle LastErrorValue: (Win32) 0xb7 (183) - <Unable to get error code text> LastStatusValue: (NTSTATUS) 0 - STATUS_SUCCESS Wow64 TEB status: 24506368 LastErrorValue: (NTSTATUS) 0 (0) - STATUS_SUCCESS LastStatusValue: (NTSTATUS) 0 - STATUS_SUCCESS

从输出信息看，当前报了一个 0xb7 的错误，不过可惜的是现在 !error 不能很好的展示错误信息，只能到 msdn 上去查，参考链接：https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

记一次 .NET某汽车零件采集系统 卡死分析

分析到这里，逻辑大概就捋清楚了。

  1. 1 号线程等待 9 号线程释放 mutex 锁。
  2. 9 号线程意外出现了错误得不到退出，导致 mutex 锁不能释放。

接下来就是让朋友重点看下 9 号线程的线程栈，为什么会出现 重复创建 的逻辑，毕竟涉及到了业务逻辑，我也只能帮到这里了。

三：总结

这种类型的dump分析起来还是挺锻炼分析基本功的，文章中涉及到了一些 windbg 命令的使用技巧，相信大家会有收获的。

记一次 .NET某汽车零件采集系统 卡死分析

便宜好用的国外VPS推荐