如何收集有关可能涉及驱动程序和用户模式代码的 Windows 7 冻结的信息？
我遇到了应用程序崩溃，即 Windows 7 崩溃，但不是传统的“蓝屏死亡”崩溃，当设备驱动程序或其他内核空间进程崩溃整个系统时会发生这种情况，而是，我看到所有用户空间进程的锁定。
这是机器的状态：
（1）Windows鼠标移动仍在响应，Aero合成层仍在工作（资源管理器中的某些鼠标悬停效果仍然有效），但没有win32进程在工作，并且GDI和用户会话似乎冻结了。 (2) Ctrl+Alt+Delete 不调出任务管理器。 (3) 没有故障转储，也没有蓝屏死机。
有人知道有什么方法可以收集有关事故的更多信息吗？我知道涉及驱动程序级别问题，并且我想收集人们可以使用的设备驱动程序级别的信息。当您遇到蓝屏死机时，您可以收集内存转储 (DMP) 文件，并将它们发送给开发人员以寻求帮助。我正在寻找一种跟踪进程和系统状态的方法，也许连接一个 内核调试器 之类的。我从未做过内核调试器工作，所以我正在寻找一种开始使用它的方法。
我可以轻松地在 win7/32 位 VM 中重现崩溃，而且我还没有安装内核调试工具。我首先想知道，我是否选择了一种有价值的方法（内核调试工具？），如果是这样，我真的不知道如何使用这些工具来收集可能帮助内核模式开发人员找到问题的信息。
I am experiencing a crash in an application, that is crashing windows 7, but not in the traditional "blue screen of death" crash, that happens when device drivers or other kernel-space processes crash the whole system, but rather, I am seeing a lock-up of all user-space processes.
Here is the state of the machine:
(1) Windows mouse movement is still responding, and Aero composition layer is still working (certain mouse over effects in explorer still work), but no win32 process is working, and the GDI and user session seem frozen.
(2) Ctrl+Alt+Delete does not bring up the task manager.
(3) There are no crash dumps, and there is no blue screen of death.
Does anybody know any way to gather any more information about the crash? I know that there are driver level issues involved, and I would like to gather information that the device driver level people could use. When you get a Blue Screen Of Death, you can gather the memory dump (DMP) files, and send them to the developers to help. What I am looking for is a way to trace the processes, and the state of the system, perhaps connect a kernel debugger or something. I have never done kernel debugger work, so I'm looking for a way to get started with that.
I can easily reproduce the crash in a win7/32 bit VM, and I do not yet have the kernel debug tools installed. I'm wondering first, if it seems that I have chosen a worthwhile approach (kernel debug tools?) and if so, I don't really know how to use those tools to gather information that might help the kernel mode devs locate the trouble.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
下载 WinDbg 并通过 Firewire 或串行电缆连接到有问题的机器（USB 在某些情况下也可以工作 IIRC）。这将允许您从远程计算机搜索正在运行的系统中的死锁。
另一种可能性是引发系统崩溃（事后分析）。您应该先确保将故障转储设置设置为完全转储。这将创建与您的 RAM 大小相同的故障转储。当然，当将转储提供给人们时（例如通过网络），这可能会带来问题。另请注意，根据具体情况，转储中可能包含私有数据。
如何引发故障转储是我所描述的这里，相关部分引用如下。如果您通过内核调试器连接，您还可以引发内存转储的创建。
键盘驱动程序可以被告知导致 BSOD：
或（对于较旧的 PS/2 键盘）
并将名为
CrashOnCtrlScroll的REG_DWORD设置为1< /代码>。下次重新启动后，您可以通过
Ctrl+ScrollLk+ScrollLk强制蓝屏。在这种情况下，错误检查代码将为0xE2(MANUALLY_INITIATED_CRASH)。Download WinDbg and connect to the machine in question by Firewire or serial cable (USB also works under some circumstances IIRC). This would allow you to search for deadlocks in the running system from a remote machine.
Another possibility is to provoke a system crash (post-mortem analysis). You should make sure before to set the crash dump settings to full dump. This will create a crash dump of the same size as your amount of RAM. Of course that may pose a problem when getting the dump to the people (e.g. via the net). Also be aware that private data can be contained in the dump, depending on the circumstances.
How to provoke the crash dump is what I described here, relevant part quoted below. If you are connected via the kernel debugger you can also provoke the creation of a memory dump.
The keyboard driver(s) can be told to cause a BSOD:
or (for older PS/2 keyboards)
And there set a
REG_DWORDnamedCrashOnCtrlScrollto1.After the next reboot you can force the blue screen by
Ctrl+ScrollLk+ScrollLk. The bug check code will in this case be0xE2(MANUALLY_INITIATED_CRASH).