Nevertheless I was intrigued by his code.
I think the right wording is that a BSOD is issued by the kernel. A program running in software-mode can be responsible for a BSOD if it makes a call the kernel internals that generate an unrecoverable error.
His code is illustrative. It tries to incorrectly set the new process token (I suspect it crashes right in the system call, not in p.Kill). And it's a clear example of a program generating a BSOD.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
But you can be sure no Microsoft program does that.
And if I ever figure out a program that calls kernel functions like that directly, I'll get rid of it. The reason we have stable operating systems nowadays is just because we cannot access kernel mode directly.
Originally Posted by Adak
Yes, I agree there. I never saw Visual Studio or Office generate a BSOD since Windows XP. It makes no sense.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
thats just an assumption. i've seen UAC causing worse problems.To fix a BSOD? I doubt that.
but it's not the UAC, its disabled here.
and sorry for not listening, i will check the dumps as soon as i have time, thank you so far.
if anyone has any other idea, it would be appreciated.
You mentioned before you get the BSOD when you type on VS2010. So three suggestions:
1. Check your keyboard drivers. Remove them if you are using manufacturer drivers and use instead windows own drivers. Or if you are using windows own drivers, try updating them or reinstalling them.
2. Are you using any VS plugins like CodeRush or anything else that tampers with VS editor window? Highly unlikely this is the cause. But you may want to try and disable them (disabling is enough) and see if you BSOD *after restarting* VS.
3. Your video card, as mentioned before. Not related to your keyboard, but BSODs often are traced to video drivers. Here the suggestion is to remove your video drivers and use Windows default drivers. Reboot and check if you BSOD this time.
Last edited by Mario F.; 07-08-2010 at 03:15 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
To be fair, `CreateProcessAsUser', a function known to use `NtSetInformationProcess' behind the scenes, can cause "BSOD" if abused. (This has been patched.)
It isn't likely that Microsoft somehow misused `CreateProcessAsUser'; I'm just saying that it is possible for application code to cause a "BSOD" because of underlying issues in the services provided by the operating system. (For example, the underlying services not checking for invalid input.)
*shrug*
Mostly I'm just posting to say that assuming you are safe because a program doesn't use "driver mode" or an undocumented API is foolish.
Soma
Indeed, someone may go for the coup de grace and use that dastardly MessageBox function.
It doesn't crash because it does anything buggy, it bugchecks because it's meant to. It sets the critical process flag which causes a bugcheck if the process ends, and then ends the process (Google RtlSetProcessIsCritical and ProcessBreakOnTermination for more info). UAC may 'fix' it because SeDebugPrivilege is required to set and unset it, something which isn't enabled for standard users and crippled admins.
Which is a flawed theory. Consider a function xyz(), which when called BSODs. VS2010 (a software-mode application) calls this kernel-mode xyz() function. Boom, BSOD. By any definition, VS2010 initiated (and thus caused) the BSOD. And we all know Microsoft and their undocumented functions...
Last edited by zacs7; 07-08-2010 at 04:46 PM.
Ah, so that's what 29 is; The critical flag value?
Are you sure about that? I never knew you could set a process critical flag with anything other than RtlSetProcessIsCritical. I just assumed 29 was invalid and, since it is expected for these undocumented kernel functions to not check their values, it crashed.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Nevermind. I went and google for it. Thanks adeyblue. Didn't notice before it's an enum. An invalid value wouldn't even compile.
However, I do have a question:
The enum is listed here: Windows API Enumerations - Process Hacker
The value is ProcessBreakOnTermination (so it confirms the bugcheck happens when killing the process.). But is this the same as a critical process? That is, IIRC, a critical process can't be killed from the task manager. Will a process merely set with the ProcessBreakOnTermination flag behave the same way?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
