記一次 .NET某汽車零件採集系統卡死分析

一線碼農發表於2023-03-14

一：背景

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         	\Sessions\9\BaseNamedObjects\USB3101ALOCK-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-