频繁出现 BSOD“THREAD_STUCK_IN_DEVICE_DRIVER”

Question

首先，我想告诉大家，这是对我之前发的一篇帖子的重写，这篇帖子由于细节不完整而被关闭。现在我把其他人要求我做的内容都加到了原文中。（原文：https://superuser.com/questions/990227/sudden-bsod-at-random-times？）

我用 Google Chrome 浏览互联网，然后进入了一所学校的网站。突然，出现了一个 BSOD，上面显示如下信息：

线程卡在设备驱动程序中

我使用 Malwarebytes Anti-Malware 进行了完整的恶意软件扫描，发现了 2 个潜在有害程序 (PUP)：

我下载了 BlueScreenView，并查看了最新的蓝屏死机转储，我发现了以下内容：

它说这是由驱动程序引起的虚拟硬盘根目录。

如果有人需要我的电脑信息，我使用 Piriform Speccy 收集了这些信息：

• 操作系统：Windows 10 家庭单语言版 64 位
• CPU：英特尔酷睿 i3 3217U @ 1.80GHz
  Ivy Bridge 22nm 技术
• 内存：4.00GB 单通道 DDR3 @ 798MHz（11-11-11-28）
• 主板：华硕电脑公司 X450CP（SOCKET 0）
• 显卡：通用即插即用显示器 (1366x768@60Hz)
  Intel HD Graphics 4000 (华硕电脑公司)
  1024MB ATI AMD Radeon R5 M240 (华硕电脑公司)
• 存储：465GB 日立 HGST HTS545050A7E680 (SATA)
• 光驱：TSSTcorp CDDVDW SU-228FB
• 音频： Realtek 高清晰度音频

这不是唯一一次出现相同消息的 BSOD。这种情况经常发生在我的电脑不在视线范围内、我连接到互联网、浏览互联网和使用某些程序时。

我去年 8 月从 Windows 8.1 更新到了 Windows 10。这可能是 Windows 10 自动更新导致的问题吗？

如果有人知道解决方案，我将不胜感激。如果你们需要更多详细信息，请告诉我缺少什么，我会添加它。

更新： 这是 minidump 文件夹中的 dmps 链接：https://www.dropbox.com/s/8y3g2lpeq57bp0n/Minidump%20copy.zip?dl=0

Answer 1

BlueScreenView 一如既往地显示错误原因。当在 Windbg 中分析 dmp运行结果!analyze -v表明崩溃是由 AMD GPU 驱动程序 atikmdag.sys 引起的：

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: ffffe0015134d800, Pointer to a stuck thread object.  Do .thread then kb on it to find
    the hung location.

 # Child-SP          RetAddr           Call Site
00 ffffd001`67194078 fffff801`d7e2e18c nt!KeBugCheckEx
01 ffffd001`67194080 fffff801`d7e2e24e dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x24
02 ffffd001`671940f0 fffff801`da002463 dxgkrnl!TdrTimedOperationDelay+0xbe
03 ffffd001`67194130 ffffe001`553cf000 atikmdag+0x42463
04 ffffd001`67194138 00000000`00000000 0xffffe001`553cf000

    Image path: \SystemRoot\system32\DRIVERS\atikmdag.sys
    Image name: atikmdag.sys
    Timestamp:        Sat Aug 22 04:10:03 2015 

安装最新的 AMD Beta 驱动程序看看是否能解决问题。