kernelbase.dll(kernelbase.dll崩溃的处理)速看

USB3101A_AUX_getch 方法，然后在 NtWaitForSingleObject 方法上等待，熟悉 NtWaitForSingle

 

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

二：WinDbg 分析1. 程序真的卡死吗因为是一个 winform 程序，验证起来很简单，观察 主线程此时在做什么即可0:000:x86>kbCvRegToMachine(x86)conversion。

failurefor0x14fX86MachineInfo::SetVal:unknownregister0requested# ChildEBP RetAddr Args to Child

00018fe0a877413ff9000009180000000000000000ntdll_77530000!NtWaitForSingleObject+0xc01018fe0a877413f5200000918

ffffffff00000000KERNELBASE!WaitForSingleObjectEx+0x9902018fe0bc1000fe9c00000918ffffffff1000fec0KERNELBASE!WaitForSingleObject+0x12

WARNING:Stackunwindinformationnotavailable.Followingframesmaybewrong.03018fe33803d7808a0000000000000000

00000000USB3101A!USB3101A_AUX_getch+0xdc04018fe35803d7803a0000000000000000000000000x3d7808a05018fe378

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

NTSTATUSNtWaitForSingleObject( [in]HANDLEHandle, [in]BOOLEANAlertable, [in]PLARGE_INTEGERTimeout

); 有了这个信息，我们可以用 windbg 提取 ntdll_77530000!NtWaitForSingleObject 方法的第一个参数 00000918 0:000:x86> !handle 00000918 f。

Handle00000918TypeMutantAttributes0GrantedAccess0x1f0001:Delete,ReadControl,WriteDac,WriteOwner,Synch

QueryStateHandleCount2PointerCount59730Name\Sessions\9\BaseNamedObjects\USB3101ALOCK-0Objectspecific information

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

0:000:x86> ~ . 0Id: 1334.1e74 Suspend: 0Teb: 016ee000 Unfrozen 1Id: 1334.1354Suspend: 0Teb: 016fa000 Unfrozen

2Id: 1334.2c30 Suspend: 0Teb: 016fd000 Unfrozen 3Id: 1334.db4 Suspend: 0Teb: 01706000 Unfrozen

4Id: 1334.2ac4 Suspend: 0Teb: 0170f000 Unfrozen 5Id: 1334.d54 Suspend: 0Teb: 01718000 Unfrozen

6Id: 1334.4fc Suspend: 0Teb: 0171b000 Unfrozen 7Id: 1334.241c Suspend: 0Teb: 01727000 Unfrozen

8Id: 1334.2464Suspend: 0Teb: 01733000 Unfrozen 9Id: 1334.1ec0 Suspend: 0Teb: 0175d000 Unfrozen 10

Id: 1334.3bc4 Suspend: 0Teb: 01790000 Unfrozen 11Id: 1334.2844Suspend: 0Teb: 01799000 Unfrozen 12

Id: 1334.2a88 Suspend: 0Teb: 0179c000 Unfrozen 13Id: 1334.2190Suspend: 0Teb: 0179f000 Unfrozen 从输出看 1334.1ec0 来看，mutex 是被本进程的 9号 线程持有，是本进程就好办了。

2. 为什么 9 号线程不释放带着好奇心立刻切到 9 号线程上观察它的托管和非托管栈0:009:x86>!clrstackOS Thread Id:0x1ec0(9)ChildSPIPCallSite0395ec00

0000002b[InlinedCallFrame:0395ec00]0395ebfc0dbfc91dDomainBoundILStubClass.IL_STUB_PInvoke(IntPtr,Int16[],

UInt32,UInt32ByRef,UInt32ByRef,Double)0395ec000dbfc3e0[InlinedCallFrame:0395ec00]xxxx.USB3101A_AI_ReadBinary(IntPtr,

Int16[],UInt32,UInt32ByRef,UInt32ByRef,Double)0:009:x86>kbCvRegToMachine(x86)conversionfailurefor0x14f

X86MachineInfo::SetVal:unknownregister0requested# ChildEBP RetAddr Args to Child 00

0395e4c077447a94000009100000000000000000ntdll_77530000!NtWaitForSingleObject+0xc010395e4c07665fc4b00000910

0022004b0395e524KERNELBASE!DeviceIoControl+0x35404020395e4ec1000c5bb000009100022004b0395e524kernel32!DeviceIoControlImplementation+0x4b

WARNING:Stackunwindinformationnotavailable.Followingframesmaybewrong.03000009101000f7ea000107e700100001

00220009USB3101A!USB3101A_SetPassword+0x24b040403a7b47292cc680438b5d4000000000000000cUSB3101A!USB3101A_E2P_UpdateToFirmware+0x10a

0500000000775a2b1c77413ff90000091800000000clr!StringObject::NewString+0x4c060000000077413ff90000091800000000

77414016ntdll_77530000!NtWaitForSingleObject+0xc070000000010022e610395e7a000000000e9c915c7KERNELBASE!WaitForSingleObjectEx+0x99

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

!handle00000910fHandle00000910TypeFileAttributes0GrantedAccess0x12019f:ReadControl,SynchRead/List,Write/Add,Append/SubDir/CreatePipe,ReadEA,WriteEA,ReadAttr,WriteAttr

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

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

!gleLastErrorValue:(Win32)0xb7(183)-LastStatusValue:(NTSTATUS)0-STATUS_SUCCESS

Wow64 TEB status:24506368LastErrorValue:(NTSTATUS)0(0)-STATUS_SUCCESSLastStatusValue:(NTSTATUS)0-STATUS_SUCCESS

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

分析到这里，逻辑大概就捋清楚了1 号线程等待 9 号线程释放 mutex 锁9 号线程意外出现了错误得不到退出，导致 mutex 锁不能释放接下来就是让朋友重点看下 9 号线程的线程栈，为什么会出现 重复创建

的逻辑，毕竟涉及到了业务逻辑，我也只能帮到这里了。三：总结这种类型的dump分析起来还是挺锻炼分析基本功的，文章中涉及到了一些 windbg 命令的使用技巧，相信大家会有收获的。