Defrag Tools #136 - Debugging User Mode Crash Dumps Part 2
Description
In this episode of Defrag Tools, Andrew Richards and Chad Beeder use Debugging Tools for Windows (WinDbg) to debug some kernel mode memory dumps. We investigate a kernel mode crash (BSOD), and a system hang.
[00:00] Introduction - kernel mode vs. user mode debugging
[02:18] Dump #1: minidump of a Stop 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL)
[03:24] Start with !analyze -v
[04:58] Debugger help has comprehensive list of bug check codes
[07:45] Do a web search for the functions on the stack
[08:58] Most likely this crash is fixed by KB 3055343
[10:22] Dump #2: Manually-generated crash dump of a system hang, submitted by Channel 9 viewer Tom
[11:22] Dump was forced via keyboard: Forcing a System Crash from the Keyboard
[12:15] !process 0 0 to list all running processes
[14:33] Andrew's funny story about diagnosing a server performance problem on a DEC Alpha cluster
[16:17] !process [address] 17 to see all the threads in a process (including user mode stacks)
[19:50] !thread with no parameters to see what was running on this CPU
[23:58] ~0 to switch to see what was running on processor 0
[24:44] A storport thread has been trying to acquire a spin lock for a long time. Introduction to Spin Locks
[29:05] !locks shows someone is holding IopDeviceTreeLock and PiEnginelock - some thread is doing Plug & Play work - bus re-enumeration
[31:53] lmvm to look at the storage driver - looks pretty old. Check for updates.
[33:22] !devnode 0 1 shows the device tree
[36:10] Questions? Email us at defragtools@microsoft.com
Share
Download
Download this episode
- MP3 (33.6 MB)
- Low Quality MP4 (58.1 MB)
- High Quality MP4 (311.5 MB)
- Mid Quality MP4 (190.1 MB)
More episodes in this series
Defrag Tools #138 - Debugging - 'dx' Command Part 1
Related episodes
Defrag Tools #175 - Debugging the Network Stack
Defrag Tools #136 - Debugging User Mode Crash Dumps Part 2
Defrag Tools #135 - Debugging User Mode Crash Dumps Part 1
Defrag Tools #194 - Windows Upgrade - Application and Device Inventory Files
Access Violation C0000005 - Execute
Access Violation C0000005 - Read or Write
Access Violation C0000005
CLR Exception E0434352
Point-of-Failure Exception C000027C
Stowed Exception C000027B
The Discussion
-
AndreyBazhan Good to see kernel mode debugging (my favorite). As always 5 stars (a) ! By the way, guys, as an alternative to the !process 0 0 command you may check out !ps command from DbgKit extension http://www.andreybazhan.com/dbgkit.html (a)
-
MagicAndre1981 [08:58] Most likely this crash is fixed by KB 3055343
heah, you found my answer on superuser :D
[10:22] Dump #2: Manually-generated crash dump of a system hang, submitted by Channel 9 viewer Tom
was !running (-t) not helpful here?
-
TDabasinskas Having the fact that the issue only occurs while the screensaver is running (meaning, the computer is idling) in mind, I would check Turn off hard disk after setting under Advanced Settings of Power Options. It is very likely that if this setting is enabled (we do see ACPI driver on the stack, so there are chances it is) and the old Nvidia driver does not know how to handle these kind of requests from the power manager, it results into the disk being reset.
Even though disabling that Power setting might not resolve the issue (while upgrading the drivers could), it could work as a workaround.
-
Tom @TDabasinskas... it is an interesting idea to try and disable the "turn off hard disk after..." setting. Unfortunately, I did try setting "turn off hard disk after" to NEVER... and unfortunately, the lockup with screen saver happened.