You've said it with a bit more vitriol than what is needed, but you're right.
Thanks. The reason I am being blunt is that I've been called an idiot a few times in this thread. Probably by people who have never written any software. Who have never debugged problems. And who have no idea how software works.
If it upsets them in some way, then you've got a BSOD because drivers are not confined to the userland.
Drivers by definition live in kernelspace.
People might think that things like DirectX are drivers too. But technically they are not. They are libraries. Libraries that implement an API. DirectX lives in userland, but does the calling of systemcalls.
What happens when "the drivers get upset" ? That depends on how they get upset.
If an application does a systemcall that "upsets the drivers", then the driver should just return the systemcall with an error message. That's it. The driver and kernel keep running. Other applications keep running. The machine continues. The application that did the bad systemcall decides itself what it shall do. It can continue. If the programmers were good, they took care of the case where they get an error return. But if they didn't program very defensively, then they could continue in a state they didn't expect, and crashes could happen. But *only* crashes to the desktop.
But if the drivers get upset because the hardware does unexpected things, then it is end of story. If the drivers are able to reset a piece of hardware to a known state, they will try to do that. (Ever seen the short black screen, and then a warning that your videocard has been reset ?). But if they can't do that, they will print the famous Blue Screen of Death, and halt the machine. But sometimes, the machine is in such a bad state that that can't even happen (e.g. if the kernel scribbled over its own memory by mistake). Then you get a black screen crash. Not blue. Now what does that mean ? It means that hardware has acted in a way that even the driver and kernel programmers didn't expect. That is a clear sign that the hardware is faulty.
If this were exclusively a problem related to a certain driver or chipset (say, all the ATI cards and no Nvidia ones) I'd be on their forums, not this one.
You must realize that bugs in drivers, or in the kernel, usually cause a Blue Screen of Death. That is really different from the black screen. Blue Screen of Death is much more likely to be a driver error. Black screen are much more likely to be a hardware error. And who says the problem is in the videocard driver ? Maybe it's in the RealTek soundchips that is on so many motherboards. Maybe in the PCIE chips. Who knows ?
it seems so unlikely that two completely different chips with completely different driver codebases, could have precisely the same flaw.
But you don't know that is the same flaw.
The troubleshooting here is very unprecise. People reporting "black screen and computer rebooting". A power outage has those symptoms. They are just too vague. We don't even know which piece of hardware is resetting the whole machine. And unfortunately, it is very hard for amateur-hardware people like ourselves to do proper troubleshooting.
But, it's Skyrim that's being played, exclusively, while these crashes happen. The hardware is not constant. The OS is not constant. Nothing is constant but the fact that Skyrim is the game being played.
This reasoning is like poking sticks in frogs.
Maybe Skyrim is the first game to stress both CPU and GPU. And while doing this, causing the hardware to draw more power than normally. And low-power, or old, or flakey PSUs get hiccups. We don't know. But from a architectural point of view, an application is never responsible for a hard crash.
But, it is within Bethesda's power to at least find out what is causing this and stop it from happening. That's all.
I kinda agree.
But is there anyone who can actually force such a crash ? Do we have scenarios to reproduce the problem at will ? If not, then it is harder to troubleshoot for the developer. And imho, if the problem can not reliably be reproduced, it points again more towards the hardware.
I'll note something even more worrysome.
Who says that Bethesda actually has engineers who can look at this ?
Bethesda bought (a license to) the GameBryo engine from NDL. And their engines are based on that. But who says that Bethesda employs the engineer(s) who done the new features ? I could imagine a scenario where Bethesda content developers made a list of features they wanted. And then sent that list to NDL. It makes much more sense to have NDL implement new features than hire your own engineer(s), train them to make them familiar with the engine design and code, and let them do the work. I wouldn't be surprised if Bethesda just didn't have the people to do a lot of work on the engine. Sad. But with modern management, I don't find it unlikely. If Bethesda management didn't find it cost-effective to hire a programmer to do the UI on a PC, then I can't believe they would find it cost-effective to hire a very technical programmer to work with low-level stuff in a 3rd party engine.
Personally, I don't care whose fault it is, or what hardware (if any) is defective - if we need to ascertain that in order to play Skyrim without experiencing BSODs, no sweat. That's cool. I just want to play Skyrim without getting BSODs all the time. That's it.
I see your point. And I agree that Bethesda should be the driving force to help their customers solve the problem.
But you are talking about BSOD here. Repeatedly. You realize that a Blue Screen of Death is something different than a "black screen", right ? You realize that the troubleshooting, the actual reporting of the problem is so vague, that any engineer can't really do much with that. That is why I am not convinced that all the reported problems are one and the same. The reports are just not specific enough to draw any conclusions. Sorry.
» Tue May 29, 2012 12:10 am 
