MACHINE_CHECK_EXCEPTION - Bluescreen Code: 9c?..

Page 2 of 2 FirstFirst 12

  1. Posts : 9
    Windows 10
    Thread Starter
       #11

    axe0 said:
    Do the crashes continue in safe mode?
    The most reliable way to reproduce them was to load up Tabletop Simulator with a lot of downloaded mod content. It doesn't seem to work in Safe Mode (something about not loading the images and .json files and whatnot), so it's a bit hard to say. Is there some specific testing I should run in Safe Mode to find out?

    Edit: but I did load up Tabletop Simulator without any content and let it sit around for a while. Didn't cause any crashes.

    Edit 2: back to Windows 10, loaded up Tabletop Simulator with some content, alt-tabbed out of it an immediately hit the BSOD. Minidump attached.
    Since it's so highly reproducible, is there a way to run some kind of logger that just writes down the last actions that the machine performed that may have led to the BSOD? Or is that complicated? Or is that already what the Minidump does?..
    MACHINE_CHECK_EXCEPTION - Bluescreen Code: 9c?.. Attached Files
      My Computer

  2. axe0's Avatar
    Posts : 14,628
    Windows 10 Pro
       #12

    The BSOD process is precisely doing what you want. Internally Windows keeps track of various things in the memory and relevant portions of it is stored in the dump.

    Let's look at this from a different perspective, please run driver verifier using the following settings for 48 hours.
    • Special Pool
    • Force IRQL checking
    • Pool Tracking
    • Deadlock Detection
    • Security Checks
    • Miscellaneous Checks
    • Power framework delay fuzzing
    • DDI compliance checking



    Warning: driver verifier could cause boot issues and/or performance issues.



    Resetting driver verifier options (recommended in this order)
    1. In normal mode open an administrator command prompt and enter the below command
    2. In safe mode open an administrator command prompt and enter the below command
    3. On 3 boot failures, you'll boot automatically to the recovery options,
      • click Troubleshoot
      • go to the advanced options
      • choose command prompt
      • enter the below command

    4. Boot with the recovery media, see above 4 steps in option 3.
    5. Via the recovery options or recovery media, select a restore point prior enabling driver verifier

    Code:
    verifier /reset


    Crashed when running driver verifier
    1. Reset driver verifier
    2. Boot in normal mode if necessary
    3. Follow Blue Screen of Death (BSOD) Posting Instructions to provide the requested logs




    Extra information about driver verifier
    When you run driver verifier, there are two things you're looking out for
    1. Driver verifier won't find any driver violating something and thus in the time you need to run it there won't be a crash
    2. Driver verifier will find a driver violating something and thus the system will crash.

    The end result of driver verifier is either of the two, but when driver verifier finds something your system will BSOD.


    Driver verifier essentially validates selected drivers on selected actions, this validation adds some delay to actions performed in the background which results in a performance decrease that many people notice. This is called stress testing drivers and depending on quite a few factors this performance decrease is worse for some than for others, and some won't even notice a difference.

    Depending on the drivers selected, it is possible that some of the selected drivers are so-called 'boot' drivers, meaning they load when your system is booting. If these drivers don't pass a validation check, your system will crash, but since the drivers are loading at boot, your system will basically be in a boot loop. That is one of the risks involved and the most important one. Of course, there are various methods to recover from it.

    If you want visual confirmation that driver verifier is actually running, copy/paste the following command in powershell or command prompt
    Code:
    verifier /query
    If the command gives a result similar to this, it means driver verifier is running.
      My Computers


  3. Posts : 9
    Windows 10
    Thread Starter
       #13

    axe0 said:
    The BSOD process is precisely doing what you want. Internally Windows keeps track of various things in the memory and relevant portions of it is stored in the dump.
    Let's look at this from a different perspective, please run driver verifier using the following settings for 48 hours.
    Great, thanks. Just to clarify for my noobish self - am I supposed to leave the PC alone for 48 hours when running it? or should I just use it and even reproduce a crash with that game?

    By the way, ran memtest86 for a couple passes (free version allows 4, so I ran that twice) - no problems. However, Windows randomly BSODed on its login screen just now. Go figure. Could it possibly be a crappy PSU causing spikes and whatnot? But then it would be more unstable during other gaming...

    - - - Updated - - -

    axe0 said:
    Let's look at this from a different perspective, please run driver verifier using the following settings for 48 hours.
    Well if we were looking for the first possible BSOD, I ran it twice with the above settings and got two BSODs (first time wasn't sure if it just went to sleep causing the crash).
    Logs are attached (8 PM first one 11PM second one). The Reliability monitor mentions Intel both times, but I did install the chipset drivers from the manufacturer's website.

    Thank you again for taking the time. Hope this helps others as well, though it might be a bit of a rare case...
    MACHINE_CHECK_EXCEPTION - Bluescreen Code: 9c?.. Attached Files
      My Computer

  4. axe0's Avatar
    Posts : 14,628
    Windows 10 Pro
       #14

    Using driver verifier, use your pc as you normally would. Verifier is only able to verify drivers if drivers are actually running which requires from you that you use the computer.

    MisterV said:
    Could it possibly be a crappy PSU causing spikes and whatnot? But then it would be more unstable during other gaming.
    It's possible, but testing a PSU is quite difficult and if something's wrong with the PSU the results may not be even close to what you expect.


    Since I finally have some time, I've had a better look at some 0x9C to see if they could tell us something more.
    Code:
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    MACHINE_CHECK_EXCEPTION (9c)
    A fatal Machine Check Exception has occurred.
    KeBugCheckEx parameters;
        x86 Processors
            If the processor has ONLY MCE feature available (For example Intel
            Pentium), the parameters are:
            1 - Low  32 bits of P5_MC_TYPE MSR
            2 - Address of MCA_EXCEPTION structure
            3 - High 32 bits of P5_MC_ADDR MSR
            4 - Low  32 bits of P5_MC_ADDR MSR
            If the processor also has MCA feature available (For example Intel
            Pentium Pro), the parameters are:
            1 - Bank number
            2 - Address of MCA_EXCEPTION structure
            3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
            4 - Low  32 bits of MCi_STATUS MSR for the MCA bank that had the error
        IA64 Processors
            1 - Bugcheck Type
                1 - MCA_ASSERT
                2 - MCA_GET_STATEINFO
                    SAL returned an error for SAL_GET_STATEINFO while processing MCA.
                3 - MCA_CLEAR_STATEINFO
                    SAL returned an error for SAL_CLEAR_STATEINFO while processing MCA.
                4 - MCA_FATAL
                    FW reported a fatal MCA.
                5 - MCA_NONFATAL
                    SAL reported a recoverable MCA and we don't support currently
                    support recovery or SAL generated an MCA and then couldn't
                    produce an error record.
                0xB - INIT_ASSERT
                0xC - INIT_GET_STATEINFO
                      SAL returned an error for SAL_GET_STATEINFO while processing INIT event.
                0xD - INIT_CLEAR_STATEINFO
                      SAL returned an error for SAL_CLEAR_STATEINFO while processing INIT event.
                0xE - INIT_FATAL
                      Not used.
            2 - Address of log
            3 - Size of log
            4 - Error code in the case of x_GET_STATEINFO or x_CLEAR_STATEINFO
        AMD64 Processors
            1 - Bank number
            2 - Address of MCA_EXCEPTION structure
            3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
            4 - Low  32 bits of MCi_STATUS MSR for the MCA bank that had the error
    Arguments:
    Arg1: 0000000080000001
    Arg2: fffff8025c697b10
    Arg3: 0000000000000000
    Arg4: 0000000000000000
    
    0: kd> dt _MCA_EXCEPTION fffff8025c697b10
    *************************************************************************
    ***                                                                   ***
    ***                                                                   ***
    ***    Either you specified an unqualified symbol, or your debugger   ***
    ***    doesn't have full symbol information.  Unqualified symbol      ***
    ***    resolution is turned off by default. Please either specify a   ***
    ***    fully qualified symbol module!symbolname, or enable resolution ***
    ***    of unqualified symbols by typing ".symopt- 100". Note that     ***
    ***    enabling unqualified symbol resolution with network symbol     ***
    ***    server shares in the symbol path may cause the debugger to     ***
    ***    appear to hang for long periods of time when an incorrect      ***
    ***    symbol name is typed or the network symbol server is down.     ***
    ***                                                                   ***
    ***    For some commands to work properly, your symbol path           ***
    ***    must point to .pdb files that have full type information.      ***
    ***                                                                   ***
    ***    Certain .pdb files (such as the public OS symbols) do not      ***
    ***    contain the required information.  Contact the group that      ***
    ***    provided you with these symbols if you need this command to    ***
    ***    work.                                                          ***
    ***                                                                   ***
    ***    Type referenced: _MCA_EXCEPTION                                ***
    ***                                                                   ***
    *************************************************************************
    Symbol _MCA_EXCEPTION not found.
    
    0: kd> dt _MCi_STATUS fffff8025c697b10
    nt!_MCI_STATUS
       +0x000 CommonBits       : _MCI_STATUS_BITS_COMMON
       +0x000 AmdBits          : _MCI_STATUS_AMD_BITS
       +0x000 IntelBits        : _MCI_STATUS_INTEL_BITS
       +0x000 QuadPart         : 1
    
    0: kd> dt _MCI_STATUS_BITS_COMMON 0xfffff8005e097b10
    nt!_MCI_STATUS_BITS_COMMON
       +0x000 McaErrorCode     : 0y0000000000000001 (0x1)
       +0x000 ModelErrorCode   : 0y0000000000000000 (0)
       +0x000 Reserved         : 0y0000000000000000000000000 (0)
       +0x000 ContextCorrupt   : 0y0
       +0x000 AddressValid     : 0y0
       +0x000 MiscValid        : 0y0
       +0x000 ErrorEnabled     : 0y0
       +0x000 UncorrectedError : 0y0
       +0x000 StatusOverFlow   : 0y0
       +0x000 Valid            : 0y0
    The interesting field in the _MCI_STATUS_BITS_COMMON structs is McaErrorCode which gives an indication as to what the MCE reported for why things crashed. Unfortunately, McaErrrorCode reports 1 which is equivalent to the fact that the error has not been classified into the MCA error classes, the error is unknown.

    I am still looking into the 0x109, one of the parameters is not what Windbg says it is and I'm trying to figure out what it is.


    I notice, around the time of crashes it usually happens that dump file creation failure occurs. Meaning a kernel dump could not be generated, but fortunately, there were no issues with a minidump. I reread your first post in this thread since sometimes things are overseen/forgotten, and noticed
    mdsched did not pass, but I could not find any references to the resulting code and the internet said the results are unreliable anyway.
    While it is true that mdsched isn't amazing, when mdsched does find problems I like to investigate them. For some reason when I help someone and mdsched is used, as well as other memory tests, mdsched sometimes finds real problems that other tests didn't find. As such I would like to know if you have spare memory modules that are known to be good that you could use for testing.
      My Computers


  5. Posts : 9
    Windows 10
    Thread Starter
       #15

    Great, so I have the PC equivalent of a rare disorder or what?.. Jokes aside, I was going to say yes, but then realised that no, my old DDR3 1666 is not compatible with this mobo. I mean I could try to get some used RAM to test, but unfortunately I'm in a situation where none of my old gamer buddies are around who could loan me some hardware. Back when I lived in the Netherlands by the way, that would've been easy...

    What I could do is first try to take the RAM out, blow on the slots to clean, switch slots and test, then maybe try testing with only one stick and then the other one?..

    By the way. Those two crashes I attached to my previous post happened without me using the PC at all. I just let it stand.
      My Computer

  6. axe0's Avatar
    Posts : 14,628
    Windows 10 Pro
       #16

    MisterV said:
    What I could do is first try to take the RAM out, blow on the slots to clean, switch slots and test, then maybe try testing with only one stick and then the other one?..
    Certainly something you could try, just be careful not to damage anything.
      My Computers


  7. axe0's Avatar
    Posts : 14,628
    Windows 10 Pro
       #17

    Hi MisterV,

    How is it going with the RAM tests?
      My Computers


  8. Posts : 9
    Windows 10
    Thread Starter
       #18

    axe0 said:
    Hi MisterV,

    How is it going with the RAM tests?
    Hey, sorry, couldn't do anything because of work and a friend staying in the room where my computer is, temporarily. Can do something next week.

    My plan would be as follows:
    1) As is, start the driver verifier and go directly to Tabletop Simulator (= reproducible crash) to post the minidump here when it crashes;
    2) take out both RAM sticks, blow, switch slots, put them back in, see if any crashes occur, post;
    3) take out one of them and do the same, then the other.

    Anything else that I could do or that you could discover from the dump files?
      My Computer

  9. axe0's Avatar
    Posts : 14,628
    Windows 10 Pro
       #19

    Right now I'm waiting for the test results.
      My Computers


 

Related Threads
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

Designer Media Ltd
All times are GMT -5. The time now is 15:35.
Find Us




Windows 10 Forums