1. #1

    How the BSOD actually 'works', why, etc.

    So on Sysnative we've talked many times in-depth regarding postmortem debugging kernel-dumps as far as blue screen crashes goes. Well, I decided maybe it's time to go ahead and actually in detail explain why a blue screen occurs, what actually goes on when a blue screen occurs, etc.

    -- Disclaimer: At the time of this post, I have never myself experienced a BSOD on my Windows 8.1 system, so I cannot 100% confirm whether or not the display is shifted to a low-res VGA mode when paining the screen. I may use NotMyFault to test this out and will edit when I get a confirmation. For now though, let's assume nothing has changed and hope I'm correct : )



    First off, why does the blue screen of death occur? Well, it's important to know that there are many reasons as to why a blue screen occurs. Just to name a few:


    • References to invalid/inaccessible memory; causes access violations, etc.
    • Unexpected exceptions.
    • Bugs in drivers causing a fault in a kernel-mode driver, 3rd party drivers doing what I first mentioned, etc.


    Again, this is very few of the potential reasons why, but some of the most prevalent. For those interested, here's actually a distribution of what causes bug checks most commonly in Windows.

    How the BSOD actually 'works', why, etc.-6758-error_categories_distribution-jpg

    Above is a picture I found on Google from a TechNet article, so thanks to the author for this! It's from Windows Internals - 5th Edition. AFAIK there is not one in the 6th, at least I have not seen it throughout my reading or research afterwards. With this said, it's likely not entirely accurate in regards to today, but I imagine it has not changed too much. Given I analyze postmortem kernel-dumps quite a bit, I am surprised to see pool is so low. Again, this was way back in the writing of the 5th edition which was during Vista's legacy, so many things have changed since then. It's up in the air, really!

    Now, with that said we understand a few reasons as to why Windows stops and a blue screen occurs. Good! Now let's also go ahead and understand that if any of these things occurred, Windows could theoretically not stop and keep going when one of these is occurring. Why doesn't it just do this? Well, it's actually extremely simple, and that's because many of these things can cause severe data/memory corruption which could actually lead to hardware problems.

    Since we don't want any of that, Windows thankfully has a fail-safe known to us as the Blue Screen of Death (BSOD -- abbreviating from now on). If Windows detects that there is a serious problem that is unrecoverable, it will stop all executions, switch the display to the basic/low-res VGA mode, paint the actual blue screen itself, write memory/crash information to what we know as a memory dump (crash dump/dmp file/dmp), and display a stop code (bug check). All of this is done through a series of functions.

    Now that we're on this topic, I must STRESS and dispel the misconception right now that the blue screen itself is a bad thing. It's not! The blue screen is a good thing, and it's making it so our data doesn't become completely corrupt. Remember, the blue screen happens because Windows has detected something has gone horribly wrong, and it cannot recover and/or stop it. When this happens, the appropriate bug check based on what caused the error is called, and the blue screen is painted.

    Bottom line... the blue screen is our friend, not our enemy : )



    As discussed above, a blue screen happens when Windows detects that there's an unrecoverable/irreversible problem occurring. Regardless of what this actual problem is, the end result is a blue screen. As I mentioned above, this blue screen process actually happens through functions.

    Despite the belief that there is only one function that calls and/or begins the bug check process, it is not true! There's two!




    (Clickable for their MSDN links)!


    First off, before stating their differences, let's make it easy by saying that both of these functions take what is known as a BugCheckCode parameter. What is a BugCheckCode parameter? Good question! This parameter is otherwise known as a STOP code (for example - 0x0000000A, 0x0000001A, 0x0000009F, etc). These stop codes (otherwise known as/called 'bug checks') are what allows us (other than actually debugging the crash dump itself) to troubleshoot the blue screen. It allows us to go ahead and troubleshoot because each of these STOP codes has an actual preset meaning/cause as to why it occurred.

    Great, so now that we know that information, what is the difference between KeBugCheckEx and KeBugCheck? Good question! KeBugCheck calls KeBugCheckEx and sets the four parameters to zero.

    Example - {0,0,0,0}

    Essentially, the KeBugCheckEx function itself provides more information because it sets the four parameters to their preset meanings based on the STOP code/bug check.



    Once KeBugCheckEx is called, it first goes ahead and disables all interrupts by calling the KiDisableInterrupts function. After this is done, it transitions to a special system-state in which the STOP code is dumped (0x0000000A for example). It accomplishes the transition and dump of the STOP code with a call from KiDisableInterrupts to the HalDisplayString function.

    HalDisplayString itself goes ahead and first takes one parameter (string to print to the blue screen), and does a check to see if the system is in its special system-state (blue screen 'mode'). If it is not in this state however, it will go ahead and attempt to successfully use the firmware to swap to this proper system-state in order to continue.

    Once the check has been successfully completed and confirmed that the system is in its proper state, HalDisplayString goes ahead and dumps the string into text-mode video memory at the current location of the cursor. This is kept track of throughout all of the future calls.

    After all of this is successfully accomplished, KeBugCheckEx then goes ahead and calls the KeGetBugMessageText function. The KeGetBugMessageText translates the stop code into its text-equivalent. There's a bug check reference list here.

    Once that is completed, KeBugCheckEx will then go ahead at this point and start to call any bug check handlers that drivers registered (if any). The handlers themselves are registered by calling KeRegisterBugCheckCallback which goes ahead and fills in a buffer that is allocated by the caller of the register routine so it can be debugged in the debugging client. It also essentially in general allows any drivers a chance to stop their devices.

    Once that is through, we move on to calling the KeRegisterBugCheckReasonCallback function which goes ahead and allows any drivers to write data to the crash dump or write crash dump information to alternate devices.

    Once the above is done (if possible, because handlers aren't always registered) KeDumpMachineState is called which dumps the rest of the text on the screen. However, the first thing KeDumpMachineState tries to do is successfully interpret the four parameters that were passed to KeBugCheckEx as a valid address within a loaded module. It will go ahead and stop when it can successfully resolve one. The function that is used to accomplish this is KiPcToFileHeader.

    KiPcToFileHeader returns for the first parameter that it goes ahead and successfully resolves, immediately prints the following text form of the STOP code, and also includes the base address of the module and the module’s name.



    Below I will share the difference between your standard 8/8.1 and XP/Vista/7 screens:

    How the BSOD actually 'works', why, etc.-blue_screen_of_death-8-png

    (Windows 8/8.1 displaying 0x5C bug check)

    How the BSOD actually 'works', why, etc.-blue_screen_of_death-xp_vista_7-jpg

    (Windows XP/Vista/7 displaying 0x50 bug check)



    Thanks for reading, and thanks to NT Insider and MSDN as always for double-checking!


    Last edited by Patrick; 06-23-2014 at 01:46 AM.
    blueelvis, LilBambi, zigzag3143 and 7 others say thanks for this.


    • Ad Bot

      advertising
      Beep.

        
       

  2. #2
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: How the BSOD actually 'works', why, etc.

    Thanks Patrick. Keep up your good work ^_^

    Even though I do the analysis which is very low as compared to you :P, I see a greater share of WHEA_Uncorrectable_Error ; Driver_Power_State_Failure (With first parameter 3) & Kernel_Data_Inpage Error.

    These are the 3 current top bugchecks in my list.

    I remember when I was a kid, dad bought in this Windows 98 PC and it used to go BSOD sometimes after shifting to Windows XP and I was like praying to the gods that gods please don't screw up this PC and I was like what if dad learnt what happened to the pc :P


    But, now, yeah BSOD's are pretty friendly ^_^
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

  3. #3
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: How the BSOD actually 'works', why, etc.

    Just had a doubt in my mind, why is KeBugCheck called in the first place when it has to call only a single function i.e. KeBugCheckEX? The KeBugcheckEX only sets the four parameters to zero but that should be achievable using the KeBugCheckEX as well?
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

  4. #4

    Re: How the BSOD actually 'works', why, etc.

    KeBugCheck is not called by default, KeBugCheckEx is. KeBugCheck still exists though, it can be called if you choose to call it (although I am unsure as to why you would).
    LilBambi says thanks for this.

  5. #5
    jcgriff2's Avatar
    Join Date
    Feb 2012
    Location
    New Jersey Shore
    Posts
    15,563
    • specs System Specs
      • Manufacturer:
        HP
      • Model Number:
        HP ENVY TouchSmart 17-j130us Notebook - E8A04UA
      • Motherboard:
        HP Insyde 720265-501 6050A2549501-MB-A02
      • CPU:
        Intel Core i7-4700MQ Processor with Turbo Boost up to 3.4GHz.
      • Memory:
        12GB DDR3L SDRAM (2 DIMM)
      • Graphics:
        Intel HD graphics 4600 with up to 1792MB total graphics memory
      • Sound Card:
        Beats Audio quad speakers and two subwoofers
      • Hard Drives:
        1TB 5400RPM hard drive with HP ProtectSmart Hard Drive Protection
      • Disk Drives:
        Hitachi 500 GB SSD; 7 TB USB External
      • Power Supply:
        90w
      • Case:
        Laptop
      • Display:
        17.3-inch diagonal HD+ BrightView LED-backlit touchscreen display (1600 x 900)
      • Operating System:
        Windows 8.1

    Re: How the BSOD actually 'works', why, etc.

    Thanks, Patrick - great read.

    BSOD Posting Instructions - Windows 10, 8.1, 8, 7 & Vista ` ` `Carrona Driver Reference Table (DRT)
    https://www.sysnative.com/
    Sysnative Hex-Decimal-UNIX Date Conversion

    Has Sysnative Forums helped you?
    Please consider donating to help support the forum.
    Thank You!

    Microsoft MVP 2009-2015

  6. #6
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,749

    Re: How the BSOD actually 'works', why, etc.

    I prefer the original BSOD screens to the new overly-simplistic Windows 8 version.
    LilBambi says thanks for this.
    Machines Can Think

    Oxygen, Nature's paradox.

  7. #7

    Re: How the BSOD actually 'works', why, etc.

    I do as well.

    IMO it's better in practically every way as it gives you as basic 'why' it occurred, to contact your system admin/manufacturer, etc. The W8 one just says 'search it online'.

    I guess MS wanted to make the BSOD a lot less 'scarier' for the average home user.
    LilBambi says thanks for this.

  8. #8
    Jared's Avatar
    Join Date
    Feb 2014
    Age
    20
    Posts
    1,568
    • specs System Specs
      • Manufacturer:
        Custom
      • Motherboard:
        ASUS Maximus VII Ranger
      • CPU:
        i7 4790K @ 4.4GHz
      • Memory:
        Corsair Vengeance 16GB 1866MHz
      • Graphics:
        MSI Gaming 4G GTX 980
      • Sound Card:
        Creative Soundblaster ZxR
      • Hard Drives:
        Samsung 850 SSD 250GB
      • Disk Drives:
        Western Digital Black Caviar 2TB
      • Power Supply:
        Corsair RM650 Modular 650 Watts
      • Case:
        Fractal Design Define R5 Window
      • Cooling:
        Corsair H100i GTX
      • Display:
        Dell U2515H 25inch 2560x1440 + LG Flatron M2262D 22inch 1920x1080
      • Operating System:
        Windows 10 Professional x64

    Re: How the BSOD actually 'works', why, etc.

    I'm still scared of it

    But yes I prefer the Windows 7 one, I mean it would still be annoying if the Windows 8 one occurred, I don't see the reason really.

    It's more practical as sometimes dump files aren't created etc and a screenshot can help where as the Windows 8 one doesn't help much.
    LilBambi says thanks for this.

  9. #9

    Join Date
    Feb 2012
    Posts
    2,085
    Blog Entries
    7

    Re: How the BSOD actually 'works', why, etc.

    I just noticed this topic! Sweet! Fascinating info on how the calls are made!

    One question that I haven't been able to find the answer to: Where are the descriptions of the arguments/parameters found (prior to the crash)?

    A picture w/percentages of types of BSOD's in Win7/7 SP1 is in Windows Internals, 6th Edition, Part 2, page 551
    AFAIK - the numbers come from the automated reporting of BSOD's through WER
    Users don't always pay attention to this - and, sometimes, they refuse to let Microsoft collect info on this. So the numbers are skewed by the users.
    Also, people looking for help with BSOD's are generally a bit more technically able than others (even if they say they don't know anything about computers).
    Those who really don't know anything will just take their systems to a shop to have a BSOD fixed (and many techs will wipe a system to fix a BSOD).

    At one point I started researching how dump files were generated. The results are here: BSOD Crash Dump Generation
    Last updated: 02 May 2011

    As for the Win8 BSOD - it's not that bad. You just have to search the Symbolic Name rather than the STOP error code.
    The only problem that I've ever had with this was when I wanted to look at the arguments/parameters.
    But there's just not that many people that want to look at the parameters, and most of them likely know how to run a memory dump through the debugger in order to find it (and they'll get more use out of the debugger output than just the parameters)

    5 PHASES OF DUMP FILE GENERATION (Setup, user adjustment of settings, during the boot, during the crash, after the reboot):

    Phase 1 (Setup)
    The system obtains much of the initially required settings/entries automatically while Windows is installing - so you won't even know that this is going on. It's determined by the hardware on your system and how Windows interprets this information during setup. Unless you're an advanced user, there's very little opportunity for you to influence the factors involved in this phase.

    Phase 2 (User adjustments)
    Next is the opportunity for the user to modify settings. This not only includes the BSOD settings in Control Panel and in the registry, but also includes unrelated settings that amy affect the generation/collection of memory dumps. One such example is the settings used for the pagefile. There's a list of the registry settings at BSOD-related Registry Entries

    Phase 3 (During the boot - the one preceding the crash)
    Hal.dll and boot start drivers load before the pagefile is initialized - so a BSOD then can't save a memory dump (hence, live debugging is required to capture a memory dump)
    Creation of pagefile occurs during the Memory Manager initialization (part of the kernel initialization - I believe it's in Phase 1)
    At boot, the system checks the crash dump options in the Registry (HKLM\SYSTEM\CurrentControlSet\Control\CrashControl)
    If a dump is configured, it makes a copy of the disk miniport driver and appends "dump_" at the beginning of the filename
    System then checksums (and saves) the components involved in generating the memory dump. (dump_ miniport driver, I/O Manager functions that write the dump, and the map of where the boot volume's paging file is on disk).

    Phase 4 (The crash itself)
    When the KeBugCheck function executes, it checksums the components again.
    If they don't match, then no dump is written (to prevent data corruption)
    If they do match, then the dump is written directly to the sectors occupied by the pagefile. It bypasses the file system and storage driver stack (including the disk miniport driver) - using the dump_ copied driver instead.
    If a dedicated dump file is specified, then the crash dump driver (crashdump.sys) creates the dump file and it's required size and writes it to the dedicated dump file location (instead of the pagefile). If not enough space for a complete or kernel dump - the system falls back to writing a minidump.

    Phase 5 (After the reboot)
    For more detail, see Boot Process Troubleshooting page here: Boot Troubleshoot
    During the reboot, the Session Manager (SMSS.exe) enables paging (function NtCreatePagingFile)
    and the system then checks to see if there's a dump file (by calling function SmpCheckForCrashDump)
    If there is a dump file, that portion of the pagefile is protected (may result in low virtual memory error messages)
    During this time (Phase 0 of kernel initialization - generally before Windows Splash Screen shows up), Driver Verifier is enabled and then Kernel Debugger is attached (if used). Initialization is finished later on (see Boot Troubleshoot )
    If the target dump file is located on another drive, then the system (winlogon.exe calling savedump.exe) renames the pagefile to Dumpxxx.tmp (from pg 1130 of Windows Internals 5th Edition) and truncates the size to the size of the dump data (stored in the header of the dump file). Removes Hidden and System attributes from the file
    Creates volatile Registry key: HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash
    Stores temporary dump file name in the value "DumpFile". Writes REG_DWORD to "TempDestination" value indicating if it's a temporary destination or not (0x0 = not temp; 0x1 = temp)
    NOTE: If the pagefile is on the same volume as the final memory dump location - then no temporary file is used and TempDestination value is set to 0x0
    Later on wininit.exe checks for the MachineCrash key. If found, Wininit.exe launches WerFault.exe -k -c (k=kernel report; c=convert to minidump) which either renames or copies the temporary file to the final location
    WerFault then writes the final dump name to the MachineCrash\FinalDumpFileLocation value



    Ya gotta wonder when and how the MachineCrash key is deleted
    The Microsoft Bug Check Reference (located here: Bug Check Code Reference (Windows Debuggers) ) is incomplete.
    Scrolling down the list will show many missing bug checks
    A more comprehensive listing is in the bugcodes.h file (I think it's from the WDK - I haven't researched it since 8.1 came out). I maintain a copy of it here: bugcodes.h v8.1
    Finally, there's even more BSOD error codes than this. At last count I'd documented over 406 BSOD error codes here: BSOD Index
    Last edited by usasma; 07-02-2014 at 05:39 PM.
    zigzag3143, LilBambi, Jared and 4 others say thanks for this.

  10. #10
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: How the BSOD actually 'works', why, etc.

    I had a question in mind that does every time a Blue Screen occurs, the KeBugCheck() function is called. But, is it necessary that it must be present in the stack as well? Asking because just encountered a dump file where there is only 2 lines both stating the Intel Rapid Storage Driver as the only call. The KeBugCheck() is nowhere to be seen. So, could anyone please explain this?

    Also, how come that after every one week or so, the people having BSOD problems are generally having the same set of software and driver versions like acronis(Just example)? Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?


    @Usasma :- there is a typo in the Phase 2 "amy" must be "may" .
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

  11. #11

    Re: How the BSOD actually 'works', why, etc.

    Can you PM me the dump? I'll take a look post the findings here.

    Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?
    I haven't seen it in a few weeks either. Either OEM's are finally cleaning up their act and releasing fixed versions of the driver, or people just haven't been installing it. Time will tell.
    LilBambi and Jared say thanks for this.

  12. #12
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: How the BSOD actually 'works', why, etc.

    Quote Originally Posted by Patrick View Post
    Can you PM me the dump? I'll take a look post the findings here.

    Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?
    I haven't seen it in a few weeks either. Either OEM's are finally cleaning up their act and releasing fixed versions of the driver, or people just haven't been installing it. Time will tell.
    Dumps PMed. Furthermore, can anyone shed light on this one that whether calling KeBugCheck() is possible by creating a simple Win 32 Application?
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

  13. #13
    niemiro's Avatar
    Join Date
    Mar 2012
    Location
    District 12
    Posts
    7,787

    Re: How the BSOD actually 'works', why, etc.

    Quote Originally Posted by blueelvis View Post
    Furthermore, can anyone shed light on this one that whether calling KeBugCheck() is possible by creating a simple Win 32 Application?
    It is not possible. There are two ways of attempting to load a a binary (and subsequently call a function) from usermode code (load time dynamic linking or run time dynamic linking), but neither will work.

    If you try to use LoadLibrary & GetProcAddress on ntoskrnl.exe & KeBugCheck respectively, you'll just get errors. If you try to include ntddk.h import library into a Win32 C++ app, it won't compile. There will be for starters a conflict between the Win32 CRT and the WinDDK CRT headers. So you perhaps take out the Win32 CRT headers to avoid that conflict. It still won't compile though. So you make some further tweaks here and there, and eventually you get it to compile. Great! But you know what? - you'll now have actually coded a driver. All those changes you made in order to get it to compile will have changed your project into a driver project. Oh yes, you started out with a Win32 project, but that's not what you've got now.

    So to answer your question, no, it cannot be called from Usermade. The closest you can get is to write a kernel mode device driver which exposes a usermode version of KeBugCheck and call that from usermode. Precisely what the SysInternals tool does (the name's slipped my mind! That one which causes BSODs...)
    LilBambi and blueelvis say thanks for this.

  14. #14
    Jared's Avatar
    Join Date
    Feb 2014
    Age
    20
    Posts
    1,568
    • specs System Specs
      • Manufacturer:
        Custom
      • Motherboard:
        ASUS Maximus VII Ranger
      • CPU:
        i7 4790K @ 4.4GHz
      • Memory:
        Corsair Vengeance 16GB 1866MHz
      • Graphics:
        MSI Gaming 4G GTX 980
      • Sound Card:
        Creative Soundblaster ZxR
      • Hard Drives:
        Samsung 850 SSD 250GB
      • Disk Drives:
        Western Digital Black Caviar 2TB
      • Power Supply:
        Corsair RM650 Modular 650 Watts
      • Case:
        Fractal Design Define R5 Window
      • Cooling:
        Corsair H100i GTX
      • Display:
        Dell U2515H 25inch 2560x1440 + LG Flatron M2262D 22inch 1920x1080
      • Operating System:
        Windows 10 Professional x64

    Re: How the BSOD actually 'works', why, etc.

    Very good Richard :)

    I believe the application you're thinking of is NotMyFault.
    niemiro and LilBambi say thanks for this.

  15. #15
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: How the BSOD actually 'works', why, etc.

    Thank you very much Richard for explaining it this clearly and deeply ^_^.
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

  16. #16

    Join Date
    Apr 2013
    Posts
    30

    Re: How the BSOD actually 'works', why, etc.

    Quote Originally Posted by blueelvis View Post
    Quote Originally Posted by Patrick View Post
    Can you PM me the dump? I'll take a look post the findings here.

    Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?
    I haven't seen it in a few weeks either. Either OEM's are finally cleaning up their act and releasing fixed versions of the driver, or people just haven't been installing it. Time will tell.
    Dumps PMed. Furthermore, can anyone shed light on this one that whether calling KeBugCheck() is possible by creating a simple Win 32 Application?
    NtRaiseHardError is the user mode BSOD function.

    The function shows a blue screen if the ResponseOption parameter is OptionShutdownSystem (6). The application must first enable SeShutdownPrivilege.
    niemiro, Patrick and LilBambi say thanks for this.

  17. #17
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: How the BSOD actually 'works', why, etc.

    Furthermore, if one is interested, I found this in the WinDBG manual :-


    Forcing a System Crash from the Keyboard

    Most of the following keyboards can cause a system crash directly:
    PS/2 keyboards connected on i8042prt ports This feature is available in Windows 2000 and later versions of Windows operating system.
    USB keyboards This feature is available in:

    • Windows Server 2003 Service Pack 1 if the hotfix available with KB 244139 is installed.

    • Windows Server 2003 (with Service Pack 2 or later).
    • Windows Vista Service Pack 1 if the hotfix available with KB 971284 is installed.
    • Windows Vista Service Pack 2.
    • Windows Server 2008 Service Pack 1 if the hotfix available with KB 971284 is installed.
    • Windows Server 2008 (with Service Pack 2 or later).
    • Windows 7 and later versions of Windows operating system.

    Note This feature is not available in Windows XP.
    You must ensure the following three settings before the keyboard can cause a system crash:

    1. If you wish a crash dump file to be written, you must enable such dump files, choose the path and file name, and select the size of the dump file. For more information, see Enabling a Kernel-Mode Dump File.
    2. With PS/2 keyboards, you must enable the keyboard-initiated crash in the registry. In the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters, create a value named CrashOnCtrlScroll, and set it equal to a REG_DWORD value of 0x01.
    3. With USB keyboards, you must enable the keyboard-initiated crash in the registry. In the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\Parameters, create a value named CrashOnCtrlScroll, and set it equal to a REG_DWORD value of 0x01.

    You must restart the system for these settings to take effect.
    After this is completed, the keyboard crash can be initiated by using the following hotkey sequence: Hold down the rightmost CTRL key, and press the SCROLL LOCK key twice.
    The system then calls KeBugCheck and issues bug check 0xE2 (MANUALLY_INITIATED_CRASH). Unless crash dumps have been disabled, a crash dump file is written at this point.
    If a kernel debugger is attached to the crashed machine, the machine will break into the kernel debugger after the crash dump file has been written.
    For more information on using this feature, refer to the article Generate a memory dump file by using the keyboard (KB 244139).
    Defining Alternate Keyboard Shortcuts to Force a System Crash from the Keyboard

    You can configure values under the following registry subkeys for different keyboard shortcut sequences to generate the memory dump file:

    • For PS/2 keyboards:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\crashdump
    • For USB keyboards:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\crashdump

    You must create the following registry REG_DWORD values under these subkeys:
    Dump1Keys The Dump1Keys registry value is a bit map of the first hot key to use. For example, instead of using the rightmost CTRL key to initiate the hot key sequence, you can set the first hot key to be the leftmost SHIFT key.
    The values for the first hot key are described in the following table.
    Value First key used in the keyboard shortcut sequence
    0x01 Rightmost SHIFT key
    0x02 Rightmost CTRL key
    0x04 Rightmost ALT key
    0x10 Leftmost SHIFT key
    0x20 Leftmost CTRL key
    0x40 Leftmost ALT key

    Note You can assign Dump1Keys a value that enables one or more keys as the first key used in the keyboard shortcut sequence. For example, assign Dump1Keys a value of 0x11 to define both the rightmost and leftmost SHIFT keys as the first key in the keyboard shortcut sequence.
    Dump2Key The Dump2Key registry value is the index into the scancode table for the keyboard layout of the target computer. The following is the actual table in the driver.
    const UCHAR keyToScanTbl[134] = {
    0x00,0x29,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,
    0x0A,0x0B,0x0C,0x0D,0x7D,0x0E,0x0F,0x10,0x11,0x12,
    0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x00,
    0x3A,0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,
    0x27,0x28,0x2B,0x1C,0x2A,0x00,0x2C,0x2D,0x2E,0x2F,
    0x30,0x31,0x32,0x33,0x34,0x35,0x73,0x36,0x1D,0x00,
    0x38,0x39,0xB8,0x00,0x9D,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0xD2,0xD3,0x00,0x00,0xCB,
    0xC7,0xCF,0x00,0xC8,0xD0,0xC9,0xD1,0x00,0x00,0xCD,
    0x45,0x47,0x4B,0x4F,0x00,0xB5,0x48,0x4C,0x50,0x52,
    0x37,0x49,0x4D,0x51,0x53,0x4A,0x4E,0x00,0x9C,0x00,
    0x01,0x00,0x3B,0x3C,0x3D,0x3E,0x3F,0x40,0x41,0x42,
    0x43,0x44,0x57,0x58,0x00,0x46,0x00,0x00,0x00,0x00,
    0x00,0x7B,0x79,0x70 };

    Note Index 124 (sysreq) is a special case because an 84-key keyboard has a different scan code.
    If you define alternate keyboard shortcuts to force a system crash from a USB or PS/2 keyboard, you must either set the CrashOnCtrlScroll registry value to 0 or remove it from the registry.
    Limitations

    It is possible for a system to freeze in such a way that the keyboard shortcut sequence will not work. However, this should be a very rare occurrence. Using the keyboard shortcut sequence to initiate a crash will work even in many instances where CTRL+ALT+DELETE does not work.
    Forcing a system crash from the keyboard does not work if the computer stops responding at a high interrupt request level (IRQL). This limitation exists because the Kbdhid.sys driver, which allows the memory dump process to run, operates at a lower IRQL than the i8042prt.sys driver.

    LilBambi says thanks for this.
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

  18. #18
    LilBambi's Avatar
    Join Date
    Apr 2012
    Location
    Virgina, USA
    Posts
    292

    Re: How the BSOD actually 'works', why, etc.

    Great read Patrick and responses all around.

    I have to admit that on my own computers long before I learned a bit more, I used to just feel like pulling my hair out when a BSOD happened and grind my teeth and spew things I do not generally say (under my breath if others present, or aloud if alone). I did not think of a BSOD as a friend.

    It has become more of a friend of late, and more so with reads like Patrick's et al here on Sysnative!

    You all are great!
    Bambi
    If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology. Bruce Schneier

  19. #19

    Re: How the BSOD actually 'works', why, etc.

    Sorry, it took me a bit to get around to the dumps that were PM'd to me. I see the crashes you're talking about:

    Code:
    6: kd> k
    Child-SP          RetAddr           Call Site
    ffffd000`edf54918 fffff800`05b508bc iaStorA+0x5e7b7
    ffffd000`edf54920 00000000`00000000 iaStorA+0x5e8bc
    Only the IRST driver (twice) is in the stack. No error reporting, etc. Note this:

    Code:
    Mini Kernel Dump File: Only registers and stack trace are available
    So as we know with a minidump you can really only take a look at 'what literally happened at the time of the crash'. My guess is in all of these crashes, we're simply going off the rails once the violation occurs in the driver. I bet if we had a kernel-dump of these exact crashes, we'd likely see the error handling, etc, in the stack.

    Code:
    0: kd> .exr 0xffffd0002090d6d8
    ExceptionAddress: fffff80119b317b7 (iaStorA+0x000000000005e7b7)
       ExceptionCode: c0000005 (Access violation)
    Why did this violation happen?

    Code:
    mov     r8d,dword ptr [rax]
    You can see with the instruction we failed on, it was moving a pointer that was stored in the rax register. Okay, let's take a look at rax:

    Code:
    0: kd> r
    rax=0000000000000000 rbx=ffffe001e1400008 rcx=ffffe001e1400008
    rdx=00000000002b8b3f rsi=0000000000000000 rdi=00000000002b8b3f
    rip=fffff80119b317b7 rsp=ffffd0002090d918 rbp=00000000002b8b3f
     r8=00000000001ae450  r9=0000000000000001 r10=00000000000000ff
    r11=0000000000000000 r12=0000000002b8b3f8 r13=ffffe001e1400008
    r14=00000000002d3984 r15=0000000000000000
    iopl=0         nv up ei pl zr na po nc
    cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
    We can see rax is null. Great, so we know why the violation occurred, which was because rax was null. What does all of this mean?

    Code:
    DEFAULT_BUCKET_ID:  NULL_DEREFERENCE
    Ding ding! We dereferened a null pointer (rax) when in this case we wanted to point to a valid memory area. As usual, this is a problem with the IRST driver.



    Great read Patrick and responses all around.
    Glad you enjoyed it! Indeed, this is one of the many reasons Sysnative is my favorite community. The discussions and teaching never end! I learn something new every day.
    Last edited by Patrick; 07-07-2014 at 07:30 PM.
    LilBambi says thanks for this.

  20. #20
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,749

    Re: How the BSOD actually 'works', why, etc.

    It's always helpful to have a little programming knowledge in a language like C or C++, some of the errors will make more sense if you know how pointers work and error handling works etc.
    LilBambi says thanks for this.
    Machines Can Think

    Oxygen, Nature's paradox.

Similar Threads

  1. Replies: 0
    Last Post: 08-17-2012, 05:41 AM
  2. Replies: 0
    Last Post: 08-14-2012, 09:47 PM
  3. Replies: 0
    Last Post: 07-23-2012, 04:11 PM
  4. Report: Universal Stylus in the Works at Microsoft
    By zigzag3143 in forum Microsoft News
    Replies: 0
    Last Post: 07-21-2012, 03:23 AM

Log in

Log in