Just curious here: is it possible to invoke a Windows Blue Screen of Death using .net managed code under Windows XP/Vista? And if it is possible, what could the example code be?
在这里好奇:是否可以在Windows XP / Vista下使用.net托管代码调用Windows蓝屏死机?如果有可能,示例代码是什么?
Just for the record, this is not for any malicious purpose, I am just wondering what kind of code it would take to actually kill the operating system as specified.
仅仅为了记录,这不是出于任何恶意目的,我只是想知道实际杀死指定的操作系统需要什么样的代码。
10 个解决方案
#1
15
The keyboard thing is probably a good option, but if you need to do it by code, continue reading...
键盘的东西可能是个不错的选择,但是如果你需要通过代码来做,继续阅读...
You don't really need anything to barf, per se, all you need to do is find the KeBugCheck(Ex) function and invoke that.
你真的不需要barf,本身你需要做的就是找到KeBugCheck(Ex)函数并调用它。
http://msdn.microsoft.com/en-us/library/ms801640.aspx http://msdn.microsoft.com/en-us/library/ms801645.aspx
For manually initiated crashes, you want to used 0xE2 (MANUALLY_INITIATED_CRASH) or 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) as the bug check code. They are reserved explicitly for that use.
对于手动启动的崩溃,您希望使用0xE2(MANUALLY_INITIATED_CRASH)或0xDEADDEAD(MANUALLY_INITIATED_CRASH1)作为错误检查代码。它们被明确保留用于该用途。
However, finding the function may prove to be a bit tricky. The Windows DDK may help (check Ntddk.h) - I don't have it available at the moment, and I can't seem to find decisive info right now - I think it's in ntoskrnl.exe or ntkrnlpa.exe, but I'm not sure, and don't currently have the tools to verify it.
但是,找到这个功能可能会有点棘手。 Windows DDK可能有所帮助(检查Ntddk.h) - 我目前没有它可用,我现在似乎无法找到决定性信息 - 我认为它在ntoskrnl.exe或ntkrnlpa.exe中,但我我不确定,目前还没有工具来验证它。
You might find it easier to just write a simple C++ app or something that calls the function, and then just running that.
您可能会发现编写一个简单的C ++应用程序或调用该函数的东西更容易,然后运行它。
Mind you, I'm assuming that Windows doesn't block you from accessing the function from user-space (.NET might have some special provisions). I have not tested it myself.
请注意,我假设Windows不阻止您从用户空间访问该功能(.NET可能有一些特殊规定)。我自己没有测试过。
#2
4
I do not know if it really works and I am sure you need Admin rights, but you could set the CrashOnCtrlScroll Registry Key and then use a SendKeys to send CTRL+Scroll Lock+Scroll Lock.
我不知道它是否真的有用,我确定你需要管理员权限,但你可以设置CrashOnCtrlScroll注册表项,然后使用SendKeys发送CTRL + Scroll Lock + Scroll Lock。
But I believe that this HAS to come from the Keyboard Driver, so I guess a simple SendKeys is not good enough and you would either need to somehow hook into the Keyboard Driver (sounds really messy) or check of that CrashDump has an API that can be called with P/Invoke.
但我相信这是来自键盘驱动程序,所以我想一个简单的SendKeys不够好,你要么以某种方式挂钩键盘驱动程序(听起来真的很乱)或检查CrashDump有一个API可以用P / Invoke调用。
http://support.microsoft.com/kb/244139
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
Restart
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters名称:CrashOnCtrlScroll数据类型:REG_DWORD值:1重新启动
#3
3
I would have to say no. You'd have to p/invoke and interact with a driver or other code that lives in kernel space. .NET code lives far removed from this area, although there has been some talk about managed drivers in future versions of Windows. Just wait a few more years and you can crash away just like our unmanaged friends.
我不得不说不。您必须p / invoke并与内核空间中的驱动程序或其他代码进行交互。虽然在未来的Windows版本中有一些关于托管驱动程序的讨论,但.NET代码远离这个领域。再等几年,你可以像我们的非管理朋友一样崩溃。
#4
2
As far as I know a real BSOD requires failure in kernel mode code. Vista still has BSOD's but they're less frequent because the new driver model has less drivers in kernel mode. Any user-mode failures will just result in your application being killed.
据我所知,真正的BSOD要求内核模式代码失败。 Vista仍然具有BSOD,但它们的频率较低,因为新的驱动程序模型在内核模式下的驱动程序较少。任何用户模式失败只会导致您的应用程序被杀死。
You can't run managed code in kernel mode. So if you want to BSOD you need to use PInvoke. But even this is quite difficult. You need to do some really fancy PInvokes to get something in kernel mode to barf.
您无法在内核模式下运行托管代码。所以如果你想要BSOD,你需要使用PInvoke。但即使这样也很困难。你需要做一些非常花哨的PInvokes才能在内核模式下获得barf。
But among the thousands of SO users there is probably someone who has done this :-)
但在成千上万的SO用户中,可能有人这样做了:-)
#5
2
You could use OSR Online's tool that triggers a kernel crash. I've never tried it myself but I imagine you could just run it via the standard .net Process class:
您可以使用OSR Online的工具来触发内核崩溃。我自己从未尝试过,但我想你可以通过标准的.net Process类运行它:
#6
1
I once managed to generate a BSOD on Windows XP using System.Net.Sockets in .NET 1.1 irresponsibly. I could repeat it fairly regularly, but unfortunately that was a couple of years ago and I don't remember exactly how I triggered it, or have the source code around anymore.
我曾经设法在Windows XP上使用.NET 1.1中的System.Net.Sockets不负责任地生成BSOD。我可以相当频繁地重复它,但不幸的是,这是几年前我不记得我是如何触发它,或者已经有了源代码了。
#7
1
Try live videoinput using directshow in directx8 or directx9, most of the calls go to kernel mode video drivers. I succeded in lots of blue screens when running a callback procedure from live videocaptureing source, particulary if your callback takes a long time, can halt the entire Kernel driver.
在directx8或directx9中使用directshow尝试实时视频输入,大多数调用都转到内核模式视频驱动程序。当从实时视频捕获源运行回调过程时,我成功地获得了大量蓝屏,特别是如果你的回调需要很长时间,可以暂停整个内核驱动程序。
#8
1
It's possible for managed code to cause a bugcheck when it has access to faulty kernel drivers. However, it would be the kernel driver that directly causes the BSOD (for example, uffe's DirectShow BSODs, Terence Lewis's socket BSODs, or BSODs seen when using BitTorrent with certain network adapters).
当托管代码可以访问有故障的内核驱动程序时,它可能会导致错误检查。然而,直接导致BSOD的是内核驱动程序(例如,uffe的DirectShow BSOD,Terence Lewis的套接字BSOD,或者在将BitTorrent与某些网络适配器一起使用时看到的BSOD)。
Direct user-mode access to privileged low-level resources may cause a bugcheck (for example, scribbling on Device\PhysicalMemory, if it doesn't corrupt your hard disk first; Vista doesn't allow user-mode access to physical memory).
对特权低级资源的直接用户模式访问可能会导致错误检查(例如,在Device \ PhysicalMemory上涂鸦,如果它不首先破坏您的硬盘; Vista不允许用户模式访问物理内存)。
If you just want a dump file, Mendelt's suggestion of using WinDbg is a much better idea than exploiting a bug in a kernel driver. Unfortunately, the .dump command is not supported for local kernel debugging, so you would need a second PC connected over serial or 1394, or a VM connected over a virtual serial port. LiveKd may be a single-PC option, if you don't need the state of the memory dump to be completely self-consistent.
如果你只想要一个转储文件,Mendelt建议使用WinDbg比利用内核驱动程序中的错误要好得多。遗憾的是,本地内核调试不支持.dump命令,因此您需要通过串行或1394连接的第二台PC,或通过虚拟串行端口连接的VM。如果您不需要内存转储的状态完全自我一致,LiveKd可能是单PC选项。
#9
0
This one doesn't need any kernel-mode drivers, just a SeDebugPrivilege. You can set your process critical by NtSetInformationProcess, or RtlSetProcessIsCritical and just kill your process. You will see same bugcheck code as you kill csrss.exe, because you set same "critical" flag on your process.
这个不需要任何内核模式驱动程序,只需要一个SeDebugPrivilege。您可以通过NtSetInformationProcess或RtlSetProcessIsCritical设置您的流程至关重要,并且只需终止您的流程。您将在杀死csrss.exe时看到相同的错误检查代码,因为您在进程上设置了相同的“严重”标记。
#10
0
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).
不幸的是,我知道如何做到这一点,因为我们的服务器上的.NET服务导致蓝屏。 (注意:Windows Server 2008 R2,而不是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.
我简直不敢相信.NET程序是罪魁祸首,但确实如此。此外,我刚刚在虚拟机中复制了BSOD。
The offending code, causes a 0x00000f4:
违规代码导致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.
如果有人想知道我为什么要复制蓝屏,那就没什么恶意了。我已经修改了我们的日志类来接受一个参数,告诉它直接写入磁盘,因为尽管调用了.Flush(),但BSOD之前的操作没有出现在日志中。我复制了服务器崩溃以测试日志记录更改。虚拟机正式崩溃但是日志工作正常。
EDIT: Killing csrss.exe appears to be what causes the blue screen. As per comments, this is likely happening in kernel code.
编辑:杀死csrss.exe似乎是导致蓝屏的原因。根据评论,这可能发生在内核代码中。
#1
15
The keyboard thing is probably a good option, but if you need to do it by code, continue reading...
键盘的东西可能是个不错的选择,但是如果你需要通过代码来做,继续阅读...
You don't really need anything to barf, per se, all you need to do is find the KeBugCheck(Ex) function and invoke that.
你真的不需要barf,本身你需要做的就是找到KeBugCheck(Ex)函数并调用它。
http://msdn.microsoft.com/en-us/library/ms801640.aspx http://msdn.microsoft.com/en-us/library/ms801645.aspx
For manually initiated crashes, you want to used 0xE2 (MANUALLY_INITIATED_CRASH) or 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) as the bug check code. They are reserved explicitly for that use.
对于手动启动的崩溃,您希望使用0xE2(MANUALLY_INITIATED_CRASH)或0xDEADDEAD(MANUALLY_INITIATED_CRASH1)作为错误检查代码。它们被明确保留用于该用途。
However, finding the function may prove to be a bit tricky. The Windows DDK may help (check Ntddk.h) - I don't have it available at the moment, and I can't seem to find decisive info right now - I think it's in ntoskrnl.exe or ntkrnlpa.exe, but I'm not sure, and don't currently have the tools to verify it.
但是,找到这个功能可能会有点棘手。 Windows DDK可能有所帮助(检查Ntddk.h) - 我目前没有它可用,我现在似乎无法找到决定性信息 - 我认为它在ntoskrnl.exe或ntkrnlpa.exe中,但我我不确定,目前还没有工具来验证它。
You might find it easier to just write a simple C++ app or something that calls the function, and then just running that.
您可能会发现编写一个简单的C ++应用程序或调用该函数的东西更容易,然后运行它。
Mind you, I'm assuming that Windows doesn't block you from accessing the function from user-space (.NET might have some special provisions). I have not tested it myself.
请注意,我假设Windows不阻止您从用户空间访问该功能(.NET可能有一些特殊规定)。我自己没有测试过。
#2
4
I do not know if it really works and I am sure you need Admin rights, but you could set the CrashOnCtrlScroll Registry Key and then use a SendKeys to send CTRL+Scroll Lock+Scroll Lock.
我不知道它是否真的有用,我确定你需要管理员权限,但你可以设置CrashOnCtrlScroll注册表项,然后使用SendKeys发送CTRL + Scroll Lock + Scroll Lock。
But I believe that this HAS to come from the Keyboard Driver, so I guess a simple SendKeys is not good enough and you would either need to somehow hook into the Keyboard Driver (sounds really messy) or check of that CrashDump has an API that can be called with P/Invoke.
但我相信这是来自键盘驱动程序,所以我想一个简单的SendKeys不够好,你要么以某种方式挂钩键盘驱动程序(听起来真的很乱)或检查CrashDump有一个API可以用P / Invoke调用。
http://support.microsoft.com/kb/244139
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
Restart
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters名称:CrashOnCtrlScroll数据类型:REG_DWORD值:1重新启动
#3
3
I would have to say no. You'd have to p/invoke and interact with a driver or other code that lives in kernel space. .NET code lives far removed from this area, although there has been some talk about managed drivers in future versions of Windows. Just wait a few more years and you can crash away just like our unmanaged friends.
我不得不说不。您必须p / invoke并与内核空间中的驱动程序或其他代码进行交互。虽然在未来的Windows版本中有一些关于托管驱动程序的讨论,但.NET代码远离这个领域。再等几年,你可以像我们的非管理朋友一样崩溃。
#4
2
As far as I know a real BSOD requires failure in kernel mode code. Vista still has BSOD's but they're less frequent because the new driver model has less drivers in kernel mode. Any user-mode failures will just result in your application being killed.
据我所知,真正的BSOD要求内核模式代码失败。 Vista仍然具有BSOD,但它们的频率较低,因为新的驱动程序模型在内核模式下的驱动程序较少。任何用户模式失败只会导致您的应用程序被杀死。
You can't run managed code in kernel mode. So if you want to BSOD you need to use PInvoke. But even this is quite difficult. You need to do some really fancy PInvokes to get something in kernel mode to barf.
您无法在内核模式下运行托管代码。所以如果你想要BSOD,你需要使用PInvoke。但即使这样也很困难。你需要做一些非常花哨的PInvokes才能在内核模式下获得barf。
But among the thousands of SO users there is probably someone who has done this :-)
但在成千上万的SO用户中,可能有人这样做了:-)
#5
2
You could use OSR Online's tool that triggers a kernel crash. I've never tried it myself but I imagine you could just run it via the standard .net Process class:
您可以使用OSR Online的工具来触发内核崩溃。我自己从未尝试过,但我想你可以通过标准的.net Process类运行它:
#6
1
I once managed to generate a BSOD on Windows XP using System.Net.Sockets in .NET 1.1 irresponsibly. I could repeat it fairly regularly, but unfortunately that was a couple of years ago and I don't remember exactly how I triggered it, or have the source code around anymore.
我曾经设法在Windows XP上使用.NET 1.1中的System.Net.Sockets不负责任地生成BSOD。我可以相当频繁地重复它,但不幸的是,这是几年前我不记得我是如何触发它,或者已经有了源代码了。
#7
1
Try live videoinput using directshow in directx8 or directx9, most of the calls go to kernel mode video drivers. I succeded in lots of blue screens when running a callback procedure from live videocaptureing source, particulary if your callback takes a long time, can halt the entire Kernel driver.
在directx8或directx9中使用directshow尝试实时视频输入,大多数调用都转到内核模式视频驱动程序。当从实时视频捕获源运行回调过程时,我成功地获得了大量蓝屏,特别是如果你的回调需要很长时间,可以暂停整个内核驱动程序。
#8
1
It's possible for managed code to cause a bugcheck when it has access to faulty kernel drivers. However, it would be the kernel driver that directly causes the BSOD (for example, uffe's DirectShow BSODs, Terence Lewis's socket BSODs, or BSODs seen when using BitTorrent with certain network adapters).
当托管代码可以访问有故障的内核驱动程序时,它可能会导致错误检查。然而,直接导致BSOD的是内核驱动程序(例如,uffe的DirectShow BSOD,Terence Lewis的套接字BSOD,或者在将BitTorrent与某些网络适配器一起使用时看到的BSOD)。
Direct user-mode access to privileged low-level resources may cause a bugcheck (for example, scribbling on Device\PhysicalMemory, if it doesn't corrupt your hard disk first; Vista doesn't allow user-mode access to physical memory).
对特权低级资源的直接用户模式访问可能会导致错误检查(例如,在Device \ PhysicalMemory上涂鸦,如果它不首先破坏您的硬盘; Vista不允许用户模式访问物理内存)。
If you just want a dump file, Mendelt's suggestion of using WinDbg is a much better idea than exploiting a bug in a kernel driver. Unfortunately, the .dump command is not supported for local kernel debugging, so you would need a second PC connected over serial or 1394, or a VM connected over a virtual serial port. LiveKd may be a single-PC option, if you don't need the state of the memory dump to be completely self-consistent.
如果你只想要一个转储文件,Mendelt建议使用WinDbg比利用内核驱动程序中的错误要好得多。遗憾的是,本地内核调试不支持.dump命令,因此您需要通过串行或1394连接的第二台PC,或通过虚拟串行端口连接的VM。如果您不需要内存转储的状态完全自我一致,LiveKd可能是单PC选项。
#9
0
This one doesn't need any kernel-mode drivers, just a SeDebugPrivilege. You can set your process critical by NtSetInformationProcess, or RtlSetProcessIsCritical and just kill your process. You will see same bugcheck code as you kill csrss.exe, because you set same "critical" flag on your process.
这个不需要任何内核模式驱动程序,只需要一个SeDebugPrivilege。您可以通过NtSetInformationProcess或RtlSetProcessIsCritical设置您的流程至关重要,并且只需终止您的流程。您将在杀死csrss.exe时看到相同的错误检查代码,因为您在进程上设置了相同的“严重”标记。
#10
0
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).
不幸的是,我知道如何做到这一点,因为我们的服务器上的.NET服务导致蓝屏。 (注意:Windows Server 2008 R2,而不是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.
我简直不敢相信.NET程序是罪魁祸首,但确实如此。此外,我刚刚在虚拟机中复制了BSOD。
The offending code, causes a 0x00000f4:
违规代码导致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.
如果有人想知道我为什么要复制蓝屏,那就没什么恶意了。我已经修改了我们的日志类来接受一个参数,告诉它直接写入磁盘,因为尽管调用了.Flush(),但BSOD之前的操作没有出现在日志中。我复制了服务器崩溃以测试日志记录更改。虚拟机正式崩溃但是日志工作正常。
EDIT: Killing csrss.exe appears to be what causes the blue screen. As per comments, this is likely happening in kernel code.
编辑:杀死csrss.exe似乎是导致蓝屏的原因。根据评论,这可能发生在内核代码中。