一个简单的程序会导致 BSOD 吗？
我有一位客户告诉我，我的程序（简单的用户态程序，而不是驱动程序）正在使他的系统崩溃并出现蓝屏死机 (BSOD)。他说他在其他程序中从未遇到过这种情况，并且他可以用我的程序轻松重现它。
BSOD 的类型为 CRITICAL_OBJECT_TERMINATION (0x000000F4)，对象类型为 0x3（进程）：对系统操作至关重要的进程或线程意外退出或终止。
一个简单的程序是否会导致 BSOD（即使在 Vista 上...）或者他应该检查硬件或操作系统安装？
I've got a customer who told me that my program (simple user-land program, not a driver) is crashing his system with a Blue Screen Of Death (BSOD). He says he has never encountered that with other program and that he can reproduce it easily with mine.
The BSOD is of type CRITICAL_OBJECT_TERMINATION (0x000000F4) with object type 0x3 (process): A process or thread crucial to system operation has unexpectedly exited or been terminate.
Can a simple program be responsible for a BSOD (even on Vista...) or should he check the hardware or OS installation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
仅仅因为您的程序不是驱动程序并不意味着它不会使用驱动程序。
理论上，您的代码不应该使计算机出现 BSOD。由操作系统来确保这种情况不会发生。根据定义，这意味着硬件或程序以外的代码中存在问题。但这并不排除您的代码中存在错误。
Just because your program isn't a driver doesn't mean it won't use a driver.
In theory, your code shouldn't be able to BSOD the computer. It's up to the OS to make sure that doesn't happen. By definition, that means there's a problem somewhere either in hardware or in code other than your program. That doesn't preclude there being a bug in your code as well though.
导致用户空间程序出现 BSOD 的最简单方法是（据我所知）杀死 Windows 子系统进程（csrss.exe）。这不需要有故障的硬件，也不需要内核或驱动程序中的错误，它只需要管理员权限1。
你的代码到底在做什么？错误消息（“对系统操作至关重要的进程或线程意外退出或已终止。”）听起来像是重要的系统进程之一已终止。也许您正在杀死一个进程并无意中获得了错误的进程？
如果可能的话，您可以尝试从该客户那里获取内存转储。使用Windows 调试工具，您可以按照此处。
1Windows 不会阻止您 这样做因为它"让管理员保持控制他们的计算机”。所以这是设计使然，而不是错误。阅读雷蒙德的文章，您就会明白原因。
The easiest way to cause a BSOD with a user-space program is (afaik) to kill the Windows subsystem process (csrss.exe). This doesn't need faulty hardware nor a bug in the kernel or a driver, it only needs administrator privileges1.
What is your code exactly doing? The error message ("A process or thread crucial to system operation has unexpectedly exited or been terminate.") sounds like one of the essential system processes terminated. Maybe you are killing a process and unintentionally got the wrong process?
If somehow possible you could try to get a memory dump from that customer. Using the Debugging Tools for Windows you can then further analyze that dump as described here.
1Windows doesn't prevent you from doing so because it "keeps administrators in control of their computer". So this is by design and not a bug. Read Raymond's articles and you will see why.
简短的回答是肯定的。长答案取决于您的程序应该做什么以及它是如何做的？
Short answer is yes. Long answer depends on what is you program is suppose to do and how it does it?
通常情况下，不应该。如果确实如此，则一定存在
我敢打赌 关于第二个选项（设备驱动程序），但如果您能给我们提供更详细的转储，那将会很有趣。
Normally, it shouldn't. If it does, there must be either
I would bet on option number two (device driver) but it would be interesting if you could get us a more detailed dump.
嗯，是的，它可以 - 但出于许多不同的原因。
这就是为什么我们在不同的机器、操作系统、硬件等上进行测试。
您是否为您的程序设置了一些要求并且您的用户是否遵循这些要求？
Well, yes it can - but for many different reasons.
That's why we test on different machines, operating systems, hardware etc..
Have you set some requirements for your program and is your user following them?
如果您无法自己复制它，并且您的程序不需要管理员运行，我会有点怀疑
如果您可以物理访问客户端盒子，则可能值得使用最新的扫描程序运行完整的病毒扫描，并运行完整的 memtest 就可以了。
我曾经有一个看起来很稳定的系统，除了某些程序无法在其上运行（有时会使盒子崩溃）。 Memtest 显示我的 RAM 有一些坏位，但它们位于更高的模拟中，因此只有当程序尝试使用大量 RAM 时才会访问它们。
If you can't duplicate it yourself, and your program doesn't need admin to run, I'd be a bit suspicous about
If you can get physical access to the client box, it might be worth running a full virus scan with an up-to-date scanner, and running a full memtest on it.
I had a system once that seemed stable, except that a certian few programs wouldn't run on it (and would sometimes crash the box). Memtest showed my RAM had some bad bits, but they were in higer sims, so they only got accessed if a program tried to use a lot of RAM.
不，这几乎是根据定义。最糟糕的是，用户态应用程序可能“触发”了 Windows 错误或驱动程序错误。但现代桌面操作系统对其自身的完整性负有全部责任； BSOD 是完整性的失败。因此，操作系统负责，而且只有操作系统负责。
（仅您的应用程序可能暴露的 BSOD 错误示例：作为驱动程序实现的病毒扫描程序，在执行扇区 0xFFFFFFFF 中的文件时崩溃，该扇区在这台机器上恰好包含您应用程序的一个 DLL）
No, and that is pretty much by definition. The worst thing that you can say is that a user-land application may have "triggered" a Windows bug or a driver bug. But a modern desktop Operating System is fully responsible for its own integrity; a BSOD is a failure of that integrity. Therefore the OS is responsible, and only the OS.
(Example of a BSOD bug that your application alone could expose: a virus scanner implemented as a driver, that crashes when executing a file from sector 0xFFFFFFFF, a sector that on this one machine just happens to contain one DLL of your application)
当程序结束时，我在退出应用程序而不停止所有进程和 BD 连接时遇到问题（我使整个 IDE 崩溃）。我将“停止和断开连接”代码放在主窗体的“Form_Closed”事件的“终止”中，问题得到解决，我不知道这是你的情况。
另一个问题可能是，如果用户尝试访问您的应用程序正在使用的相同资源（数据库、硬件、套接字等）。询问他/她发生 BSOD 时正在使用哪些应用程序。
病毒是无法被丢弃的。
I had problems when exit my app without stopping all the processes and BD connections when the program ends (I crashed the entire IDE). I place the "stopping and disconnecting" code in the "Terminate" of "Form_Closed" event of my main form and the problem wa solved, I don't know it this is your situation.
Another problem can be if the user is trying to access the same resources your app is using (databases, hardware, sockets, etc). Ask him/her about what apps he/she is using when the BSOD happens.
A virus can't be discarded.