编译源码时卡死-还记得.NET 中的车辆零件收集系统的卡住分析吗

一:背景 1.讲故事

前段时间,有同事在陌陌上找到我,说他的程序偶尔会卡顿,让我帮忙看看怎么回事。 恰巧有一个同学也捡到了垃圾,他就让同学把垃圾扔给我。 ,接下来使用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来看,这是一个互斥锁。 目前这个锁是由进程1134中的1ec0线程持有的,我们都知道mutex是可以跨进程的,那么接下来的问题是,这个锁是不是被其他进程持有后没有释放呢? 是另一个过程吗? 可以使用~查看当前进程的进程号。

编译源码时卡死-还记得.NET 中的车辆零件收集系统的卡住分析吗

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的输出来看,互斥量是由本进程的线程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

从输出信息来看,这是一个文件类型的句柄。 既然同学说卡住了,那就说明线程9还在这个句柄上等待或者由于各种情况出不来,那为什么出不来呢?

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上查看,参考链接:

编译源码时卡死-还记得.NET 中的车辆零件收集系统的卡住分析吗

分析了这一点,逻辑大概就清楚了。

线程 1 等待线程 9 释放互斥锁。

线程9意外出错,无法退出,导致互斥锁没有被释放。

接下来就是让同学们重点关注9号线程的线程栈,为什么会有重复创建的逻辑,毕竟涉及到业务逻辑,我只能帮忙到这里了。

三:总结

这种类型的转储分析似乎是分析基本技能的良好实践。 文章涉及一些windbg命令的使用。 我相信你一定会有所收获。

收藏 (0) 打赏

感谢您的支持,我会继续努力的!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

悟空资源网 源码编译 编译源码时卡死-还记得.NET 中的车辆零件收集系统的卡住分析吗 https://www.wkzy.net/game/175582.html

常见问题

相关文章

官方客服团队

为您解决烦忧 - 24小时在线 专业服务