Login/Register
Can a simple program be responsible for a BSOD?
Asked Answered
Solved windowsbsod
D

8

9

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?

Dunning answered 19/10, 2009 at 12:39 Comment(6)
What language is it written in? – Satang
It's a C++ program using wxWidgets toolkit. – Dunning
@math: it could be a bug in wxWidgets that is giving some problems to the Win API. – Fuse
Check this out (from 2005): symantec.com/security_response/vulnerability.jsp?bid=13121 – Traverse
Just out of curiosity, could you reproduce (and solve) the problem using the a crash dump? – Papandreou
@divo: not for the moment, I don't have one. I have chosen your answer because of the possibility that a user with admin privileges can kill (inadvertently or not) a critical process which can then trigger a BSOD. I don't know if it's my case but it's worth noting. – Dunning
P
6

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.

Papandreou answered 19/10, 2009 at 13:2 Comment(0)
R
11

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.

Revet answered 19/10, 2009 at 12:42 Comment(2)
"In theory"? Maybe too strong a word when describing Windows. I don't think there's a real science that postulates any theories about Windows. I think this is more of a hope that Microsoft harbors. I think the right word might be "Hopefully". – Enantiomorph
S.Lott: I suppose what he meant that in x86 protected mode, ring 3 shouldn't be able to take down ring 0. This has nothing to do with Windows. – Vainglorious
P
6

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.

Papandreou answered 19/10, 2009 at 13:2 Comment(0)
E
4

Short answer is yes. Long answer depends on what is you program is suppose to do and how it does it?

Edrei answered 19/10, 2009 at 12:42 Comment(0)
V
4

Normally, it shouldn't. If it does, there must be either

  • A bug in the Windows kernel (possible but very unlikely)
  • A bug in a device driver (not necessarily in a device your program uses, this could get quite complicated)
  • A fault in the hardware

I would bet on option number two (device driver) but it would be interesting if you could get us a more detailed dump.

Vainglorious answered 19/10, 2009 at 12:44 Comment(4)
+1: A bug in windows? Really? Who would have thought of that? – Enantiomorph
@S.Lott: Surprisingly and despite all those Windows jokes, but the few BSOD I have seen since Windows XP could all be traced down to third-party products or hardware faults. – Papandreou
@divo: Good point. However, when a 3rd party product can crash Windows, I suspect there's still a bug somewhere outside the 3rd party component. – Enantiomorph
@S.Lott: This would only be true if Windows didn't allow any third-party components to run in kernel mode. Running device drivers in user-mode is possible and more stable but this comes not for free - usually the performance impact for all the user/kernel mode transitions would be too high. – Papandreou
S
3

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?

Sheree answered 19/10, 2009 at 12:43 Comment(0)
U
1

If you can't duplicate it yourself, and your program doesn't need admin to run, I'd be a bit suspicous about

  • The stability of that system's hardware
  • The virus/malware status of that system.

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.

Unalloyed answered 19/10, 2009 at 14:1 Comment(1)
Yep, It can be a hardware failure. – Thorathoracic
C
1

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)

Cityscape answered 19/10, 2009 at 14:13 Comment(2)
I wouldn't say only the OS is responsible. Certainly the OS should be uncrashable from a non-privileged app, but we do have to deal with real-life operating systems. – Vine
OS bugs are an indisputable fact but that observation doesn't take away anything from the responsibility. – Cityscape
T
-1

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.

Thorathoracic answered 19/10, 2009 at 15:39 Comment(1)
Funny how an answer can collect a negative vote eight years later (I was so young back then!) – Thorathoracic

© 2022 - 2024 — McMap. All rights reserved.