WinDbg定位死锁问题

于 2023-08-23 15:06:54 发布
阅读量647 收藏 2
点赞数 1
分类专栏： windbg 文章标签： windows
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_48073095/article/details/132451879
版权

文章目录

方法1

1、首先确认下是哪个进程出现死锁的情况，如界面卡死、点击没有反应等，抓取对应进程的dump
2、查看是否存在

0:000> kv
ChildEBP RetAddr  Args to Child             
0019f3b8 77736b0c 77722253 00000108 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0019f3bc 77722253 00000108 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
0019f420 77722137 00000000 00000000 00000001 ntdll!RtlpWaitOnCriticalSection+0x13e (FPO: [Non-Fpo])
0019f448 777504a0 777c8340 774893be 00000000 ntdll!RtlEnterCriticalSection+0x150 (FPO: [Non-Fpo])
0019f480 759e7b43 00000001 00000000 0019f4a8 ntdll!LdrLockLoaderLock+0xe4 (FPO: [Non-Fpo])
0019f4cc 6e723027 6e6f0000 0019f4e4 00000104 KERNELBASE!GetModuleFileNameW+0x75 (FPO: [Non-Fpo])
...

3、从上面看线程在等待一个临界区，使用!cs进行分析

0:000> !cs 777c8340
-----------------------------------------
Critical section   = 0x777c8340 (ntdll!LdrpLoaderLock+0x0)
DebugInfo          = 0x777c8540
LOCKED
LockCount          = 0x15
WaiterWoken        = No
OwningThread       = 0x00001a40
RecursionCount     = 0x1
LockSemaphore      = 0x108
SpinCount          = 0x00000000

4、可以看出0号线程等待的是ntdll!LdrpLoaderLock 锁，再看下这个锁被哪个线程占用了

0:000> ~~[0x00001a40]
  30  Id: 1c14.1a40 Suspend: 1 Teb: 7ff8d000 Unfrozen
      Start: CloudEngine!CreateCloudEngineLocker+0x2561 (702db4f0)
      Priority: -2  Priority class: 32  Affinity: f

5、从上面看该锁被30号线程占用，然后再来分析30号线程的状态

0:000> ~30 kv
ChildEBP RetAddr  Args to Child             
0c8ed9f8 77736b0c 77722253 00000bf4 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0c8ed9fc 77722253 00000bf4 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
0c8eda60 77722137 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0x13e (FPO: [Non-Fpo])
0c8eda88 753b2fa0 753c4060 00000000 0bcf70bc ntdll!RtlEnterCriticalSection+0x150 (FPO: [Non-Fpo])
0c8edab0 753b2de2 0b8a5b84 00000000 0bcf70b8 bcrypt!LoadProvider+0x32 (FPO: [Non-Fpo])
0c8edb04 6dc79472 0c8edb24 6dc794a0 00000000 bcrypt!BCryptOpenAlgorithmProvider+0x12c (FPO: [Non-Fpo])
0c8edb28 7764c167 6dcc055c 0c8edb50 6dc1ce76 msxml3!AutoInitSalt::AutoInitSalt+0x1f (FPO: [Non-Fpo])
0c8edb34 6dc1ce76 6dc1cea4 6dc1cf10 00000001 msvcrt!_initterm+0x13 (FPO: [Non-Fpo])
0c8edb50 6dbf1594 6dbf0000 00000000 00000000 msxml3!_CRT_INIT+0xc3 (FPO: [Non-Fpo])
0c8edbb0 6dc19709 6dbf0000 00000001 00000000 msxml3!_CRT_INIT+0x22a (FPO: [Non-Fpo])
0c8edbcc 77748cc8 6dbf0000 00000001 00000000 msxml3!InitDllMain+0x8e (FPO: [Non-Fpo])
...

6、从上面看，30号线程也在等待一个临界区，该临界区被41号线程占用

0:030> !cs 753c4060
-----------------------------------------
Critical section   = 0x753c4060 (bcrypt!g_csLoaderLock+0x0)
DebugInfo          = 0x0b8c1b20
LOCKED
LockCount          = 0x2
WaiterWoken        = No
OwningThread       = 0x00000398
RecursionCount     = 0x1
LockSemaphore      = 0xBF4
SpinCount          = 0x00000000
 
 
0:030> ~~[0x00000398]
  41  Id: 1c14.398 Suspend: 1 Teb: 7ff82000 Unfrozen
      Start: cloudsec3!C360EngTaskMgr::_threadProc (6dfafb90)
      Priority: 0  Priority class: 32  Affinity: f

7、看下41号线程

0:030> ~41 kv
ChildEBP RetAddr  Args to Child             
0df3bfac 77736b0c 77722253 00000108 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0df3bfb0 77722253 00000108 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
0df3c014 77722137 00000000 00000000 0df3c07c ntdll!RtlpWaitOnCriticalSection+0x13e (FPO: [Non-Fpo])
0df3c03c 7774fd17 777c8340 7aa2a7e6 753b2738 ntdll!RtlEnterCriticalSection+0x150 (FPO: [Non-Fpo])
0df3c0d8 77752563 74f50000 0df3c114 00000000 ntdll!LdrGetProcedureAddressEx+0x159 (FPO: [Non-Fpo])
0df3c0f4 759e6d18 74f50000 0df3c114 00000000 ntdll!LdrGetProcedureAddress+0x18 (FPO: [Non-Fpo])
0df3c11c 753b26c5 74f50000 753b2738 092e1dac KERNELBASE!GetProcAddress+0x44 (FPO: [Non-Fpo])
0df3c130 753b2fce 74f50000 092e1dac 00000000 bcrypt!_LoadInterface+0x77 (FPO: [Non-Fpo])
0df3c164 753b2de2 092e1dac 00000000 0bcf7018 bcrypt!LoadProvider+0x76 (FPO: [Non-Fpo])
0df3c1b8 75b1ada1 0df3c214 758cc800 00000000 bcrypt!BCryptOpenAlgorithmProvider+0x12c (FPO: [Non-Fpo])
0df3c234 75b184e4 0b8093c0 00000006 75b180fc wintrust!SIPObjectPE_::DigestFile+0x6a (FPO: [Non-Fpo])
0df3c264 75b1b471 75b161c8 0df3c3b4 08cdb278 wintrust!SIPObject_::CreateIndirectData+0x11a (FPO: [Non-Fpo])
0df3c2a4 75b18158 0df3c338 0df3c3b4 08cdb278 wintrust!SIPObjectPE_::CreateIndirectData+0x5d (FPO: [Non-Fpo])
0df3c2c4 758db43a 0df3c338 0df3c3b4 08cdb278 wintrust!InboxCryptSIPCreateIndirectData+0x4e (FPO: [Non-Fpo])
0df3c318 75b32f33 0df3c338 0df3c3b4 08cdb278 crypt32!CryptSIPCreateIndirectData+0x63 (FPO: [Non-Fpo])
0df3c3cc 75b18719 75b18728 00000770 0df3c61c wintrust!_CatAdminCalcHashFromFileHandle+0x14f (FPO: [Non-Fpo])
0df3c3e8 73d5087a 00000770 0df3c61c 0df3c408 wintrust!CryptCATAdminCalcHashFromFileHandle+0x1c (FPO: [Non-Fpo])
...

8、看出41号线程也在等待一个临界区

0:041> !cs 777c8340
-----------------------------------------
Critical section   = 0x777c8340 (ntdll!LdrpLoaderLock+0x0)
DebugInfo          = 0x777c8540
LOCKED
LockCount          = 0x15
WaiterWoken        = No
OwningThread       = 0x00001a40
RecursionCount     = 0x1
LockSemaphore      = 0x108
SpinCount          = 0x00000000
 
0:041> ~~[0x00001a40]
  30  Id: 1c14.1a40 Suspend: 1 Teb: 7ff8d000 Unfrozen
      Start: CloudEngine!CreateCloudEngineLocker+0x2561 (702db4f0)
      Priority: -2  Priority class: 32  Affinity: f

41号线程的要访问的临界区被30号线程占用，30号线程访问的临界区被41号线程占用，主线程要访问的临界区也被30号线程占用。
死锁发生在调用系统API时，猜测是系统的bug

方法2

1、首先确认下是哪个进程出现死锁的情况，如界面卡死、点击没有反应等，抓取对应进程的dump
2、执行!locks命令查看所有的线程占用的锁

CritSec xxx!AtqActiveContextList+a8 at 68629100
LockCount          2	——有多少个线程在等待这个临界区
RecursionCount     1
OwningThread       5b0
EntryCount         2
ContentionCount    2
*** Locked

这个线程等待的锁是68629100，被5b0线程占用
3、运行~列出所有线程的信息

   0  Id: 1054.f54 Suspend: 1 Teb: 7efdb000 Unfrozen
   1  Id: 1054.20c Suspend: 1 Teb: 7efd8000 Unfrozen
   2  Id: 1054.1048 Suspend: 1 Teb: 7efd5000 Unfrozen
   3  Id: 1054.104c Suspend: 1 Teb: 7ef9d000 Unfrozen
   4  Id: 1054.a58 Suspend: 1 Teb: 7ef9a000 Unfrozen
   5  Id: 1054.a60 Suspend: 1 Teb: 7ef97000 Unfrozen
   6  Id: 1054.ea4 Suspend: 1 Teb: 7ef94000 Unfrozen
   7  Id: 1054.3b4 Suspend: 1 Teb: 7ef91000 Unfrozen
   8  Id: 1054.494 Suspend: 1 Teb: 7ef8e000 Unfrozen
   9  Id: 1054.5b0 Suspend: 1 Teb: 7ef8b000 Unfrozen
  10  Id: 1054.1010 Suspend: 1 Teb: 7ef82000 Unfrozen
  11  Id: 1054.13f0 Suspend: 1 Teb: 7ef7f000 Unfrozen
  12  Id: 1054.13e8 Suspend: 1 Teb: 7ef7c000 Unfrozen
  13  Id: 1054.13cc Suspend: 1 Teb: 7ef79000 Unfrozen
  14  Id: 1054.13b8 Suspend: 1 Teb: 7ef76000 Unfrozen
  15  Id: 1054.a80 Suspend: 1 Teb: 7ef88000 Unfrozen
  16  Id: 1054.fcc Suspend: 1 Teb: 7ef85000 Unfrozen
  17  Id: 1054.e10 Suspend: 1 Teb: 7ef73000 Unfrozen
  18  Id: 1054.edc Suspend: 1 Teb: 7ef70000 Unfrozen
  19  Id: 1054.cbc Suspend: 1 Teb: 7ef6d000 Unfrozen
  20  Id: 1054.c2c Suspend: 1 Teb: 7ef6a000 Unfrozen
  21  Id: 1054.cc4 Suspend: 1 Teb: 7ef67000 Unfrozen
  22  Id: 1054.544 Suspend: 1 Teb: 7ef64000 Unfrozen
  23  Id: 1054.794 Suspend: 1 Teb: 7ef61000 Unfrozen
  24  Id: 1054.950 Suspend: 1 Teb: 7ef5e000 Unfrozen

Id: 前的数字是thread id，Id: 后的数字1054是process id，这里可知5b0对应的thread id是9
4、查看9的堆栈信息

9  id: 1054.5b0   Suspend: 0 Teb 7ef8b000 Unfrozen

ChildEBP RetAddr  Args to Child
014cfe64 77f6cc7b 00000460 00000000 00000000 ntdll!NtWaitForSingleObject+0xb
014cfed8 77f67456 0024e750 6833adb8 0024e750 ntdll!RtlpWaitForCriticalSection+0xaa
014cfee0 6833adb8 0024e750 80000000 01f21cb8 ntdll!RtlEnterCriticalSection+0x46
014cfef4 6833ad8f 01f21cb8 000a41f0 014cff20 xxx!DereferenceUserDataAndKill+0x24
014cff04 6833324a 01f21cb8 00000000 00000079 xxx!ProcessUserAsyncIoCompletion+0x2a
014cff20 68627260 01f21e0c 00000000 00000079 xxx!ProcessAtqCompletion+0x32
014cff40 686249a5 000a41f0 00000001 686290e8 xxx!I_TimeOutContext+0x87
014cff5c 68621ea7 00000000 00000001 0000001e xxx!AtqProcessTimeoutOfRequests_33+0x4f
014cff70 68621e66 68629148 000ad1b8 686230c0 xxx!I_AtqTimeOutWorker+0x30
014cff7c 686230c0 00000000 00000001 000c000a xxx!I_AtqTimeoutCompletion+0x38
014cffb8 77f04f2c 00000000 00000001 000c000a xxx!SchedulerThread_297+0x2f
00000001 000003e6 00000000 00000001 000c000a kernel32!BaseThreadStart+0x51

这里也可以通过windbg的View——Process and Threads的对应关系查找到对应的线程id

5、重复方法1的操作进行检查即可

方法3

1、确认出现死锁的进程
2、打开windows的任务管理器
3、选择性能项——打开左下角的资源监视器
资源监视器
4、找到死锁的进程，右键选择“分析等待链”，如果发生死锁的话，可以从这里获取到死锁的线程id信息，再综合dump去分析
分析等待链

过好每一天的女胖子
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
windbg使用教程（调试异常及死锁等）
baidu_38621657的博客
12-09 1万+
1.背景 最近由于线上的程序发生了死锁，而且重现的概率很低，正好客户反馈一个任务超时了，登上线上环境发现有一个“僵尸”进程，占用内存不波动，cpu仍在占用， 那么用创建转储文件，用windbg调试吧。 2.准备 2.1.下载windbg 需要下载Windows 调试工具 (WinDbg)：Windows 10 SDK，安装时候根据需要，可以只安装Debugging Tools For Windows，即windbg； 如果已下载并安装Windows 10 SDK，而没有安装Windbg，那么在控
使用WinDBG分析死锁问题
fengheyu425786182的博客
12-27 1193
使用WinDBG分析死锁问题
记一次 .NET 某数控机床控制程序 卡死分析
一线码农的专栏
09-06 545
这个案例告诉我们：只要代码还能跑，就不要动它，它要是不动了，你得要做好动的准备。
使用Windbg找出死锁，解决生产环境中运行的软件不响应请求的问题
weixin_30732825的博客
11-03 440
前言 本文介绍本人的一次使用Windbg分析dump文件找出死锁的过程，并重点介绍如何确定线程所等待的锁及判断是否出现了死锁。 对于如何安装及设置Windbg请参考：《使用Windbg和SoS扩展调试分析.NET程序》http://www.cnblogs.com/shanyou/archive/2006/12/23/601004.html 起因 今天，部署到生产环境中的软件再次...
【windbg】使用windbg 检查c++程序死锁
qq_43331089的博客
06-09 346
上一篇文章是使用lockcop软件检测死锁的。参考见：使用现在使用windbg。可运行的程序和代码还是一样的。
windbg定位死锁问题
momo459548255的博客
09-10 777
操作系统对死锁的描述如下： 所谓死锁:是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。 那么为什么会产生死锁呢？ 1.因为系统资源不足。 2.进程运行推进的顺序不合适。 3.资源分配不当。 而产生死锁的条件有四个： 1.互斥条件：所谓互斥就是进程在某一时间内独占资源。 2.请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 3.不剥夺条件:进程已获得资源，在末使用完之前，不...
windbg_advanced.rar_windbg
09-19
通过深入学习和实践，你可以利用Windbg的高级功能解决复杂的调试问题，无论是调试内核崩溃，还是优化应用程序性能，Windbg都是不可或缺的工具。记得经常查阅官方文档和社区资源，不断更新和提升你的Windbg技能。
WinDbg_cmds.rar_windbg
09-14
runaway`检查长时间运行的线程，找出可能的死锁或资源占用问题。 6. **学习资源** - MSDN上的WinDbg文档：官方最权威的参考资料，详细解释每个命令。 - Windbg社区：全球开发者交流平台，分享调试经验和技巧。 -...
Windows调试工具Windbg_x86
06-14
- **使用WinDbg进行性能分析**：配合ETW事件跟踪，可以进行性能瓶颈的定位。 5. **学习资源**： - 微软官方文档：提供详细的API和命令参考。 - 社区论坛：如Microsoft TechNet上的Windbg论坛，是交流和学习的好...
windbg x86
10-27
- **软件调试**：在开发过程中，可以利用Windbg定位程序崩溃、死锁等问题。 - **驱动开发**：对内核模式驱动进行调试，修复系统蓝屏（BSOD）问题。 - **性能优化**：通过分析CPU和内存使用情况，找出性能瓶颈。 ...
C++(Qt)软件调试-线程死锁调试（15）
最新发布
10-25
通过熟练运用各种调试工具，结合对线程同步机制的深入理解，开发者可以有效地定位并解决这类问题，保证程序的正常运行。无论是在Linux还是Windows系统下，GDB和Windbg都是强大的武器，能够帮助开发者在遇到死锁时...
使用windbg 检查c++程序死锁
baidu_16370559的博客
11-21 1216
上一篇文章是使用lockcop软件检测死锁的。参考见：使用lockcop软件检测c++死锁_baidu_16370559的博客-CSDN博客 现在使用windbg。 可运行的程序和代码还是一样的。 1.配置symbols 因为我使用的windbg 版本是6.12 。提示Unable to resolve ntdll!RtlCriticalSectionList 因为在新版本的windbg中可能部分指令不支持。 如果有如下提示 NTSDEXTS: Unable to resolve ntdll!Rt
记一次 .NET 某物管后台服务 卡死分析
dotNET跨平台
06-28 476
一：背景 1. 讲故事这几个月经常被朋友问，为什么不更新这个系列了，哈哈，确实停了好久，主要还是打基础去了，分析 dump 的能力不在于会灵活使用 windbg，而是对底层知识有一个深厚的理解，比如：汇编，C， C++，Win32 Api，虚拟内存，Windows 用户态和内核态，这是我今年看的书给大家分享一下。前段时候微信上有位朋友说他的程序出现了卡死，所有线程都不工作...
使用Windbg分析程序死锁小结
tpriwwq的专栏
12-02 4436
死锁场景描述：          针对之前一个版本反馈回来的问题，对数据通讯模块升级，做了精简和重构         因为ABA问题的存在，将之前以Socket为key改为以只增的Int为key。使用的锁为临界区锁。         修改完成，联调后进行压力测试，发现当后台的线程池满的时候会必然发生死锁。 死锁定位过程     第一步：精简线程模型，将授权检测线程、超时检测等辅助线程通通
应用死锁的分析
mergerly的专栏
02-08 7577
一款软件嘟嘟启动时无法启动，卡死在某个地方，界面显示不出来，于是分析了一番。 启动利器Windbg，Attach到目标进程dudu_d.exe。 首先显示一下所有堆栈 0:007> ~*kb 0 Id: d2c.1abc Suspend: 1 Teb: 7efdd000 Unfrozen ChildEBP RetAddr Args to Child 0
windbg分析死锁问题
小菜鸟
05-28 1378
代码如下： #include #include #include using namespace std; CRITICAL_SECTION cs_DB1; CRITICAL_SECTION cs_DB2; DWORD WINAPI ThreadProc(LPVOID lpParam) { EnterCriticalSection(&cs_DB1); cout<<"Updat
windbg定位线程死锁和句柄泄露
lv_yjie2011的专栏
12-03 1874
有异常处理程序定义处理引发的异常时，将调用该 UnhandledExceptionFilter 函数。 通常，该函数会将异常传递给在 Ntdll.dll 为文... 没有异常处理程序定义处理引发的异常时，将调用该 UnhandledExceptionFilter 函数。 通常，该函数会将异常传递给在 Ntdll.dll 为文件其中捕获，并尝试处理设置。  在进程的内存快照所在某些情况下，可以看
windbg 死锁问题分析
勇气凛凛
05-31 640
针对临界区的死锁分析，比较简单   !cs xxxxx ,然后通过owningthread 来找到对应的线程，并查看调用栈。   原因大致有以下几种： 1、owningthread  忘了释放锁，  建议使用 autolock 2、线程中使用了嵌套锁 3、owningthread 被动的原因无法释放锁，比如 1）、使用开源库，异常时直接ExitThread。 2）、使用了 __try...
windows程序使用Windbg分析dump
steem
04-23 5117
windows上Windbg分析dump文件
使用windbg 排查死锁问题
09-14
可以使用 Windbg 来排查死锁问题。 首先，在 Windbg 中使用 `.loadby sos mscorwks` 命令加载 SOS (Son of Strike) 插件。这个插件是用于在调试 .NET 程序时帮助调试器识别堆内存布局和执行信息的。 然后，使用 `!locks` 命令查看当前存在的锁定。这将会列出所有当前被锁定的对象，以及锁定它们的线程。 如果有多个线程都被阻塞等待获取锁，这就可能是死锁的情况。可以使用 `~*k` 命令查看所有线程的堆栈跟踪信息，以找出哪些线程正在等待获取锁。 还可以使用 `!dumpstack` 命令查看特定线程的堆栈跟踪信息，以帮助确定发生死锁的原因。 希望这些信息能帮到你。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值