I experienced a Bluescreen of Death (BSOD) on my Windows 8 Laptop (HP EliteBook 8560w) this morning when it resumed from Hibernate.
I quickly launched WinDBG and opened the crashdump.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 |
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\Minidump\030613-18798-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: srv*E:\Temp\Symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows 7 Kernel Version 9200 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 9200.16496.amd64fre.win8_gdr.130108-1504 Machine Name: Kernel base = 0xfffff801`32483000 PsLoadedModuleList = 0xfffff801`3274ca80 Debug session time: Wed Mar 6 07:16:24.267 2013 (GMT+1) System Uptime: 3 days 23:01:10.653 Loading Kernel Symbols ............................................................... ................................................................ .................................................... Loading User Symbols Loading unloaded module list .................................................. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 9F, {3, fffffa800dfae880, fffff80133f0db30, fffff9801b7f6d80} *** WARNING: Unable to verify timestamp for e1c63x64.sys *** ERROR: Module load completed but symbols could not be loaded for e1c63x64.sys Probably caused by : e1c63x64.sys Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_POWER_STATE_FAILURE (9f) A driver is causing an inconsistent power state. Arguments: Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time Arg2: fffffa800dfae880, Physical Device Object of the stack Arg3: fffff80133f0db30, Functional Device Object of the stack Arg4: fffff9801b7f6d80, The blocked IRP Debugging Details: ------------------ DRVPOWERSTATE_SUBCODE: 3 IRP_ADDRESS: fffff9801b7f6d80 DEVICE_OBJECT: fffffa8011e01050 DRIVER_OBJECT: fffffa800f7fa5f0 IMAGE_NAME: e1c63x64.sys DEBUG_FLR_IMAGE_TIMESTAMP: 50258df2 MODULE_NAME: e1c63x64 FAULTING_MODULE: fffff88004a00000 e1c63x64 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP BUGCHECK_STR: 0x9F PROCESS_NAME: SynTPEnh.exe CURRENT_IRQL: 2 LAST_CONTROL_TRANSFER: from fffff80132612422 to fffff801324fd040 STACK_TEXT: fffff801`33f0daf8 fffff801`32612422 : 00000000`0000009f 00000000`00000003 fffffa80`0dfae880 fffff801`33f0db30 : nt!KeBugCheckEx fffff801`33f0db00 fffff801`32612455 : fffffa80`20a1e170 fffffa80`11f0ec70 fffff801`33f0dc89 fffff801`325287d6 : nt!PopIrpWatchdogBugcheck+0xe2 fffff801`33f0db60 fffff801`32529ae4 : fffffa80`11f0ec70 fffffa80`11f0eb00 fffff801`33f0de68 fffff880`02ef4180 : nt!PopIrpWatchdog+0x32 fffff801`33f0dbb0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiProcessExpiredTimerList+0x214 STACK_COMMAND: kb FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: X64_0x9F_VRF_IMAGE_e1c63x64.sys BUCKET_ID: X64_0x9F_VRF_IMAGE_e1c63x64.sys Followup: MachineOwner --------- |
WinDBG managed to find the driver that caused this problem by itself this time. But IF WinDBG had not been able to show me the faulty driver, the next step would have been to use the Bugcheck info (0x0000009f) to dig further into this;
|
1 2 3 4 5 6 7 |
DRIVER_POWER_STATE_FAILURE (9f) A driver is causing an inconsistent power state. Arguments: Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time Arg2: fffffa800dfae880, Physical Device Object of the stack Arg3: fffff80133f0db30, Functional Device Object of the stack Arg4: fffff9801b7f6d80, The blocked IRP |
The last argument is the interesting one, and which we should look into further with the !irp command.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
0: kd> !irp fffff9801b7f6d80 Irp is active with 6 stacks 4 is current (= 0xfffff9801b7f6f28) No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned cmd flg cl Device File Completion-Context [ 0, 0] 0 10 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 16, 2] 0 e1 fffffa800dfae880 00000000 fffff80132aca430-fffff9801b7f6ee0 Success Error Cancel pending \Driver\pci nt!IovpInternalCompletionTrap Args: 00041100 00000001 00000001 00000002 [ 16, 2] 0 e1 fffffa800f5a2040 00000000 fffff880014b54c0-fffffa8011e011a0 Success Error Cancel pending \DRIVER\VERIFIER_FILTER ndis!ndisSetDevicePowerOnComplete Args: 00041100 00000001 00000001 00000002 >[ 16, 2] 0 e1 fffffa8011e01050 00000000 fffff80132aca430-fffff9801b7f6f70 Success Error Cancel pending Unable to load image \SystemRoot\system32\DRIVERS\e1c63x64.sys, Win32 error 0n2 *** WARNING: Unable to verify timestamp for e1c63x64.sys *** ERROR: Module load completed but symbols could not be loaded for e1c63x64.sys \Driver\e1cexpress nt!IovpInternalCompletionTrap Args: 00041100 00000001 00000001 00000002 [ 16, 2] 0 e1 fffffa8012162040 00000000 fffff8013259d6a0-fffffa8020a1e170 Success Error Cancel pending \DRIVER\VERIFIER_FILTER nt!PopRequestCompletion Args: 00041100 00000001 00000001 00000002 [ 0, 0] 0 0 00000000 00000000 00000000-fffffa8020a1e170 Args: 00000000 00000000 00000000 00000000 |
It will show something similar to this. And it’s the e1c63x64.sys driver that were active at the time of the bluescreen. Same info as !analyze -v managed to figure out by itself.
Hmm, so what driver is that?
|
1 2 3 4 5 6 7 8 9 10 |
0: kd> lmv m e1c63x64 start end module name fffff880`04a00000 fffff880`04a70000 e1c63x64 T (no symbols) Loaded symbol image file: e1c63x64.sys Image path: \SystemRoot\system32\DRIVERS\e1c63x64.sys Image name: e1c63x64.sys Timestamp: Sat Aug 11 00:40:50 2012 (50258DF2) CheckSum: 0007E11B ImageSize: 00070000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 |
Too bad that it were unable to provide more detailed information. But some oldschool properties of the \SystemRoot\system32\DRIVERS\e1c63x64.sys file gave this;
And a quick search on Intel’s Support sites showed that there was a newer version available for my NIC;
Intel(R) 82579LM Gigabit Network Connection here.
Driver updated, and hopefully no more bluescreens due to this driver bug.