WinDBG - The Basics for Debugging Crash Dumps in Windows 10  

Page 1 of 5 123 ... LastLast
    WinDBG - The Basics for Debugging Crash Dumps in Windows 10

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10

    Basic WinDBG methods for debugging crash dumps in Windows 10
    Published by Category: BSOD
    09 Oct 2015
    Designer Media Ltd

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10

    information   Information
    WinDBG (Windows DeBuGger) is an analytic tool used for analysing and debugging Windows crash dumps, also known as BSODs (Blue Screens of Death). It is part of the Windows Developer Kit which is a free download from Microsoft and is used by the vast majority of debuggers, including here on Ten Forums.

    Note   Note
    The tutorial below outlines the basic instructions when analysing dump files, it is by no means a complete and definitive guide. This tutorial will show you how to look for problematic drivers and highlights a few other common basic issues that arise when debugging. There are many commands to master within WinDBG and many different methods to use for different STOP codes which aren't covered in this tutorial. Mastering WinDBG and becoming proficient in debugging crash dumps take a lot of time and dedication, it is certainly not a quick process but can be highly rewarding once dumps start to make more sense.


     Table of Contents

    Part One: WinDBG Installation and Configuration
    Part Two: Opening BSOD Logs
    Part Three: The Dump File and Basic Analysis
    Part Four: Common Bugchecks and Plans of Attack
    Part Five: SCSI Pass-Thru Direct (SPTD)
    Part Six: Recommended Research Materials


     WinDBG Installation and Configuration

    To install and configure WinDBG follow WinDBG - Install Configure - Windows 10 Forums for full instructions.


     Opening BSOD Logs

    Step One: 7Zip and Opening Dump Files
    Step Two: The WinDBG Interface


    7Zip and Opening Dump Files

    information   Information
    Dump files are saved with the .dmp file extension and are identified by the icon below.
    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg_icon.gif
    Small memory dump files (most commonly used for analysing BSODs) are saved locally to %SystemRoot%\Minidump.

    For information on configuring which dump files Windows creates see Dump Files - Configure Windows 10 to Create on BSOD.

    A) When a log file is downloaded from Ten Forums it will be in the form of a .zip file. The easiest way to access the contents is using 7Zip, a free open source file compression tool. Once 7Zip is installed download an uploaded log file from a thread in BSOD Crashes and Debugging - Windows 10 Forums and open the saved destination folder. Logs can appear as ZIP Files or WinRAR Archives (see image below).

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-dumps-folder.jpg

    B) Right click on the log you wish to examine, hover over 7Zip in the context menu and click/tap on Open archive

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-7zip-context-menu.jpg

    C) Once the archive is opened you'll see the dump files located at the top of the archive. The number of dump files present will vary from archive to archive and is completely dependent on how many BSODs the user has received.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-opened-archive.jpg

    Tip   Tip
    Always open dumps from the most recent date backwards, opening older dumps first can give you a false picture of what the current issue actually is. Note the date of the dump files too, dumps that are many months old may no longer be relevant.

    D) On occasion you will encounter an archive that contains no dump files. This usually means that the user's Windows configuration is not set to create dump files on BSOD, refer the user to Dump Files - Configure Windows 10 to Create on BSOD to ensure the machine creates dump files on subsequent BSODs. The user will have to upload new logs once new BSODs have been encountered to capture the new dump files.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-opened-archive-no-dumps.jpg

    Double click/tap on the most recent dump which will open in WinDBG provided it has been configured correctly.


    The WinDBG Interface

    When you open your first dump file you will be greeted with a window like the one below.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-opened-dump.png

    It's worth noting that the dump readout window (highlighted in the screenshot above) is separate to the WinDBG window. It can be moved around and/or resized (by dragging the corner of the window) within the WinDBG window. Manipulate the dump readout window to the size that suits your personal preference, giving yourself a bigger workspace can make for easier reading.

    EXAMPLE: Dump window manually resized for larger viewing area:

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-full-screen.jpg

    The dump file will take a few seconds to load as it connects to the internet and downloads the required symbols to display in the readout. You will see the message Debugee not connected in the command bar while the symbols are downloaded. You can not work on the dump file until all of the relevant symbols are downloaded.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-debugee-not-connected-cropped.jpg

    Once the symbols have been downloaded and the dump is ready to analyse you will see the message Followup: MachineOwner at the bottom of the dump text.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-followup-machineowner.jpg

    At this point you're ready to start analysing the dump file. All commands are entered into the command bar at the bottom of the dump window.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-command-bar.jpg


     The Dump File and Basic Analysis

    Step One: Bugchecks At a Glance
    Step Two: !thread and Driver Analysis
    Step Three: !analyze-v and !irp


    Bugchecks At a Glance

    Bugchecks are always presented in the form of a STOP followed by a hexadecimal number, the hexadecimal value always being 0xXXXXXXXX. The hexadecimal code defines the type of bugcheck. Bugchecks can be referred to in the following ways:


    STOP: 0x0000000A


    All of these methods equate to the same bugcheck. For the remainder of this tutorial bugchecks will be referred to in the shorthand format (0xA).

    The first thing you need to note when opening a dump file is the Bugcheck code, this will largely define the underlying issue that caused the crash. To identify a Bugcheck code refer to the Windows Dev Center Bug Check Code Reference. In the example below we'll be dealing with a 0x9F.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-1.jpg

    Having consulted the Bug Check Code Reference you will learn that a 0x9F is a DRIVER_POWER_STATE_FAILURE. This is addressed later in this tutorial.


    !thread and Driver Analysis

    One common cause of BSODs is third party device drivers. To see if a device driver has been named in the crash dump you will need to dump the stack, follow the steps below to perform the procedure and see which drivers, if any, have been named in the stack.

    1: In the command bar type in !thread and hit enter, this will display the information from the active thread at the time of the crash.

    2: Scan through the thread until you find the Base and Limit texts and their hexadecimal outputs.

    Base fffff80000b9b000 Limit fffff80000b95000
    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-2.jpg

    In the command bar type dps followed by the Limit value first and the Base value second, it is important to input the values in the correct order. Hit enter to dump the stack.

    dps fffff80000b95000 fffff80000b9b000
    Tip   Tip
    You cannot right click and copy within the WinDBG window. Select the text required by highlighting with the mouse and using CTRL+C, then paste the text into the command bar using CTRL+V.

    3: When the stack has been dumped you will see a wall of hexadecimal text, a small example is outlined in the code below:

    fffff800`00b9a590  fffffa80`0e746d08
    fffff800`00b9a598  fffff880`0f00b768 dxgmms1!VidSchiFreeQueuePacket+0xa4
    fffff800`00b9a5a0  fffffa80`11854848
    fffff800`00b9a5a8  fffffa80`0e7c17a8
    fffff800`00b9a5b0  00000000`00000000
    fffff800`00b9a5b8  fffffa80`0e746d18
    fffff800`00b9a5c0  00000000`00000000
    fffff800`00b9a5c8  fffffa80`0e7c17a8
    fffff800`00b9a5d0  00000000`00000002
    fffff800`00b9a5d8  fffffa80`0e746b10
    fffff800`00b9a5e0  fffffa80`0e7c1010
    fffff800`00b9a5e8  fffff880`0f00a382 dxgmms1!VidSchiProcessCompletedQueuePacketInternal+0x44e
    fffff800`00b9a5f0  fffffa80`11854840
    fffff800`00b9a5f8  fffffa80`0e7428b0
    fffff800`00b9a600  fffffa80`11854840
    fffff800`00b9a608  fffffa80`0e7ca000
    fffff800`00b9a610  00000000`00000000
    fffff800`00b9a618  fffffa80`11854840
    fffff800`00b9a620  00000000`00000000
    fffff800`00b9a628  00000000`00000000
    fffff800`00b9a630  fffffa80`0e7c1690
    fffff800`00b9a638  fffff800`03288dd6 nt!KeSetEvent+0x106
    fffff800`00b9a640  fffffa80`0e7c1010
    fffff800`00b9a648  00000000`00000000
    fffff800`00b9a650  fffffa80`0e7c17a0
    fffff800`00b9a658  fffff880`0f00c48b dxgmms1!VidSchiSignalRegisteredEvent+0xe7
    fffff800`00b9a660  fffff800`00000001
    fffff800`00b9a668  00000000`00000001
    fffff800`00b9a670  00000000`00000000
    fffff800`00b9a678  fffffa80`0e7428b0
    fffff800`00b9a680  fffffa80`0e7c1010
    fffff800`00b9a688  fffffa80`0e7ca000
    fffff800`00b9a690  00000000`00000000
    fffff800`00b9a698  fffffa80`0e746b10
    fffff800`00b9a6a0  fffffa80`0e7cb340
    fffff800`00b9a6a8  fffff880`0f0097e6 dxgmms1!VidSchiProcessDpcCompletedPacket+0x3b6
    fffff800`00b9a6b0  fffffa80`00000000
    fffff800`00b9a6b8  fffffa80`00000000
    fffff800`00b9a6c0  00000000`00000002
    fffff800`00b9a6c8  00000000`00000000
    fffff800`00b9a6d0  00000000`00000000
    fffff800`00b9a6d8  00000000`00000000
    fffff800`00b9a6e0  00000000`0000000a
    fffff800`00b9a6e8  fffffa80`0e7cb350
    fffff800`00b9a6f0  fffffa80`0e7cb350
    fffff800`00b9a6f8  fffff880`0f010127 dxgmms1!VidSchiInterlockedInsertTailList+0x47
    fffff800`00b9a700  00000000`00000000
    fffff800`00b9a708  fffffa80`0e7ca000
    fffff800`00b9a710  fffffa80`0e7cab10
    fffff800`00b9a718  00000000`00000000
    fffff800`00b9a720  00000000`00000000
    fffff800`00b9a728  fffffa80`0e7c17a8
    fffff800`00b9a730  fffffa80`0e7cb302
    fffff800`00b9a738  fffffa80`0e7c1010
    fffff800`00b9a740  fffffa80`0e7cb340
    fffff800`00b9a748  fffff880`0f008e34 dxgmms1!VidSchDdiNotifyDpcWorker+0x1c0
    fffff800`00b9a750  00000000`00000000
    fffff800`00b9a758  fffffa80`0e7c1010
    fffff800`00b9a760  00000000`00000000
    fffff800`00b9a768  fffffa80`0d285000
    fffff800`00b9a770  fffff800`00b94080
    fffff800`00b9a778  00000000`00000022
    fffff800`00b9a780  00000000`00000000
    fffff800`00b9a788  00000000`00000000
    fffff800`00b9a790  fffffa80`0e7bb000
    fffff800`00b9a798  fffff880`0f008c63 dxgmms1!VidSchDdiNotifyDpc+0x9f
    fffff800`00b9a7a0  00000007`00000030
    fffff800`00b9a7a8  fffffa80`0d2971f8
    fffff800`00b9a7b0  fffffa80`0e7c1010
    fffff800`00b9a7b8  fffffa80`0d289000
    fffff800`00b9a7c0  00000000`00000000
    fffff800`00b9a7c8  fffffa80`0e7c17b8
    fffff800`00b9a7d0  00e3e790`00000030
    fffff800`00b9a7d8  00000000`0000000c
    fffff800`00b9a7e0  00000000`00000000
    fffff800`00b9a7e8  fffff880`102dc1cf dxgkrnl!DxgNotifyDpcCB+0x77
    fffff800`00b9a7f0  fffffa80`0d74e480
    fffff800`00b9a7f8  00000000`00000000
    fffff800`00b9a800  fffff800`00b94080
    fffff800`00b9a808  00000000`00000022
    fffff800`00b9a810  fffff800`00b9a920

    4: To see whether a driver or drivers are named in the stack, scroll through and scan for outputs like the two examples below:

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-3.jpg

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-4.jpg

    Here you can see two offending drivers, atikmdag.sys and lvuvc64.sys. These drivers have been named in the crash dump so you can assume they're contributing to the problem. First you must identify the drivers, to do this refer to the archive opened in Part One C) and open the drivers.txt file.

    Note   Note
    If your default program association for .txt files isn't already set to Notepad, change it prior to opening.

    5: In the drivers.txt file, looking in the Path column, scroll down until you find the name of the driver listed in the dump file. Reference the Display Name and Description columns for the identity of the driver.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-6.jpg
    In this case the Display Name and Description read the same as the driver name, in such an instance a quick Google search for atikmdag.sys will reveal it's the ATI Graphics driver.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-7.jpg

    In this case the driver is named as a LogitechHD Webcam C61 driver.

    6: Now you have identified the drivers, check the age of each one by typing lmvm followed by the driver name (minus the .sys) into the command bar of WinDBG and hit enter.

    lmvm atikmdag
    Gives the readout:

    0: kd> lmvm atikmdag
    start             end                 module name
    fffff880`0f055000 fffff880`102d9000   atikmdag T (no symbols)           
        Loaded symbol image file: atikmdag.sys
        Image path: \SystemRoot\system32\DRIVERS\atikmdag.sys
        Image name: atikmdag.sys
        Timestamp:        Fri Nov 21 02:30:27 2014 (546EA3C3)
        CheckSum:         0121F198
        ImageSize:        01284000
        Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

    The date of the driver is highlighted giving an indication of whether an update to a newer version or rollback to an earlier version should be applied to test.

    lmvm lvuvc64
    Gives the readout:

    0: kd> lmvm lvuvc64
    start             end                 module name
    fffff880`05ad5000 fffff880`05f5e300   lvuvc64  T (no symbols)           
        Loaded symbol image file: lvuvc64.sys
        Image path: \SystemRoot\system32\DRIVERS\lvuvc64.sys
        Image name: lvuvc64.sys
        Timestamp:        Fri Sep 21 20:03:12 2012 (505CB9F0)
        CheckSum:         0048F35A
        ImageSize:        00489300
        Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

    In this case the date of the driver would indicate an update is required as the installed version is relatively old.

    This method can be applied to all drivers that appear in stacks within dump files. It is worth noting however that not all dump files will show drivers as the problem, in some instances it may be hardware that is causing issues but if the STOP code is one that normally indicates a driver as being the problem it may be necessary to run Driver Verifier to weed out the offending driver. These calls come with experience, and identifying drivers as causes of BSODs is just the tip of the proverbial iceberg.



    The !analyze command displays information about the current exception (or Bugcheck), adding the -v extension displays the verbose output as pictured below. Two points of information to take from the !analyze-v output in this instance is Arg4 (the blocked irp) and the FAILURE_BUCKET_ID and BUCKET_ID (pictured below).

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-windbg-command-8.jpg

    Type !irp into the command box followed by the value of Arg4 and hit enter.

    !irp fffffa800ff17ca0

    The output from !irp shows that the third stack is active and blames athrx.sys for the DRIVER_POWER_STATE_FAILURE.

    >[ 16, 2]   0  0 fffffa800d879050 00000000 00000000-00000000    
              Unable to load image \SystemRoot\system32\DRIVERS\athrx.sys, Win32 error 0n2
    *** WARNING: Unable to verify timestamp for athrx.sys
    *** ERROR: Module load completed but symbols could not be loaded for athrx.sys

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-irp.jpg

    As alluded to in the previous !analyze-v output screenshot, athrx.sys has been named in the current stack. Referencing that driver name in the drivers.txt file you can see that the driver is Qualcomm Atheros network adapter driver, this is the driver responsible for the DRIVER_POWER_STATE_FAILURE at system shutdown. Running the lmvm athrx command shows that the driver is old and needs updating.

    0: kd> lmvm athrx
    start             end                 module name
    fffff880`04824000 fffff880`04beb000   athrx    T (no symbols)           
        Loaded symbol image file: athrx.sys
        Image path: \SystemRoot\system32\DRIVERS\athrx.sys
        Image name: athrx.sys
        Timestamp:        Thu Oct 25 03:31:15 2012 (5088A473)
        CheckSum:         003AF186
        ImageSize:        003C7000
        Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4


     Common Bugchecks and Plans of Attack

    There are several bugchecks that appear on a regular basis which should nearly always require the same course of action, two of them are covered below.

    • 0x116 (VIDEO_TDR_ERROR)



    A VIDEO_TDR_ERROR always relates to the system's graphics card (TDR = Timeout Detection Recovery). This could be down to a number of reasons including drivers, heat, power to the card, a faulty PCI-e slot or simply a defective GPU. It's in your best interests to employ common sense trouble shooting techniques in these situations.

    • Try later and/or earlier drivers
    • Measure the GPU's temperatures at idle and under load
    • Ensure the GPU is free from dust build up and that the fan is working correctly
    • Reseat the GPU and check all connections are securely made
    • Check PSU voltages in BIOS
    • Try a different card in the system



    A 0x124 is one of the worst STOP codes to encounter for the sole reason that the dump files usually give nothing away as to the cause of the problem. WHEA (Windows Hardware Error Architecture) errors signify a problem with hardware but very rarely pinpoint the culprit. In these scenarios it is advised to run a series of hardware stress and diagnostic tests to try and pinpoint the problem. A template is offered below which covers the four main components (GPU, CPU, RAM, HDD) and gives you a fighting chance of narrowing down the problematic device.

    information   Information
    While 0x124s are usually caused by defective hardware it has been proven on occasion for software to be the culprit. See 0x124 software section for information.

    To attempt dig deeper into a 0x124 use the !analyze-v command, in the example below you'll see the PROCESS_NAME: audiodg.exe.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-0x124-1.jpg

    In this particular case there were also 0x1000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M) dumps which identified a Logitech Headset driver (dated 2013) as an issue. This tied in with the audio reference highlighted in the 0x124 so the recommended action would be to update the driver for the headset, negating the need to stress test components.

    If there is no clear indicator within the verbose output run !errrec on Arg2 the Address of the WHEA_ERROR_RECORD structure.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-0x124-2.jpg

    Again this will often result in a dead end, the !errrec output from the above dump reveals nothing of use. This is a very common output from this particular command within 0x124s.

    4: kd> !errrec fffffa8008f15028
    Common Platform Error Record @ fffffa8008f15028
    Record Id     : 01d085fcd7041c49
    Severity      : Fatal (1)
    Length        : 928
    Creator       : Microsoft
    Notify Type   : Machine Check Exception
    Timestamp     : 5/4/2015 1:21:13 (UTC)
    Flags         : 0x00000000
    Section 0     : Processor Generic
    Descriptor    @ fffffa8008f150a8
    Section       @ fffffa8008f15180
    Offset        : 344
    Length        : 192
    Flags         : 0x00000001 Primary
    Severity      : Fatal
    Proc. Type    : x86/x64
    Instr. Set    : x64
    Error Type    : Cache error
    Operation     : Instruction Execute
    Flags         : 0x00
    Level         : 1
    CPU Version   : 0x0000000000600f20
    Processor ID  : 0x0000000000000004
    Section 1     : x86/x64 Processor Specific
    Descriptor    @ fffffa8008f150f0
    Section       @ fffffa8008f15240
    Offset        : 536
    Length        : 128
    Flags         : 0x00000000
    Severity      : Fatal
    Local APIC Id : 0x0000000000000004
    CPU Id        : 20 0f 60 00 00 08 08 04 - 0b 32 98 3e ff fb 8b 17
                    00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
    Proc. Info 0  @ fffffa8008f15240
    Section 2     : x86/x64 MCA
    Descriptor    @ fffffa8008f15138
    Section       @ fffffa8008f152c0
    Offset        : 664
    Length        : 264
    Flags         : 0x00000000
    Severity      : Fatal
    Error         : ICACHEL1_IRD_ERR (Proc 4 Bank 1)
      Status      : 0xb080000000040151


    On more than one instance software has been identified as being the cause of STOP 0x124s, namely Gigabyte motherboard utilities. Follow the links below for more detailed information and analysis.

    Tip   Tip
    Any of the stress or diagnostic tests below can be used individually to diagnose hardware faults outside 0x124 situations.

    STOP 0x124 Troubleshooting

    Read carefully before proceeding.

    warning   Warning
    If you're overclocking your system, revert back to stock clocks now.

    Note   Note
    Test the system once the overclock is removed before continuing with the steps outlined below.



    Run Prime95 to stress test your CPU. Prime95 Tutorial

    warning   Warning
    Your CPU temperatures will rise quickly while under this stress test. Keep a keen eye on them and abort the test if temperatures rise too high.



    Run MemTest86+ to analyse your RAM. MemTest86+ Tutorial

    Note   Note
    MemTest86+ needs to be run for at least 8 passes for conclusive results. Set it running before you go to bed and leave it overnight. We're looking for zero errors here. Even a single error will indicate RAM failure.



    Run SeaTools to check the integrity of your HDD. SeaTools Tutorial

    Run chkdsk Chkdsk



    Run Furmark to stress test your GPU. Furmark Tutorial
    Note   Note
    Run Furmark for around 30 minutes.
    warning   Warning
    Your GPU temperatures will rise quickly while Furmark is running. Keep a keen eye on them and abort the test if temperatures rise too high.


     SCSI Pass-Thru Direct (SPTD)

    information   Information
    SCSI Pass-Thru Direct (SPTD) is a proprietary API and device driver which uses an alternative method of accessing SCSI devices. SPTD is bundled into DAEMON Tools and Alcohol 120% and is a proven cause of countless BSODs. Uninstalling DAEMON Tools and/or Alcohol 120% does not remove SPTD from the system, it has to be uninstalled using an additional process outlined below.

    To check if DAEMON Tools and/or Alcohol 120% is installed on a system:

    1: Open the selected archive as per Step 1 C)

    2: Locate the msinfo32.nfo file and double click to open the file. This will enable you to see the details of the system experiencing the BSODs.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-sptd-1.jpg

    3: With the msinfo32.nfo file opened click on the + sign next to Software Environment in the left hand navigation pane to expand the section then click on Startup Programs in the expanded menu. Browse the program list to see if DAEMON Tools or Alcohol 120% are installed.

    WinDBG - The Basics for Debugging Crash Dumps in Windows 10-sptd-2.jpg
    4: If either program is installed it is best practice to recommend the user uninstall them. Use the template below to instruct the user on how to completely uninstall SPTD. Delete whichever program is not applicable.


    1. Uninstall Daemon Tools/Alcohol 120%.
    2. Download the SPTD standalone installer and perform the following steps.
    3. Double click the executable to open it.
    4. Click the button shown below.

    information   Information
    If the button it is grayed out as shown in the image, there is no more SPTD installation on your system and you can just close the window.


     Recommended Research Materials

    Learning to debug BSOD crash dumps is no small feat and a knowledge of the internal of Windows can be hugely advantageous. The three books listed below will offer a vast insight into the workings of Windows and furnish you with a greater knowledge of what's actually happening within dump files.

    This concludes this beginner's guide to debugging BSODs in Windows 10, if you have any questions please feel free to ask in the thread.


  1. Boozad's Avatar
    Posts : 1,625
    W7 Pro x64 | W10 IP x64 | Linux Mint VM

    Updated to include more information on STOP 0x124s.
      My Computer

  2. Boozad's Avatar
    Posts : 1,625
    W7 Pro x64 | W10 IP x64 | Linux Mint VM
    Thread Starter

    Updated to include information on SCSI Pass-Thru Direct.
      My Computer

  3. Dude's Avatar
    Posts : 14,154
    Windows 10 Pro X64

    Very good tutorial Gav!
      My Computers

  4. Boozad's Avatar
    Posts : 1,625
    W7 Pro x64 | W10 IP x64 | Linux Mint VM
    Thread Starter

    Thanks Doug. :)
      My Computer

  5. ICIT2LOL's Avatar
    Posts : 4,081
    1010 Pro on all on various machines version 1909

    Wow Gav mate that is some piece of work can I take it (without having thoroughly read it yet) as the same form of dealing with BSOD's in 7?
      My Computer

  6. axe0's Avatar
    Posts : 14,595
    Windows 10 Pro

    It is the same for Windows 7 to 10 :)
      My Computers

  7. ICIT2LOL's Avatar
    Posts : 4,081
    1010 Pro on all on various machines version 1909

    Thanks Martjin it just looked a little more detailed which is really what I was after perhaps I won't make too many mistakes this time
      My Computer

  8. Sumit Dhiman's Avatar
    Posts : 341
    Windows 10

    Getting to know things..

    I hope someone can help me with this:
    When I type in dps Limit Base
    I should get the name of the offending driver/drivers within the wall of text,but it isn't the case when I use it.
    Can somebody throw a light on this?
    Example dump
      My Computer

  9. Posts : 1,088
    Win 10 Pro x64

    Sumit Dhiman said:
    I hope someone can help me with this:
    When I type in dps Limit Base
    I should get the name of the offending driver/drivers within the wall of text,but it isn't the case when I use it.
    Can somebody throw a light on this?
    Example dump
    It would be better if you show us what you get, I have no idea which one of those dumps you are reading, let's stick to one dump and see what might be the problem.

    It could also be that no driver gets flagged after doing that, then you have to resort to other methods.

    Looking at this dump real quick,

    There is no driver getting flagged so you wouldn't see it.
      My Computer

Page 1 of 5 123 ... LastLast

Tutorial Categories

WinDBG - The Basics for Debugging Crash Dumps in Windows 10 Tutorial Index Network & Sharing Instalation and Upgrade Browsers and Email General Tips Gaming Customization Apps and Features Virtualization BSOD System Security User Accounts Hardware and Drivers Updates and Activation Backup and Restore Performance and Maintenance Mixed Reality Phone

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 16:52.
Find Us

Windows 10 Forums