tags:

views:

386

answers:

8

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?

+10  A: 

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.

Jon Skeet
"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".
S.Lott
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.
DrJokepu
+4  A: 

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

Alex Reitbort
+3  A: 

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?

Makach
+4  A: 

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.

DrJokepu
+1: A bug in windows? Really? Who would have thought of that?
S.Lott
@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.
0xA3
@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.
S.Lott
@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.
0xA3
+4  A: 

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.

0xA3
+1  A: 

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.

T.E.D.
Yep, It can be a hardware failure.
yelinna
+1  A: 

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)

MSalters
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.
David Thornley
OS bugs are an indisputable fact but that observation doesn't take away anything from the responsibility.
MSalters
A: 

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.

yelinna