This topic is locked
This is a short and concise beginner's guide to configuring WinDbg (Windows Debugger) and using the default !anaylze -v command to debug a crash dump file. WinDbg is the only suitable debugging tool for analysing a crash dump file, programs such as WhoCrashed and BlueScreenView only provide very rudimentary information which usually isn't particularly useful in isolation.
WinDbg is part of the Windows SDK and is available to download from here. Please do not use WinDbg Preview from the Microsoft Store, this program is still in beta and is prone to bugs.
Installing and Configuring WinDbg
- Download and open the winsdksetup.exe using the download link provided above.
- Please click Next and/or Accept until you reach the screen asking you to select which components you wish to install.
- Please only select Debugging Tools for Windows and the Windows Performance Toolkit.
- Select Install and wait for the installer to complete.
- Open WinDbg, you can find this by searching for windbg on your Start menu. Please select the version which matches your architecture e.g. x64
- The newer versions of WinDbg should automatically configure and download the debugging symbols (.pdb) for you, however, if you have any warnings about missing symbols, then please configure the symbol search path (CTRL+S) to SRV*c:\symbols*https://msdl.microsoft.com/download/symbols
- It is recommended that you associate the crash dump file extension (.dmp) to the Windows Debugger. Otherwise, you can open the dump file in WinDbg by using CTRL+D and then selecting the dump file.
Using !analyze -v
Once you opened the dump file in WinDbg, you should see a hyperlink for the !analyze -v command. If you click it, then WinDbg's debugger engine will analyse the dump file for you and provide some basic information such as the call stack and the bugcheck parameters. You may also see the last saved context and/or exception record depending on the bugcheck code.
The two most important parts are the bugcheck parameters and the call stack. Let's examine these two key pieces of information.
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: 0000000000000000, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000000, value 0 = read operation, 1 = write operation Arg4: fffff80223c56b5e, address which referenced memory
As we can see, the bugcheck code is Stop 0xD1 and the four parameters are shown below it. We can look up this bugcheck code on the MSDN support page for some basic troubleshooting tips. In our particular example, the first and last parameters are the most important, these indicate what address was being referenced and who was referencing it.
It would seem that we were referencing an address through a null pointer. Let's examine which function was dereferencing the null pointer using the ln command and the value of the fourth parameter. You can enter commands in the input box at the bottom of WinDbg.
2: kd> ln fffff80223c56b5e Browse module Set bu breakpoint (fffff802`23bf2ca0) tcpip!FlpReturnNetBufferListChain+0x63ebe | (fffff802`23bf2db0) tcpip!RscLibExUncoalesceNBL
We can clearly see it is for a tcpip.sys function, which is FlpReturnNetBufferListChain. This is unlikely to be the direct cause of the crash and just happens to be where the exception was thrown. If we examine the call stack (alternatively just use knL) then we can see a third-party driver. These are typically easy to recognise since they will have no function name associated to them. The reason being is because we do not have the appropriate symbols for that driver.
2: kd> knL *** Stack trace for last set context - .thread/.cxr resets it # Child-SP RetAddr Call Site 00 fffff20b`ba7fdfb0 fffff802`23ae5e07 tcpip!FlpReturnNetBufferListChain+0x63ebe 01 fffff20b`ba7fe010 fffff802`23ae5c28 NETIO!NetioDereferenceNetBufferList+0x87 02 fffff20b`ba7fe060 fffff802`23bb8156 NETIO!NetioDereferenceNetBufferListChain+0x1c8 03 fffff20b`ba7fe0e0 fffff802`23bb763f tcpip!IppReceiveHeaderBatch+0x2b6 04 fffff20b`ba7fe1e0 fffff802`23cdf7b2 tcpip!IppFlcReceivePacketsCore+0x32f 05 fffff20b`ba7fe300 fffff802`23cdf634 tcpip!IppInspectInjectReceiveEx+0x172 06 fffff20b`ba7fe350 fffff802`23e887b5 tcpip!IppInspectInjectReceive+0x24 07 fffff20b`ba7fe3b0 fffff802`1ecf8458 fwpkclnt!FwppInjectionStackCallout+0x115 08 fffff20b`ba7fe440 fffff802`1ecf83cd nt!KeExpandKernelStackAndCalloutInternal+0x78 09 fffff20b`ba7fe4b0 fffff802`23e8a2b4 nt!KeExpandKernelStackAndCalloutEx+0x1d 0a fffff20b`ba7fe4f0 fffff802`23e89ea4 fwpkclnt!NetioExpandKernelStackAndCallout+0x58 0b fffff20b`ba7fe530 fffff802`2d2ba363 fwpkclnt!FwpsInjectTransportReceiveAsync0+0x304 0c fffff20b`ba7fe670 ffffd90a`0ea8ef30 klwtp+0xa363 0d fffff20b`ba7fe678 00000000`00000000 0xffffd90a`0ea8ef30
The third-party driver is klwtp.sys and if we look this up in the Driver Reference Table (DRT), then we'll notice that it is for Kaspersky Security and therefore it is recommended that the user either update the program or remove it completely using Kaspersky's official removal tool. That's it!
I appreciate that this is a very short and informal tutorial, however, it is very difficult to cover beyond the very basics in a single post. As a result of this, if you are interested in learning more and becoming proficient in learning how to debug BSODs, then I would thoroughly recommend signing up to the Sysnative BSOD Academy. There is no obligation to finish the academy within a set time frame - you work at your pace - and there is no failure. The instructors will walk you through each assignment step by step, happily answering any questions which you may have. Upon the completion of the academy, you should have a solid foundation to progress from, since BSOD analysis is an ever continual journey of learning.
If you have any questions, then please leave them below or send me a PM.
Edited by xBlueRobot, 20 November 2021 - 01:03 PM.
Back to top
