当前位置：文江博客话题详情

使用托管代码调用蓝屏死机

发布于 2024-07-08 19:59:32 字数 147 浏览 10 评论 0原文

只是好奇：是否可以在 Windows XP/Vista 下使用 .net 托管代码调用 Windows 蓝屏死机？如果可能的话，示例代码可能是什么？

只是为了记录，这并不是出于任何恶意目的，我只是想知道需要什么样的代码才能真正按照指定的方式杀死操作系统。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

无风消散 2024-07-15 19:59:32

键盘可能是一个不错的选择，但如果您需要通过代码来完成，请继续阅读...

您实际上不需要任何东西来呕吐，本身，您需要做的就是找到 KeBugCheck(Ex) 函数并调用它。

http://msdn.microsoft.com/en-us/library/ms801640.aspx
http://msdn.microsoft.com/en-us/library/ms801645.aspx

对于手动启动的崩溃，您需要使用 0xE2 (MANUALLY_INITIATED_CRASH) 或 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) 作为错误检查代码。它们被明确保留用于该用途。

然而，找到这个函数可能有点棘手。 Windows DDK 可能会有所帮助（检查 Ntddk.h） - 我目前没有可用的，而且我现在似乎找不到决定性的信息 - 我认为它在 ntoskrnl.exe 中或 ntkrnlpa.exe，但我不确定，并且目前没有工具来验证它。

您可能会发现编写一个简单的 C++ 应用程序或调用该函数的应用程序，然后运行它会更容易。

请注意，我假设 Windows 不会阻止您从用户空间访问该函数（.NET 可能有一些特殊规定）。我自己没有测试过。

回复收藏 0 原文

活泼老夫 2024-07-15 19:59:32

我不知道它是否真的有效，我确定您需要管理员权限，但您可以设置 CrashOnCtrlScroll 注册表项，然后使用 SendKeys 发送 CTRL+Scroll Lock+Scroll Lock。

但我相信这必须来自键盘驱动程序，所以我想一个简单的 SendKeys 还不够好，您要么需要以某种方式连接到键盘驱动程序（听起来真的很乱），要么检查 CrashDump 是否有一个 API 可以通过 P/Invoke 进行调用。

http://support.microsoft.com/kb/244139

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \i8042prt\参数
名称：CrashOnCtrlScroll
数据类型：REG_DWORD
值：1
重新开始

回复收藏 0 原文

英雄似剑 2024-07-15 19:59:32

我不得不说不。您必须 p/invoke 并与内核空间中的驱动程序或其他代码进行交互。尽管在未来版本的 Windows 中存在一些关于托管驱动程序的讨论，但 .NET 代码与该领域相距甚远。只要再等几年，你就会像我们不受管理的朋友一样崩溃。

回复收藏 0 原文

懒猫 2024-07-15 19:59:32

据我所知，真正的 BSOD 需要内核模式代码失败。 Vista 仍然存在 BSOD，但频率较低，因为新的驱动程序模型在内核模式下的驱动程序较少。任何用户模式故障都会导致您的应用程序被终止。

您无法在内核模式下运行托管代码。因此，如果您想出现 BSOD，则需要使用 PInvoke。但即便如此也是相当困难的。你需要做一些非常奇特的 PInvokes 才能在内核模式下得到一些东西。

但在成千上万的 SO 用户中，可能有人已经做到了这一点:-)

回复收藏 0 原文

剪不断理还乱 2024-07-15 19:59:32

您可以使用 OSR Online 的工具来触发内核崩溃。我自己从未尝试过，但我想您可以通过标准 .net Process 类运行它：

http://www.osronline.com/article.cfm?article=153

回复收藏 0 原文

单身狗的梦 2024-07-15 19:59:32

我曾经不负责任地使用 .NET 1.1 中的 System.Net.Sockets 在 Windows XP 上生成了 BSOD。我可以定期重复它，但不幸的是那是几年前的事了，我不记得我到底是如何触发它的，或者已经有源代码了。

回复收藏 0 原文

计㈡愣 2024-07-15 19:59:32

尝试在 directx8 或 directx9 中使用 directshow 进行实时视频输入，大多数调用都会转到内核模式视频驱动程序。当从实时视频捕获源运行回调过程时，我成功地遇到了很多蓝屏，特别是如果您的回调需要很长时间，可能会停止整个内核驱动程序。

回复收藏 0 原文

腹黑女流氓 2024-07-15 19:59:32

当托管代码访问有故障的内核驱动程序时，它可能会导致错误检查。但是，直接导致 BSOD 的可能是内核驱动程序（例如，uffe 的 DirectShow BSOD、Terence Lewis 的套接字 BSOD 或在某些网络适配器上使用 BitTorrent 时出现的 BSOD）。

直接用户模式访问特权低级资源可能会导致错误检查（例如，在 Device\PhysicalMemory 上乱写乱画，如果它不会首先损坏您的硬盘；Vista 不允许用户-模式访问物理内存）。

如果您只想要一个转储文件，Mendelt 建议使用 WinDbg 比利用内核驱动程序中的错误要好得多。不幸的是，本地内核调试不支持 .dump 命令，因此您需要第二台通过串行或 1394 连接的 PC，或者通过虚拟串行端口连接的 VM。 LiveKd 可能是单 PC 选项（如果您不这样做）需要内存转储的状态完全一致。

回复收藏 0 原文

·深蓝 2024-07-15 19:59:32

这个不需要任何内核模式驱动程序，只需要 SeDebugPrivilege。您可以通过 NtSetInformationProcess，或RtlSetProcessIsCritical 然后终止你的进程。您将看到与杀死 csrss.exe 相同的错误检查代码，因为您在进程上设置了相同的“关键”标志。

回复收藏 0 原文

情仇皆在手 2024-07-15 19:59:32

不幸的是，我知道如何执行此操作，因为我们服务器上的 .NET 服务导致蓝屏。（注意：Windows Server 2008 R2，而不是 XP/Vista）。

我简直不敢相信 .NET 程序是罪魁祸首，但事实确实如此。此外，我刚刚在虚拟机中复制了 BSOD。

违规代码会导致 0x00000f4：

string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace

foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
    Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
    process.Kill();
    r = true;
}

如果有人想知道为什么我要复制蓝屏，那么这并不是恶意的。我修改了我们的日志类以接受一个参数，告诉它直接写入磁盘因为尽管调用了 .Flush() ，但 BSOD 之前的操作并未出现在日志中。我复制了服务器崩溃来测试日志记录更改。虚拟机崩溃了，但日志记录正常。

编辑：杀死 csrss.exe 似乎是导致蓝屏的原因。根据评论，这可能发生在内核代码中。

Unfortunately, I know how to do this as a .NET service on our server was causing a blue screen. (Note: Windows Server 2008 R2, not XP/Vista).

I could hardly believe a .NET program was the culprit, but it was. Furthermore, I've just replicated the BSOD in a virtual machine.

The offending code, causes a 0x00000f4:

string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace

foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
    Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
    process.Kill();
    r = true;
}

If anyone's wondering why I'd want to replicate the blue screen, it's nothing malicious. I've modified our logging class to take an argument telling it to write direct to disk as the actions prior to the BSOD weren't appearing in the log despite .Flush() being called. I replicated the server crash to test the logging change. The VM duly crashed but the logging worked.

EDIT: Killing csrss.exe appears to be what causes the blue screen. As per comments, this is likely happening in kernel code.

回复收藏 0 原文