Visual Studio 2010 - BSOD, always crashing...

This is a discussion on Visual Studio 2010 - BSOD, always crashing... within the General Discussions forums, part of the Community Boards category; Nevertheless I was intrigued by his code. I think the right wording is that a BSOD is issued by the ...

  1. #16
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  2. #17
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,450
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Yes, I agree there. I never saw Visual Studio or Office generate a BSOD since Windows XP. It makes no sense.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  4. #19
    Registered User Devils Child's Avatar
    Join Date
    Jan 2008
    Posts
    244
    To fix a BSOD? I doubt that.
    thats just an assumption. i've seen UAC causing worse problems.
    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.

  5. #20
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  6. #21
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,177
    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

  7. #22
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    Quote Originally Posted by phantomotap View Post
    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.
    Indeed, someone may go for the coup de grace and use that dastardly MessageBox function.

    Quote Originally Posted by Mario
    It tries to incorrectly set the new process token (I suspect it crashes right in the system call, not in p.Kill.
    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.

  8. #23
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Quote Originally Posted by Elysia View Post
    Why do you continue to be difficult? A software-mode application cannot, and I repeat, cannot cause a BSOD.
    ONLY driver-mode applications/drivers can.
    So do us all a favor, and do the research steps above. Find the culprit instead of coming here and making up excuses.

    Clearly, Visual Studio is the trigger that causes this driver-mode code to cause a BSOD, but VS itself is not the culprit.
    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.

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Quote Originally Posted by adeyblue View Post
    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
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  10. #25
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    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?
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. LDAP Query
    By Travoiz in forum C++ Programming
    Replies: 0
    Last Post: 08-13-2009, 02:58 PM
  2. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 04:45 PM
  3. C++ std routines
    By siavoshkc in forum C++ Programming
    Replies: 33
    Last Post: 07-28-2006, 12:13 AM
  4. load gif into program
    By willc0de4food in forum Windows Programming
    Replies: 14
    Last Post: 01-11-2006, 09:43 AM
  5. Learning OpenGL
    By HQSneaker in forum C++ Programming
    Replies: 7
    Last Post: 08-06-2004, 08:57 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21