【问题标题】:spindump for Windows Kernel Debugging Devstudio用于 Windows 内核调试 Devstudio 的 spindump
【发布时间】:2018-07-18 14:19:14
【问题描述】:

因此,当遇到死锁、互斥、锁反转等问题时,在 OSX 上,spindump 工具非常有用。它只是转储所有系统(用户态和内核)上的线程堆栈,并且对于哪些线程被阻塞是相当可见的。

现在使用 Devstudio 在第二个 VM 上进行内核调试,我遇到了死锁。我看到我可以使用“!process 0 0”来转储所有进程。而且我相信我可以切换到一个进程,并转储线程(?),然后选择一个带有“!thread”和“k”的线程来查看堆栈。但是实际上有数千个线程,肯定有一种方法可以在不手动执行的情况下将它们全部转储吗?

"!process 0 7" 运行了大约 40 分钟,并且设置的堆栈中没有我的函数。

spindump 输出看起来像 Thread 0x8ab 1000 samples (1-1000) priority 81 (base 81) *1000 call_continuation + 23 (kernel.development + 1927415) *1000 arc_reclaim_thread + 2391 (arc.c:5095,11 in zfs + 131367) *1000 cv_timedwait_hires + 206 (spl-condvar.c:172,14 in spl + 8125) *1000 msleep + 98 (kernel.development + 7434066) *1000 _sleep + 219 (kernel.development + 7432603) *1000 lck_mtx_sleep_deadline + 147 (kernel.development + 2362339) *1000 thread_block_reason + 286 (kernel.development + 2407438)

所以没有什么神奇的,只是它遍历所有线程。

【问题讨论】:

  • "!process 0 0" 并找到系统进程地址,然后 "!process 0xdeadbeef 7" 似乎至少列出了内核中的线程以及堆栈中的函数。不过在我的虚拟机上需要将近 12 分钟。
  • 你想解决什么问题?在我看来,您似乎知道存在死锁,但您不知道它是在内核中还是在用户模式中,并且您不知道哪个应用程序受到影响。在我看来,您似乎想要一个通用的解决所有问题的死锁工具。如果您发现 Microsoft Office 与 Adob​​e Reader 陷入僵局,您会怎么做?那么下一步是什么?
  • 我知道有一个死锁,因为等待新 vnode 的线程永远等待,所以我需要查看堆栈以了解谁拥有该互斥锁,以便我可以找出它没有返回的原因。是的,这些堆栈中的大多数都在内核中,但有些可以是用户态(调用内核的命令行工具)。是的,自旋锁非常接近通用死锁工具,但就我而言,我正在研究文件系统驱动程序。

标签: windows visual-studio kernel windbg


【解决方案1】:

使用 !stacks 和 0,1,2

引自windbg chm文件

The !stacks extension gives a brief summary of the state of every thread. You   
can use this extension instead of the !process extension to get a quick overview    
of the system, especially when debugging multithread issues such as resource    
conflicts or deadlocks.

The !findstack user-mode extension also displays information about particular stacks.

Here is an example of the simplest !stacks display:

kd> !stacks 0
Proc.Thread  .Thread  ThreadState  Blocker
                                     [System]
   4.000050  827eea10  Blocked    +0xfe0343a5

                                     [smss.exe]

                                     [csrss.exe]
  b0.0000a8  82723b70  Blocked    ntoskrnl!_KiSystemService+0xc4
  b0.0000c8  82719620  Blocked    ntoskrnl!_KiSystemService+0xc4
  b0.0000d0  827d5d50  Blocked    ntoskrnl!_KiSystemService+0xc4
.....

编辑

!stacks 是一个耗时的操作 速度与所使用的交通工具有关
vm 到 vm 有自己的开销 在与具有网络调试的物理机器的物理连接上或 pre win 10 上的 1394 比具有 115200 波特率的 com 端口或管道更快

我不确定你的虚拟机是什么,但如果你在 vbox 上,那么你可以试试 vmkd

任何方式来回答您的评论

你可以运行它来记录和 grep 输出

.logopen z:\foo.txt ; !堆栈 0; .logclose

这将在您想要的路径中打开一个日志文件,并将所有输出重定向到日志文件,并在命令完成后关闭日志文件

还请记住 !stacks 接受通配符过滤器字符串,以便只有您知道可以过滤符号的堆栈

喜欢

kd> .logopen c:\stacks.txt ; !stacks 0  Etw; .logclose
Opened log file 'c:\stacks.txt'

Proc.Thread  .Thread  Ticks   ThreadState Blocker

Max cache size is       : 1048576 bytes (0x400 KB) 
Total memory in cache   : 0 bytes (0 KB) 
Number of regions cached: 0
0 full reads broken into 0 partial reads
    counts: 0 cached/0 uncached, 0.00% cached
    bytes : 0 cached/0 uncached, 0.00% cached
** Prototype PTEs are implicitly decoded
                            [82965600 Idle]
                            [840dcc40 System]
   4.000078  8410ed48 0000081 Blocked    nt!EtwpLogger+0xd0
   4.000080  8410e4d8 0000081 Blocked    nt!EtwpLogger+0xd0
   4.000084  84142020 0000081 Blocked    nt!EtwpLogger+0xd0
   4.000088  84142d48 0000081 Blocked    nt!EtwpLogger+0xd0
   4.000090  8416c630 000001d Blocked    nt!EtwpLogger+0xd0
   4.000094  8496ea88 0000bf3 Blocked    nt!EtwpLogger+0xd0
   4.0000a0  84079a88 000004a Blocked    nt!EtwpLogger+0xd0
   4.000194  85144d48 000445c Blocked    nt!EtwpLogger+0xd0
   4.000308  851b9d48 0004035 Blocked    nt!EtwpLogger+0xd0
   4.00032c  851d3d48 0002d48 Blocked    nt!EtwpLogger+0xd0
   4.00034c  852e8d48 0003e4a Blocked    nt!EtwpLogger+0xd0
   4.000350  84973d48 0003df4 Blocked    nt!EtwpLogger+0xd0
   4.000354  84f0dd48 0003de4 Blocked    nt!EtwpLogger+0xd0
   4.000444  854c7970 0002158 Blocked    nt!EtwpLogger+0xd0

                            [84f0b930 smss.exe]

                            [8409eb38 csrss.exe]

                            [84f34d40 wininit.exe]

                            [84f4d030 csrss.exe]

                            [850f8d40 winlogon.exe]

                            [8515bb38 services.exe]

                            [85161d40 lsass.exe]

                            [85163d40 lsm.exe]

【讨论】:

  • 啊,谢谢。奇怪的是,在我进行的所有冲浪中,我没有找到任何人提到 !stacks,也没有提到文档。猜猜这只是意味着我在谷歌搜索方面很差。 :) 接下来是将该输出保存到 txt 文件中,以便我可以对其进行 grep 或其他操作,因为“中间窗口”中的搜索功能是有史以来最糟糕的 :)
  • 虽然,即使只是“!stacks 0”也需要 12 分钟才能用我的小型 VM 转储。这就是你的专业 Windows 开发人员的工作方式,只是一大堆耐心吗? (两台虚拟机,使用 TCP over localhost 调试)。
  • .logopen z:\foo.bar;!stacks 0; .logclose
  • 哦,搜索字符串绝对有用。谢谢!
  • 一旦我有了我的堆栈列表,很快就可以找到它。原子移植错误,c11 采用 ptrs,但 win32 没有。这非常有用,谢谢大家。
猜你喜欢
  • 2011-10-03
  • 2012-09-23
  • 2011-12-26
  • 1970-01-01
  • 2013-02-13
  • 2013-01-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多