Can an unhandled exception in a C# application cause a blue screen of death?
+2
A:
No; ideally, there should be no way to cause a BSOD from C#.
Show us the code that is causing it and we'll see if we can help.
BlueRaja - Danny Pflughoeft
2010-05-20 20:18:54
+12
A:
Not unless you're dealing with unmanaged resources like raw memory access. (In which case the Exception isn't likely the cause)
.NET Exceptions will be caught by the runtime environment. You can crash your PROGRAM but not the OS.
In my experience the only things that cause BSOD's are bad drivers, and hardware errors. (This of course is not an extensive list of the causes of BSOD, but that's the first place I look.)
Aren
2010-05-20 20:19:12
Unmanaged resources cannot cause a BSOD.
Stephen Cleary
2010-05-20 20:27:18
@Stephen Cleary: I'm fairly certain a call to unmanaged code that references a faulty driver could cause a BSOD, the point was that within the context of .NET (Where Exceptions live) you wont be causing BSOD's. Once you leave managed code, there's no guarantees.
Aren
2010-05-20 20:36:32
@Aren: What do you mean by, "a call to unmanaged code that references a faulty driver could cause a BSOD." Can you please elaborate?
Jim Fell
2010-05-20 20:38:31
A driver file (ser2pl.sys), which was installed for a USB-to-RS232 converter, is specifically called out as the problem on the BSOD. I've tried a number of different things, but (long story short) the BSOD only occurs on older systems (same OS: WinXP SP3) equipped with a legacy USB 1.1 root hub. However, other C# applciations using the same converter do not cause a crash. Changing the baud rate and driver port configuration seem to make no difference.
Jim Fell
2010-05-20 20:39:31
@Aren: No matter what functions you call in a driver (in this case, opening/closing/reading/writing), it's the driver's job to *always* prevent BSODs. .NET code cannot be blamed; it's a bug in the driver.
Stephen Cleary
2010-05-20 20:43:05
Followup: For that matter, it's not just .NET code. User-mode code (which includes .NET code *and* native code) cannot cause BSODs. BSODs can only be caused by bugs in kernel-mode code, which is comprised of the OS and its drivers (or an actual hardware failure). Of those three causes, drivers are by far the most common culprit.
Stephen Cleary
2010-05-20 20:45:27
@Stephen Cleary: That's what I meant. You can activate an operation in a driver that was written poorly from .NET (leaving managed for unmanaged). The idea i was trying to convey was that you're not 100% safe from BSODs when using .NET apps, but the .NET app is not to blame. (The unmanaged code/resource is, in this case the driver).@Jim Fell: Your problem is likely with that driver or the hardware. Even though other apps don't cause the problem, the manner in which you're using it is likely where your problem is.
Aren
2010-05-20 21:00:58
@Aren: Unmanaged non-driver code cannot cause BSODs. In particular, your example of writing various memory locations cannot cause a BSOD, even in unmanaged code (but a *driver* writing random memory locations *can*).
Stephen Cleary
2010-05-20 21:45:27
+2
A:
No, it wouldn't. That's not to say that you couldn't potentially cause a BSOD with a C# program, but if you did, it wouldn't be due to an unhandled exception being thrown.
Eric Petroelje
2010-05-20 20:19:57
+2
A:
The only causes for a BSOD are hardware error, OS bug, or driver bug. .NET code cannot ever cause a BSOD.
Stephen Cleary
2010-05-20 20:27:00
Yes, a driver file (ser2pl.sys), which was installed for a USB-to-RS232 converter, is specifically called out as the problem on the BSOD. I've tried a number of different things, but (long story short) the BSOD only occurs on older systems (same OS: WinXP SP3) equipped with a legacy USB 1.1 root hub. However, other C# applciations using the same converter do not cause a crash. Changing the baud rate and driver port configuration seem to make no difference.
Jim Fell
2010-05-20 20:36:00
I assume that's the result of a WinDbg `analyze -v`, which has a correct analysis at least 95% of the time, I'd say. Pretty much the only thing you can do is update the drivers (or instruct your clients to, if these are client machines).
Stephen Cleary
2010-05-20 20:38:47
@Stephen: Thanks. What is WinDbg? Is that part of C#, or is it used to report on the error on the BSOD?
Jim Fell
2010-05-20 20:53:02
Ah, no. It's part of [Debugging Tools for Windows](http://www.microsoft.com/whdc/devtools/debugging/default.mspx). A BSOD will normally create a full dump or minidump (configurable under System Properties), and this dump file can be loaded into WinDbg. The most common procedure is to then type `!analyze -v`, which does an automated analysis of the BSOD, displaying the most likely culprit.
Stephen Cleary
2010-05-20 20:57:29
A:
Can you share the code that interacts with your driver?
Either way, it looks like the driver itself is at fault here: A BSOD is the result of an unhandled crash in code running in the kernel (your driver in this case).
bitcrazed
2010-05-20 20:39:53
+2
A:
Yeah, it is possible, indirectly. There's plenty of unmanaged code you'll use when you work with namespaces like System.Management, System.Windows.Media, System.Drawing.Printing, System.IO.Ports. That code can issue device driver calls which can trigger a bug in the device driver. Blue screen is next.
Obviously the real problem is not in the managed code, it is a crummy driver.
But to answer the question directly: no, an unhandled managed exception cannot cause a BSOD.
Hans Passant
2010-05-20 20:42:06