INTERNAL_POWER_ERROR (a0)

Prokash_Sinha · April 4, 2012, 2:14pm

Folks,

I’ve a question related to above bugcheck in one of our test.

Here is the initial output -

INTERNAL_POWER_ERROR (a0)
The power policy manager experienced a fatal error.
Arguments:
Arg1: 0000000000000009, A fatal error occured while preparing the hibernate
file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
((NTSTATUS)0xC000000EL)
Arg2: ffffffffc000000e, Status code
Arg3: 0000000000000001, Mirroring phase
Arg4: 0000000000000000

Debugging Details:

TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

BUGCHECK_STR: 0xA0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: f

LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490

STACK_TEXT:
fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
0000000000000000 fffffa8007ee0000 : nt!RtlpBreakWithStatusInstruction
fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!PopEndMirroring+145
fffff800`02ce1975 cc int 3

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!PopEndMirroring+145

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a

FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145

BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145

Followup: MachineOwner

Questions are:::::::

I’ve not found any doc, that state the cause of arg1 being 9.
Initial sanity check like: !vm, !memusage etc. does not indicate any
clue. Also the !process 0 7 does not tell any indications about our driver
being in a stack. Perhaps it did something - like a snipper , and left, not
sure… Looked thru a !irpfind to relate any threads currently running in
any processors to any of the pending/stuck irp **No luck**. So looking for
any pattern being documented on the cloud to see how to get deeper. While
looking thru the disassembled code I see there are stack checking code like
this in the
kernel. Could it be due to verifier on?

nt!PopEndMirroring+0x2ea:
fffff80002ce1b1a 8bc3 mov eax,ebx fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h]
fffff80002ce1b24 4833cc xor rcx,rsp fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie
(fffff800`02a92a90)

Basically it seems like it is trying to write the memory on to
hiberfile, and in the middle it finds that the device is no longer there.
Looking at the disassembled code, it seems like it is going to hibernate (
and yes that is the test case ). So is there any pattern someone
documented somewhere ( blog/docs etc)?.

Thanks
-pro

Scott_Noone_OSR · April 4, 2012, 3:33pm

I think you’re actually coming out of hibernate at this point, does the test
automatically resume the system after some timeout (or by direct user
intervention)?

What kind of driver do you have in the system? Do you control the storage
containing the hibernation file?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
Folks,

I’ve a question related to above bugcheck in one of our test.

Here is the initial output -

INTERNAL_POWER_ERROR (a0)
The power policy manager experienced a fatal error.
Arguments:
Arg1: 0000000000000009, A fatal error occured while preparing the hibernate
file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
((NTSTATUS)0xC000000EL)
Arg2: ffffffffc000000e, Status code
Arg3: 0000000000000001, Mirroring phase
Arg4: 0000000000000000

Debugging Details:
------------------

TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

BUGCHECK_STR: 0xA0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: f

LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490

STACK_TEXT:
fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
0000000000000000 fffffa8007ee0000 : nt!RtlpBreakWithStatusInstruction
fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!PopEndMirroring+145
fffff80002ce1975 cc int 3 SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: nt!PopEndMirroring+145 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145 BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145 Followup: MachineOwner Questions are::::::: 0) I've not found any doc, that state the cause of arg1 being 9. 2) Initial sanity check like: !vm, !memusage etc. does not indicate any clue. Also the !process 0 7 does not tell any indications about our driver being in a stack. Perhaps it did something - like a snipper , and left, not sure... Looked thru a !irpfind to relate any threads currently running in any processors to any of the pending/stuck irp **No luck**. So looking for any pattern being documented on the cloud to see how to get deeper. While looking thru the disassembled code I see there are stack checking code like this in the kernel. Could it be due to verifier on? nt!PopEndMirroring+0x2ea: fffff80002ce1b1a 8bc3 mov eax,ebx
fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h] fffff80002ce1b24 4833cc xor rcx,rsp
fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie (fffff80002a92a90)

3) Basically it seems like it is trying to write the memory on to hiberfile,
and in the middle it finds that the device is no longer there. Looking at
the disassembled code, it seems like it is going to hibernate ( and yes that
is the test case ). So is there any pattern someone documented somewhere
( blog/docs etc)?.

Thanks
-pro

Prokash_Sinha · April 4, 2012, 3:53pm

The regression was using Velocity test suite… Need to check how it is
getting out of hibernation.

Yes we are right there in the storage stack. So yes, we are controlling the
storage. Good point Scott, if there is a way to use powercfg to put the
hiberfile into a different drive, that might be an option!!!

It could also be that test configuration(s) is(are) not correct, that is
I’m verifying,since it is quick to reproduce_

I did look at the disassembled code ( did not do a thorough flow-cntl chart
to analyze what is happening), but to me it looked like it is getting in to
hibernate. Stack is kinda telling nt!PopTransitionToSleep
->nt!MmDuplicateMemory->nt!PopEndMirroring. First two kernel functions
looks like it is going on to hibernate, but not sure though…

I looked at the irps to see anything to pin point, not yet there…

-pro

On Wed, Apr 4, 2012 at 12:34 PM, Scott Noone wrote:

> I think you’re actually coming out of hibernate at this point, does the
> test automatically resume the system after some timeout (or by direct user
> intervention)?
>
> What kind of driver do you have in the system? Do you control the storage
> containing the hibernation file?
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> Folks,
>
> I’ve a question related to above bugcheck in one of our test.
>
> Here is the initial output -
>
> INTERNAL_POWER_ERROR (a0)
> The power policy manager experienced a fatal error.
> Arguments:
> Arg1: 0000000000000009, A fatal error occured while preparing the
> hibernate file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
> ((NTSTATUS)0xC000000EL)
> Arg2: ffffffffc000000e, Status code
> Arg3: 0000000000000001, Mirroring phase
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
> TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\ modclass.ini,
> error 2
>
> BUGCHECK_STR: 0xA0
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: f
>
> LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490
>
> STACK_TEXT:
> fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
> 0000000000000000 fffffa8007ee0000 : nt! RtlpBreakWithStatusInstruction
> fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
> 000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
> fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
> 0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
> fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
> ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
> fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
> 00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
> fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
> 0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
> fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
> fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
> fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
> fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
> fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
> fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!PopEndMirroring+145
> fffff80002ce1975 cc int 3 > > SYMBOL_STACK_INDEX: 4 > > SYMBOL_NAME: nt!PopEndMirroring+145 > > FOLLOWUP_NAME: MachineOwner > > MODULE_NAME: nt > > IMAGE_NAME: ntkrnlmp.exe > > DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a > > FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+ **145 > > BUCKET_ID: X64_0xA0_nt!PopEndMirroring+** 145 > > Followup: MachineOwner > > > > Questions are::::::: > > 0) I've not found any doc, that state the cause of arg1 being 9. > > 2) Initial sanity check like: !vm, !memusage etc. does not indicate any > clue. Also the !process 0 7 does not tell any indications about our driver > being in a stack. Perhaps it did something - like a snipper , and left, not > sure... Looked thru a !irpfind to relate any threads currently running in > any processors to any of the pending/stuck irp **No luck**. So looking for > any pattern being documented on the cloud to see how to get deeper. While > looking thru the disassembled code I see there are stack checking code like > this in the > kernel. Could it be due to verifier on? > > nt!PopEndMirroring+0x2ea: > fffff80002ce1b1a 8bc3 mov eax,ebx
> fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h] > fffff80002ce1b24 4833cc xor rcx,rsp
> fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie > (fffff80002a92a90)
>
> 3) Basically it seems like it is trying to write the memory on to
> hiberfile, and in the middle it finds that the device is no longer there.
> Looking at the disassembled code, it seems like it is going to hibernate (
> and yes that is the test case ). So is there any pattern someone
> documented somewhere ( blog/docs etc)?.
>
>
> Thanks
> -pro
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
></http:>

Scott_Noone_OSR · April 4, 2012, 3:59pm

>Yes we are right there in the storage stack. So yes, we are controlling the

storage

Do you have any way to determine if your storage is still attached and
functioning? Is this a crash dump or a live kernel debug session? If it a
live kernel debug session you could try taking a look at your registers,
just make sure you set the debugger’s cache off (.cache 0)

Stack is kinda telling
nt!PopTransitionToSleep ->nt!MmDuplicateMemory->nt!PopEndMirroring. First
two kernel functions looks like it is going on to >hibernate, but not sure
though…

Absolutely. However, thatâ€™s also what the stack looks like initially coming
out of hibernate. At some point the system shuts down and when it comes back
up execution resumes from where it left off. Thus, this call frame doesn’t
unwind until *after* the system resumes from hibernate.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
The regression was using Velocity test suite… Need to check how it is
getting out of hibernation.

Yes we are right there in the storage stack. So yes, we are controlling the
storage. Good point Scott, if there is a way to use powercfg to put the
hiberfile into a different drive, that might be an option!!!

It could also be that test configuration(s) is(are) not correct, that is
I’m verifying,since it is quick to reproduce_

I did look at the disassembled code ( did not do a thorough flow-cntl chart
to analyze what is happening), but to me it looked like it is getting in to
hibernate. Stack is kinda telling
nt!PopTransitionToSleep ->nt!MmDuplicateMemory->nt!PopEndMirroring. First
two kernel functions looks like it is going on to hibernate, but not sure
though…

I looked at the irps to see anything to pin point, not yet there…

-pro

On Wed, Apr 4, 2012 at 12:34 PM, Scott Noone wrote:
I think you’re actually coming out of hibernate at this point, does the test
automatically resume the system after some timeout (or by direct user
intervention)?

What kind of driver do you have in the system? Do you control the storage
containing the hibernation file?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…

Folks,

I’ve a question related to above bugcheck in one of our test.

Here is the initial output -

INTERNAL_POWER_ERROR (a0)
The power policy manager experienced a fatal error.
Arguments:
Arg1: 0000000000000009, A fatal error occured while preparing the hibernate
file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
((NTSTATUS)0xC000000EL)
Arg2: ffffffffc000000e, Status code
Arg3: 0000000000000001, Mirroring phase
Arg4: 0000000000000000

Debugging Details:
------------------

TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

BUGCHECK_STR: 0xA0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: f

LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490

STACK_TEXT:
fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
0000000000000000 fffffa8007ee0000 : nt!RtlpBreakWithStatusInstruction
fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!PopEndMirroring+145
fffff80002ce1975 cc int 3 SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: nt!PopEndMirroring+145 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145 BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145 Followup: MachineOwner Questions are::::::: 0) I've not found any doc, that state the cause of arg1 being 9. 2) Initial sanity check like: !vm, !memusage etc. does not indicate any clue. Also the !process 0 7 does not tell any indications about our driver being in a stack. Perhaps it did something - like a snipper , and left, not sure... Looked thru a !irpfind to relate any threads currently running in any processors to any of the pending/stuck irp **No luck**. So looking for any pattern being documented on the cloud to see how to get deeper. While looking thru the disassembled code I see there are stack checking code like this in the kernel. Could it be due to verifier on? nt!PopEndMirroring+0x2ea: fffff80002ce1b1a 8bc3 mov eax,ebx
fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h] fffff80002ce1b24 4833cc xor rcx,rsp
fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie (fffff80002a92a90)

3) Basically it seems like it is trying to write the memory on to hiberfile,
and in the middle it finds that the device is no longer there. Looking at
the disassembled code, it seems like it is going to hibernate ( and yes that
is the test case ). So is there any pattern someone documented somewhere
( blog/docs etc)?.

Thanks
-pro

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Prokash_Sinha · April 4, 2012, 4:15pm

once again thx for the tips ( on live kd ). It is a crash dump, have not
seen any trap frame, the register(s) states are not preserved, right?
Unless there is some shadow ( which i don’t know). By going thru child-sp
and correlate with rsp, would be another way to look at what has been
pushed in the stack ( will do that if I can’t get forward with other
approach ). Perhaps some register values can be tracked…

I will track when the crash is happening - was not thinking about waking up
(with preserved stacks )…

-pro

On Wed, Apr 4, 2012 at 1:00 PM, Scott Noone wrote:

> Yes we are right there in the storage stack. So yes, we are controlling
>> the storage
>>
>
> Do you have any way to determine if your storage is still attached and
> functioning? Is this a crash dump or a live kernel debug session? If it a
> live kernel debug session you could try taking a look at your registers,
> just make sure you set the debugger’s cache off (.cache 0)
>
>
> Stack is kinda telling nt!PopTransitionToSleep ->nt!MmDuplicateMemory->nt!
>> **PopEndMirroring. First two kernel functions looks like it is going on
>> to >hibernate, but not sure though…
>>
>
> Absolutely. However, that?s also what the stack looks like initially
> coming out of hibernate. At some point the system shuts down and when it
> comes back up execution resumes from where it left off. Thus, this call
> frame doesn’t unwind until after the system resumes from hibernate.
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> The regression was using Velocity test suite… Need to check how it is
> getting out of hibernation.
>
> Yes we are right there in the storage stack. So yes, we are controlling
> the storage. Good point Scott, if there is a way to use powercfg to put the
> hiberfile into a different drive, that might be an option!!!
>
> It could also be that test configuration(s) is(are) not correct, that is
> I’m verifying,since it is quick to reproduce_
>
> I did look at the disassembled code ( did not do a thorough flow-cntl
> chart to analyze what is happening), but to me it looked like it is getting
> in to hibernate. Stack is kinda telling nt!PopTransitionToSleep
> ->nt!MmDuplicateMemory->nt!**PopEndMirroring. First two kernel functions
> looks like it is going on to hibernate, but not sure though…
>
> I looked at the irps to see anything to pin point, not yet there…
>
> -pro
>
>
> On Wed, Apr 4, 2012 at 12:34 PM, Scott Noone wrote:
> I think you’re actually coming out of hibernate at this point, does the
> test automatically resume the system after some timeout (or by direct user
> intervention)?
>
> What kind of driver do you have in the system? Do you control the storage
> containing the hibernation file?
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> Folks,
>
> I’ve a question related to above bugcheck in one of our test.
>
> Here is the initial output -
>
> INTERNAL_POWER_ERROR (a0)
> The power policy manager experienced a fatal error.
> Arguments:
> Arg1: 0000000000000009, A fatal error occured while preparing the
> hibernate file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
> ((NTSTATUS)0xC000000EL)
> Arg2: ffffffffc000000e, Status code
> Arg3: 0000000000000001, Mirroring phase
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
> TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\ modclass.ini,
> error 2
>
> BUGCHECK_STR: 0xA0
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: f
>
> LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490
>
> STACK_TEXT:
> fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
> 0000000000000000 fffffa8007ee0000 : nt! RtlpBreakWithStatusInstruction
> fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
> 000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
> fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
> 0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
> fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
> ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
> fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
> 00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
> fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
> 0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
> fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
> fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
> fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
> fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
> fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
> fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!PopEndMirroring+145
> fffff80002ce1975 cc int 3 > > SYMBOL_STACK_INDEX: 4 > > SYMBOL_NAME: nt!PopEndMirroring+145 > > FOLLOWUP_NAME: MachineOwner > > MODULE_NAME: nt > > IMAGE_NAME: ntkrnlmp.exe > > DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a > > FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+ **145 > > BUCKET_ID: X64_0xA0_nt!PopEndMirroring+** 145 > > Followup: MachineOwner > > > > Questions are::::::: > > 0) I've not found any doc, that state the cause of arg1 being 9. > > 2) Initial sanity check like: !vm, !memusage etc. does not indicate any > clue. Also the !process 0 7 does not tell any indications about our driver > being in a stack. Perhaps it did something - like a snipper , and left, not > sure... Looked thru a !irpfind to relate any threads currently running in > any processors to any of the pending/stuck irp **No luck**. So looking for > any pattern being documented on the cloud to see how to get deeper. While > looking thru the disassembled code I see there are stack checking code like > this in the > kernel. Could it be due to verifier on? > > nt!PopEndMirroring+0x2ea: > fffff80002ce1b1a 8bc3 mov eax,ebx
> fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h] > fffff80002ce1b24 4833cc xor rcx,rsp
> fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie > (fffff80002a92a90)
>
> 3) Basically it seems like it is trying to write the memory on to
> hiberfile, and in the middle it finds that the device is no longer there.
> Looking at the disassembled code, it seems like it is going to hibernate (
> and yes that is the test case ). So is there any pattern someone
> documented somewhere ( blog/docs etc)?.
>
>
> Thanks
> -pro
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServerhttp:
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServerhttp:
></http:></http:>

Scott_Noone_OSR · April 4, 2012, 4:52pm

I was thinking specifically about your device registers, if you knew where
they were in memory you could try to inspect its state. This isn’t going to
be a useful exercise in a crash dump though, device registers aren’t stored
in the dump file at all.

If the system is in the process of resuming (!poaction might tell you
something here), then this is *really* early in the resume process. I’d
suspect a hardware issue or something outside of the O/S (i.e. BIOS/storage
issue on resume).

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
once again thx for the tips ( on live kd ). It is a crash dump, have not
seen any trap frame, the register(s) states are not preserved, right? Unless
there is some shadow ( which i don’t know). By going thru child-sp and
correlate with rsp, would be another way to look at what has been pushed in
the stack ( will do that if I can’t get forward with other approach ).
Perhaps some register values can be tracked…

I will track when the crash is happening - was not thinking about waking up
(with preserved stacks )…

-pro

On Wed, Apr 4, 2012 at 1:00 PM, Scott Noone wrote:

Yes we are right there in the storage stack. So yes, we are controlling the
storage

Do you have any way to determine if your storage is still attached and
functioning? Is this a crash dump or a live kernel debug session? If it a
live kernel debug session you could try taking a look at your registers,
just make sure you set the debugger’s cache off (.cache 0)

Stack is kinda telling
nt!PopTransitionToSleep ->nt!MmDuplicateMemory->nt!PopEndMirroring. First
two kernel functions looks like it is going on to >hibernate, but not sure
though…

Absolutely. However, that’s also what the stack looks like initially coming
out of hibernate. At some point the system shuts down and when it comes back
up execution resumes from where it left off. Thus, this call frame doesn’t
unwind until after the system resumes from hibernate.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…

The regression was using Velocity test suite… Need to check how it is
getting out of hibernation.

Yes we are right there in the storage stack. So yes, we are controlling the
storage. Good point Scott, if there is a way to use powercfg to put the
hiberfile into a different drive, that might be an option!!!

It could also be that test configuration(s) is(are) not correct, that is
I’m verifying,since it is quick to reproduce_

I did look at the disassembled code ( did not do a thorough flow-cntl chart
to analyze what is happening), but to me it looked like it is getting in to
hibernate. Stack is kinda telling
nt!PopTransitionToSleep ->nt!MmDuplicateMemory->nt!PopEndMirroring. First
two kernel functions looks like it is going on to hibernate, but not sure
though…

I looked at the irps to see anything to pin point, not yet there…

-pro

On Wed, Apr 4, 2012 at 12:34 PM, Scott Noone wrote:
I think you’re actually coming out of hibernate at this point, does the test
automatically resume the system after some timeout (or by direct user
intervention)?

What kind of driver do you have in the system? Do you control the storage
containing the hibernation file?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…

Folks,

I’ve a question related to above bugcheck in one of our test.

Here is the initial output -

INTERNAL_POWER_ERROR (a0)
The power policy manager experienced a fatal error.
Arguments:
Arg1: 0000000000000009, A fatal error occured while preparing the hibernate
file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
((NTSTATUS)0xC000000EL)
Arg2: ffffffffc000000e, Status code
Arg3: 0000000000000001, Mirroring phase
Arg4: 0000000000000000

Debugging Details:
------------------

TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

BUGCHECK_STR: 0xA0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: f

LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490

STACK_TEXT:
fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
0000000000000000 fffffa8007ee0000 : nt!RtlpBreakWithStatusInstruction
fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!PopEndMirroring+145
fffff80002ce1975 cc int 3 SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: nt!PopEndMirroring+145 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145 BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145 Followup: MachineOwner Questions are::::::: 0) I've not found any doc, that state the cause of arg1 being 9. 2) Initial sanity check like: !vm, !memusage etc. does not indicate any clue. Also the !process 0 7 does not tell any indications about our driver being in a stack. Perhaps it did something - like a snipper , and left, not sure... Looked thru a !irpfind to relate any threads currently running in any processors to any of the pending/stuck irp **No luck**. So looking for any pattern being documented on the cloud to see how to get deeper. While looking thru the disassembled code I see there are stack checking code like this in the kernel. Could it be due to verifier on? nt!PopEndMirroring+0x2ea: fffff80002ce1b1a 8bc3 mov eax,ebx
fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h] fffff80002ce1b24 4833cc xor rcx,rsp
fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie (fffff80002a92a90)

3) Basically it seems like it is trying to write the memory on to hiberfile,
and in the middle it finds that the device is no longer there. Looking at
the disassembled code, it seems like it is going to hibernate ( and yes that
is the test case ). So is there any pattern someone documented somewhere
( blog/docs etc)?.

Thanks
-pro

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Prokash_Sinha · April 4, 2012, 5:41pm

Without our driver, there is no issue. The same set of tests runs fine.
This is a filter driver.

I looked at few power related (!poaction, !podev, and !poirplist )

0: kd> !poaction
PopAction: fffff80002c35090
State…: 3 - Set System State
Updates…: 0
Action…: Sleep
Lightest State.: Sleeping1
Flags…: 80000004 OverrideApps|Critical
Irp minor…: SetPower
System State…: Sleeping3
Hiber Context…: fffffa800759c9b0

Allocated power irps (PopIrpList - fffff80002c43330)

Irp worker threads (PopIrpThreadList - fffff80002c42c80)

Error resolving nt!_POP_CURRENT_BROADCAST…

0: kd> !poreqlist
All active Power Irps from PoRequestPowerIrp
PopReqestedPowerIrpList
FieldOffset = 0000000000000008

-pro

On Wed, Apr 4, 2012 at 1:53 PM, Scott Noone wrote:

> I was thinking specifically about your device registers, if you knew where
> they were in memory you could try to inspect its state. This isn’t going to
> be a useful exercise in a crash dump though, device registers aren’t stored
> in the dump file at all.
>
> If the system is in the process of resuming (!poaction might tell you
> something here), then this is really early in the resume process. I’d
> suspect a hardware issue or something outside of the O/S (i.e. BIOS/storage
> issue on resume).
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> once again thx for the tips ( on live kd ). It is a crash dump, have not
> seen any trap frame, the register(s) states are not preserved, right?
> Unless there is some shadow ( which i don’t know). By going thru child-sp
> and correlate with rsp, would be another way to look at what has been
> pushed in the stack ( will do that if I can’t get forward with other
> approach ). Perhaps some register values can be tracked…
>
> I will track when the crash is happening - was not thinking about waking
> up (with preserved stacks )…
>
> -pro
>
>
> On Wed, Apr 4, 2012 at 1:00 PM, Scott Noone wrote:
>
> Yes we are right there in the storage stack. So yes, we are controlling
> the storage
>
> Do you have any way to determine if your storage is still attached and
> functioning? Is this a crash dump or a live kernel debug session? If it a
> live kernel debug session you could try taking a look at your registers,
> just make sure you set the debugger’s cache off (.cache 0)
>
>
> Stack is kinda telling nt!PopTransitionToSleep ->nt!MmDuplicateMemory->nt!
> **PopEndMirroring. First two kernel functions looks like it is going on
> to >hibernate, but not sure though…
>
> Absolutely. However, that?s also what the stack looks like initially
> coming out of hibernate. At some point the system shuts down and when it
> comes back up execution resumes from where it left off. Thus, this call
> frame doesn’t unwind until after the system resumes from hibernate.
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> The regression was using Velocity test suite… Need to check how it is
> getting out of hibernation.
>
> Yes we are right there in the storage stack. So yes, we are controlling
> the storage. Good point Scott, if there is a way to use powercfg to put the
> hiberfile into a different drive, that might be an option!!!
>
> It could also be that test configuration(s) is(are) not correct, that is
> I’m verifying,since it is quick to reproduce_
>
> I did look at the disassembled code ( did not do a thorough flow-cntl
> chart to analyze what is happening), but to me it looked like it is getting
> in to hibernate. Stack is kinda telling nt!PopTransitionToSleep
> ->nt!MmDuplicateMemory->nt!**PopEndMirroring. First two kernel functions
> looks like it is going on to hibernate, but not sure though…
>
> I looked at the irps to see anything to pin point, not yet there…
>
> -pro
>
>
> On Wed, Apr 4, 2012 at 12:34 PM, Scott Noone wrote:
> I think you’re actually coming out of hibernate at this point, does the
> test automatically resume the system after some timeout (or by direct user
> intervention)?
>
> What kind of driver do you have in the system? Do you control the storage
> containing the hibernation file?
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> Folks,
>
> I’ve a question related to above bugcheck in one of our test.
>
> Here is the initial output -
>
> INTERNAL_POWER_ERROR (a0)
> The power policy manager experienced a fatal error.
> Arguments:
> Arg1: 0000000000000009, A fatal error occured while preparing the
> hibernate file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
> ((NTSTATUS)0xC000000EL)
> Arg2: ffffffffc000000e, Status code
> Arg3: 0000000000000001, Mirroring phase
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
> TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\ modclass.ini,
> error 2
>
> BUGCHECK_STR: 0xA0
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: f
>
> LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490
>
> STACK_TEXT:
> fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
> 0000000000000000 fffffa8007ee0000 : nt! RtlpBreakWithStatusInstruction
> fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
> 000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12
> fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
> 0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8
> fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
> ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104
> fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
> 00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145
> fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
> 0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64
> fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
> fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5
> fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
> fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a
> fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
> fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!PopEndMirroring+145
> fffff80002ce1975 cc int 3 > > SYMBOL_STACK_INDEX: 4 > > SYMBOL_NAME: nt!PopEndMirroring+145 > > FOLLOWUP_NAME: MachineOwner > > MODULE_NAME: nt > > IMAGE_NAME: ntkrnlmp.exe > > DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a > > FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+ **145 > > BUCKET_ID: X64_0xA0_nt!PopEndMirroring+** 145 > > Followup: MachineOwner > > > > Questions are::::::: > > 0) I've not found any doc, that state the cause of arg1 being 9. > > 2) Initial sanity check like: !vm, !memusage etc. does not indicate any > clue. Also the !process 0 7 does not tell any indications about our driver > being in a stack. Perhaps it did something - like a snipper , and left, not > sure... Looked thru a !irpfind to relate any threads currently running in > any processors to any of the pending/stuck irp **No luck**. So looking for > any pattern being documented on the cloud to see how to get deeper. While > looking thru the disassembled code I see there are stack checking code like > this in the > kernel. Could it be due to verifier on? > > nt!PopEndMirroring+0x2ea: > fffff80002ce1b1a 8bc3 mov eax,ebx
> fffff80002ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h] > fffff80002ce1b24 4833cc xor rcx,rsp
> fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie > (fffff80002a92a90)
>
> 3) Basically it seems like it is trying to write the memory on to
> hiberfile, and in the middle it finds that the device is no longer there.
> Looking at the disassembled code, it seems like it is going to hibernate (
> and yes that is the test case ). So is there any pattern someone
> documented somewhere ( blog/docs etc)?.
>
>
> Thanks
> -pro
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServerhttp:
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServerhttp:
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
></http:></http:></http:>

Prokash_Sinha · April 4, 2012, 6:49pm

One thing I was trying to find is the type *nt!TRIAGE_9F_POWER* this is
for a different crash ( after modifying the hiberfile size configuration,
now it is 100% of the memory installed ).

But on 64bit Win 7, and I understand I’ve stripped os files.

kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
Symbol nt!TRIAGE_9F_POWER not found

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559329(v=vs.85).aspx
tells
how to use it…

-pro

OSR_Community_User · April 4, 2012, 7:04pm

You have to see where it is declared. If the declaration is

const SOMEINTEGERTYPE TRIAGE_9F_POWER = number;

then it can be found by the debugger, but if it is

#define TRIAGE_9F_POWER number

then the symbol disappears in the preprocessor and is never seen by the
compiler, hence unavailable in the debugger.

Note that if the symbol is a const integer type, it may not have a
location allocated to hold it.
joe

One thing I was trying to find is the type *nt!TRIAGE_9F_POWER* this is
for a different crash ( after modifying the hiberfile size configuration,
now it is 100% of the memory installed ).

But on 64bit Win 7, and I understand I’ve stripped os files.

kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
Symbol nt!TRIAGE_9F_POWER not found

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559329(v=vs.85).aspx
tells
how to use it…

-pro

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 4, 2012, 8:32pm

Is it Vista system caused by many times sleep loop? If that, it may be same
root cause of an OS known issue which caused by failed to allocate a large
continue virtual address for hibernate file:

http://support.microsoft.com/kb/969853/en-us

???: xxxxx@lists.osr.com [mailto:xxxxx@lists.
osr.com] ??? Prokash Sinha
???ʱ??: April 05, 2012 02:14
?ռ???: Kernel Debugging Interest List
???: [windbg] INTERNAL_POWER_ERROR (a0)

Folks,

I’ve a question related to above bugcheck in one of our test.

Here is the initial output -

INTERNAL_POWER_ERROR (a0)

The power policy manager experienced a fatal error.

Arguments:

Arg1: 0000000000000009, A fatal error occured while preparing the hibernate
file. <<<<<<< ntstatus.h:#define STATUS_NO_SUCH_DEVICE
((NTSTATUS)0xC000000EL)

Arg2: ffffffffc000000e, Status code

Arg3: 0000000000000001, Mirroring phase

Arg4: 0000000000000000

Debugging Details:

TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

BUGCHECK_STR: 0xA0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: f

LAST_CONTROL_TRANSFER: from fffff80002b82d92 to fffff80002a93490

STACK_TEXT:

fffff880085fd398 fffff80002b82d92 : 0000000000000000 0000000000000000
0000000000000000 fffffa8007ee0000 : nt!RtlpBreakWithStatusInstruction

fffff880085fd3a0 fffff80002b84158 : fffff80000000004 fffff80002c93b80
000000000000000f fffffa8003e356e0 : nt!KiBugCheckDebugBreak+0x12

fffff880085fd400 fffff80002a9b744 : 0000000000000000 0000000000000000
0000000000000128 0000000000000001 : nt!KeBugCheck2+0xcf8

fffff880085fdad0 fffff80002ce1975 : 00000000000000a0 0000000000000009
ffffffffc000000e 0000000000000001 : nt!KeBugCheckEx+0x104

fffff880085fdb10 fffff80002cdd704 : ffffffffffffffff ffffffffffffffff
00000000001287fb 0000000000000000 : nt!PopEndMirroring+0x145

fffff880085fdbe0 fffff80002ce1c35 : fffff880085fdd00 fffff88000000008
0000000000000000 fffffa8000000008 : nt!MmDuplicateMemory+0xb64

fffff880085fdcd0 fffff80002d38cce : fffffa8003e356e0 fffffa8003adb040
fffffa8003adb040 fffff80002a93157 : nt!PopTransitionToSleep+0xd5

fffff880085fdd40 fffff80002a8cfe6 : fffff80002c0de80 fffffa8003e356e0
fffff80002c1bcc0 fffff8800121fcb0 : nt!PspSystemThreadStartup+0x5a

fffff880085fdd80 0000000000000000 : fffff880085fe000 fffff880085f8000
fffff880085fd920 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!PopEndMirroring+145

fffff800`02ce1975 cc int 3

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!PopEndMirroring+145

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a

FAILURE_BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145

BUCKET_ID: X64_0xA0_nt!PopEndMirroring+145

Followup: MachineOwner

Questions are:::::::

I’ve not found any doc, that state the cause of arg1 being 9.
Initial sanity check like: !vm, !memusage etc. does not indicate any
clue. Also the !process 0 7 does not tell any indications about our driver
being in a stack. Perhaps it did something - like a snipper , and left, not
sure… Looked thru a !irpfind to relate any threads currently running in
any processors to any of the pending/stuck irp **No luck**. So looking for
any pattern being documented on the cloud to see how to get deeper. While
looking thru the disassembled code I see there are stack checking code like
this in the

kernel. Could it be due to verifier on?

nt!PopEndMirroring+0x2ea:

fffff800`02ce1b1a 8bc3 mov eax,ebx

fffff800`02ce1b1c 488b8c2490000000 mov rcx,qword ptr [rsp+90h]

fffff800`02ce1b24 4833cc xor rcx,rsp

fffff80002ce1b27 e8640fdbff call nt!_security_check_cookie (fffff80002a92a90)

Basically it seems like it is trying to write the memory on to hiberfile,
and in the middle it finds that the device is no longer there. Looking at
the disassembled code, it seems like it is going to hibernate ( and yes that
is the test case ). So is there any pattern someone documented somewhere (
blog/docs etc)?.

Thanks

-pro

— WINDBG is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Prokash_Sinha · April 4, 2012, 11:13pm

Oh this is nt kernel typedef, and in win 7 "dt nt!* then grepping does not
show *TRIAGE* type, that was being used in the msdn doc ( the link I
provided).

So basically I can not take that analysis path, well if I can cook up a
typedef on the fly while using windbg then that could be nice, otherwise
parse the raw data…

!po* did not help much either, looked at the !irplist, and got some clues
( but need to correlate before forming any Hypothesis ).

Looked at the !stacks, !memusage [8], !vm nothing particularly
interesting. Also !locks don’t show up with high contentions.

The time out is 10 minutes, and it could not get out of it…

Looked at bits and pieces of random KB that MSFT put out there, but nothing
matching so far …

For the other poster, this is x64 machine, so that link does not cover the
issue…

-pro

On Wed, Apr 4, 2012 at 4:03 PM, wrote:

> You have to see where it is declared. If the declaration is
>
> const SOMEINTEGERTYPE TRIAGE_9F_POWER = number;
>
> then it can be found by the debugger, but if it is
>
> #define TRIAGE_9F_POWER number
>
> then the symbol disappears in the preprocessor and is never seen by the
> compiler, hence unavailable in the debugger.
>
> Note that if the symbol is a const integer type, it may not have a
> location allocated to hold it.
> joe
>
>
> > One thing I was trying to find is the type nt!TRIAGE_9F_POWER this is
> > for a different crash ( after modifying the hiberfile size configuration,
> > now it is 100% of the memory installed ).
> >
> > But on 64bit Win 7, and I understand I’ve stripped os files.
> >
> > kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
> > Symbol nt!TRIAGE_9F_POWER not found
> >
> >
> >
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559329(v=vs.85).aspx
> > tells
> > how to use it…
> >
> > -pro
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Scott_Noone_OSR · April 5, 2012, 9:21am

I donâ€™t have this data type in my symbols either, I filed a bug against the
documentation at least.

Luckily the article provides output of the command working with private
symbols though, so you know the structure layout:

0: kd> dt nt!TRIAGE_9F_POWER 82b5dae0
+0x000 Signature : 0x8000
+0x002 Revision : 1
+0x004 IrpList : 0x82b78480 _LIST_ENTRY
+0x008 ThreadList : 0x82b77f28 _LIST_ENTRY
+0x00c DelayedWorkQueue : 0x82b715bc _TRIAGE_EX_WORK_QUEUE

What’s the bugcheck information for the new crash?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
One thing I was trying to find is the type nt!TRIAGE_9F_POWER this is for a
different crash ( after modifying the hiberfile size configuration, now it
is 100% of the memory installed ).

But on 64bit Win 7, and I understand I’ve stripped os files.

kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
Symbol nt!TRIAGE_9F_POWER not found

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559329(v=vs.85).aspx
tells how to use it…

-pro

Prokash_Sinha · April 5, 2012, 1:36pm

0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually
10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too
long a time
Arg2: fffffa80054ca050, Physical Device Object of the stack
Arg3: fffff80000b9c518, nt!TRIAGE_9F_POWER on Win7, otherwise the
Functional Device Object of the stack
Arg4: fffffa8007e37010, The blocked IRP

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for
ahcix64.sys
TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

DRVPOWERSTATE_SUBCODE: 3

DRIVER_OBJECT: fffffa8003accc90

IMAGE_NAME: ahcix64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4c9b227e

MODULE_NAME: ahcix64

FAULTING_MODULE: fffff88001039000 ahcix64

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: System

CURRENT_IRQL: f

STACK_TEXT:
fffff80000b9bd58 fffff80002bb8d92 : fffffa800738cea0 0000000000000000
0000000000000000 fffffa8007a6d000 : nt!RtlpBreakWithStatusInstruction
fffff80000b9bd60 fffff80002bba158 : fffff80000000004 fffff80002cc9b80
000000000000000f fffff80002c51cc0 : nt!KiBugCheckDebugBreak+0x12
fffff80000b9bdc0 fffff80002ad1744 : fffffa8008021260 fffff80002b7e054
fffff80000000068 0000000000000004 : nt!KeBugCheck2+0xcf8
fffff80000b9c490 fffff80002b3db52 : 000000000000009f 0000000000000003
fffffa80054ca050 fffff80000b9c518 : nt!KeBugCheckEx+0x104
fffff80000b9c4d0 fffff80002add062 : fffff80000b9c600 fffff80000b9c600
0000000000000001 0000000000000001 : nt! ?? ::FNODOBFM::string'+0x34a90 fffff80000b9c570 fffff80002adcf06 : fffff80002c79740 0000000000025385 0000000000000000 0000000000000000 : nt!KiProcessTimerDpcTable+0x66 fffff80000b9c5e0 fffff80002adcdee : 0000000589921c88 fffff80000b9cc58 0000000000025385 fffff80002c47328 : nt!KiProcessExpiredTimerList+0xc6 fffff80000b9cc30 fffff80002adcbd7 : 00000002150b0fc1 0000000200025385 00000002150b0f37 0000000000000085 : nt!KiTimerExpiration+0x1be fffff80000b9ccd0 fffff80002ac936a : fffff80002c43e80 fffff80002c51cc0 fffff80000000001 fffff88000000000 : nt!KiRetireDpcList+0x277 fffff80000b9cd80 0000000000000000 : fffff80000b9d000 fffff80000b97000 fffff80000b9cd40 00000000`00000000 : nt!KiIdleLoop+0x5a

0: kd> !stacks
Proc.Thread .Thread Ticks ThreadState Blocker
[fffff80002c521c0 Idle]
0.000000 fffff80002c51cc0 0000000 RUNNING
nt!RtlpBreakWithStatusInstruction
0.000000 fffff880009fe040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff88002f6f040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff88002fe0040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff880009bd040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff88003093040 ffffdd5b RUNNING amdppm!ReadIoMemRaw+0x30

[… rest of the threads are BLOCKED]

Yes I know the structure, and am going to try to peel off the infos…

-pro

On Thu, Apr 5, 2012 at 6:21 AM, Scott Noone wrote:

> I don?t have this data type in my symbols either, I filed a bug against
> the documentation at least.
>
> Luckily the article provides output of the command working with private
> symbols though, so you know the structure layout:
>
> 0: kd> dt nt!TRIAGE_9F_POWER 82b5dae0
> +0x000 Signature : 0x8000
> +0x002 Revision : 1
> +0x004 IrpList : 0x82b78480 _LIST_ENTRY
> +0x008 ThreadList : 0x82b77f28 _LIST_ENTRY
> +0x00c DelayedWorkQueue : 0x82b715bc _TRIAGE_EX_WORK_QUEUE
>
> What’s the bugcheck information for the new crash?
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
> One thing I was trying to find is the type nt!TRIAGE_9F_POWER this is for
> a different crash ( after modifying the hiberfile size configuration, now
> it is 100% of the memory installed ).
>
>
> But on 64bit Win 7, and I understand I’ve stripped os files.
>
> kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
> Symbol nt!TRIAGE_9F_POWER not found
>
>
> http://msdn.microsoft.com/en- us/library/windows/hardware/
> ff559329(v=vs.85).aspxhttp:tells how to use it…
>
> -pro
>
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
></http:></http:>

Scott_Noone_OSR · April 5, 2012, 1:48pm

Blocked threads a probably the interesting ones. What’s the output of:

!irp fffffa8007e37010

You mentioned earlier that this was a filter driver. Any chance it’s a KMDF
filter driver and you have KMDF Verifier enabled?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
0: kd> !analyze -v

Bugcheck Analysis

******

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually
10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too
long a time
Arg2: fffffa80054ca050, Physical Device Object of the stack
Arg3: fffff80000b9c518, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional
Device Object of the stack
Arg4: fffffa8007e37010, The blocked IRP

Debugging Details:
------------------

*** ERROR: Module load completed but symbols could not be loaded for
ahcix64.sys
TRIAGER: Could not open triage file : C:\Debuggers\x64\triage\modclass.ini,
error 2

DRVPOWERSTATE_SUBCODE: 3

DRIVER_OBJECT: fffffa8003accc90

IMAGE_NAME: ahcix64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4c9b227e

MODULE_NAME: ahcix64

FAULTING_MODULE: fffff88001039000 ahcix64

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: System

CURRENT_IRQL: f

STACK_TEXT:
fffff80000b9bd58 fffff80002bb8d92 : fffffa800738cea0 0000000000000000
0000000000000000 fffffa8007a6d000 : nt!RtlpBreakWithStatusInstruction
fffff80000b9bd60 fffff80002bba158 : fffff80000000004 fffff80002cc9b80
000000000000000f fffff80002c51cc0 : nt!KiBugCheckDebugBreak+0x12
fffff80000b9bdc0 fffff80002ad1744 : fffffa8008021260 fffff80002b7e054
fffff80000000068 0000000000000004 : nt!KeBugCheck2+0xcf8
fffff80000b9c490 fffff80002b3db52 : 000000000000009f 0000000000000003
fffffa80054ca050 fffff80000b9c518 : nt!KeBugCheckEx+0x104
fffff80000b9c4d0 fffff80002add062 : fffff80000b9c600 fffff80000b9c600
0000000000000001 0000000000000001 : nt! ?? ::FNODOBFM::string'+0x34a90 fffff80000b9c570 fffff80002adcf06 : fffff80002c79740 0000000000025385 0000000000000000 0000000000000000 : nt!KiProcessTimerDpcTable+0x66 fffff80000b9c5e0 fffff80002adcdee : 0000000589921c88 fffff80000b9cc58 0000000000025385 fffff80002c47328 : nt!KiProcessExpiredTimerList+0xc6 fffff80000b9cc30 fffff80002adcbd7 : 00000002150b0fc1 0000000200025385 00000002150b0f37 0000000000000085 : nt!KiTimerExpiration+0x1be fffff80000b9ccd0 fffff80002ac936a : fffff80002c43e80 fffff80002c51cc0 fffff80000000001 fffff88000000000 : nt!KiRetireDpcList+0x277 fffff80000b9cd80 0000000000000000 : fffff80000b9d000 fffff80000b97000 fffff80000b9cd40 00000000`00000000 : nt!KiIdleLoop+0x5a

0: kd> !stacks
Proc.Thread .Thread Ticks ThreadState Blocker
[fffff80002c521c0 Idle]
0.000000 fffff80002c51cc0 0000000 RUNNING
nt!RtlpBreakWithStatusInstruction
0.000000 fffff880009fe040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff88002f6f040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff88002fe0040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff880009bd040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
0.000000 fffff88003093040 ffffdd5b RUNNING amdppm!ReadIoMemRaw+0x30

[… rest of the threads are BLOCKED]

Yes I know the structure, and am going to try to peel off the infos…

-pro

On Thu, Apr 5, 2012 at 6:21 AM, Scott Noone wrote:
I don’t have this data type in my symbols either, I filed a bug against the
documentation at least.

Luckily the article provides output of the command working with private
symbols though, so you know the structure layout:

0: kd> dt nt!TRIAGE_9F_POWER 82b5dae0
+0x000 Signature : 0x8000
+0x002 Revision : 1
+0x004 IrpList : 0x82b78480 _LIST_ENTRY
+0x008 ThreadList : 0x82b77f28 _LIST_ENTRY
+0x00c DelayedWorkQueue : 0x82b715bc _TRIAGE_EX_WORK_QUEUE

What’s the bugcheck information for the new crash?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
One thing I was trying to find is the type nt!TRIAGE_9F_POWER this is for a
different crash ( after modifying the hiberfile size configuration, now it
is 100% of the memory installed ).

But on 64bit Win 7, and I understand I’ve stripped os files.

kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
Symbol nt!TRIAGE_9F_POWER not found

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559329(v=vs.85).aspx
tells how to use it…

-pro

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Scott_Noone_OSR · April 5, 2012, 1:55pm

“Scott Noone” wrote in message news:xxxxx@windbg…

You mentioned earlier that this was a filter driver. Any chance it’s a KMDF
filter driver and you have KMDF Verifier enabled?

Spoke too soon…Never mind this, I was thinking of an unrelated timeout
bugcheck around hiber resume (WDF_VIOLATION).

!irp output and full output of !stacks 2 would be useful here though.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

Prokash_Sinha · April 5, 2012, 2:03pm

As usual… Thanks Scott

No it is not a KMDF filter driver, wish it were

0: kd> !irp fffffa8007e37010
Irp is active with 3 stacks 2 is current (= 0xfffffa8007e37128)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[16, 2] 0 e1 fffffa80054ca050 00000000 00000000-00000000 pending
\Driver\ahcix64 (IopUnloadSafeCompletion)
Args: 00000000 00000001 00000004 00000000
[0, 0] 0 0 00000000 00000000 00000000-fffffa8008021260

Args: 00000000 00000000 00000000 00000000

On Thu, Apr 5, 2012 at 10:48 AM, Scott Noone wrote:

> Blocked threads a probably the interesting ones. What’s the output of:
>
> !irp fffffa8007e37010
>
> You mentioned earlier that this was a filter driver. Any chance it’s a
> KMDF filter driver and you have KMDF Verifier enabled?
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> 0: kd> !analyze -v
> *********************************************
>
> * *
> * Bugcheck Analysis *
> * *
> *********************************************
>
>
> DRIVER_POWER_STATE_FAILURE (9f)
> A driver has failed to complete a power IRP within a specific time
> (usually 10 minutes).
> Arguments:
> Arg1: 0000000000000003, A device object has been blocking an Irp for too
> long a time
> Arg2: fffffa80054ca050, Physical Device Object of the stack
> Arg3: fffff80000b9c518, nt!TRIAGE_9F_POWER on Win7, otherwise the
> Functional Device Object of the stack
> Arg4: fffffa8007e37010, The blocked IRP
>
> Debugging Details:
> ------------------
>
> ERROR: Module load completed but symbols could not be loaded for
> ahcix64.sys
> TRIAGER: Could not open triage file : C:\Debuggers\x64\triage* modclass.ini,
> error 2
>
> DRVPOWERSTATE_SUBCODE: 3
>
> DRIVER_OBJECT: fffffa8003accc90
>
> IMAGE_NAME: ahcix64.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4c9b227e
>
> MODULE_NAME: ahcix64
>
> FAULTING_MODULE: fffff88001039000 ahcix64
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> BUGCHECK_STR: 0x9F
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: f
>
> STACK_TEXT:
> fffff80000b9bd58 fffff80002bb8d92 : fffffa800738cea0 0000000000000000
> 0000000000000000 fffffa8007a6d000 : nt! RtlpBreakWithStatusInstruction
> fffff80000b9bd60 fffff80002bba158 : fffff80000000004 fffff80002cc9b80
> 000000000000000f fffff80002c51cc0 : nt!KiBugCheckDebugBreak+0x12
> fffff80000b9bdc0 fffff80002ad1744 : fffffa8008021260 fffff80002b7e054
> fffff80000000068 0000000000000004 : nt!KeBugCheck2+0xcf8
> fffff80000b9c490 fffff80002b3db52 : 000000000000009f 0000000000000003
> fffffa80054ca050 fffff80000b9c518 : nt!KeBugCheckEx+0x104
> fffff80000b9c4d0 fffff80002add062 : fffff80000b9c600 fffff80000b9c600
> 0000000000000001 0000000000000001 : nt! ?? ::FNODOBFM::string'+0x34a90 > fffff80000b9c570 fffff80002adcf06 : fffff80002c79740 0000000000025385 > 0000000000000000 0000000000000000 : nt!KiProcessTimerDpcTable+0x66 > fffff80000b9c5e0 fffff80002adcdee : 0000000589921c88 fffff80000b9cc58 > 0000000000025385 fffff80002c47328 : nt!KiProcessExpiredTimerList+** 0xc6 > fffff80000b9cc30 fffff80002adcbd7 : 00000002150b0fc1 0000000200025385 > 00000002150b0f37 0000000000000085 : nt!KiTimerExpiration+0x1be > fffff80000b9ccd0 fffff80002ac936a : fffff80002c43e80 fffff80002c51cc0 > fffff80000000001 fffff88000000000 : nt!KiRetireDpcList+0x277 > fffff80000b9cd80 0000000000000000 : fffff80000b9d000 fffff80000b97000 > fffff80000b9cd40 00000000`00000000 : nt!KiIdleLoop+0x5a
>
> 0: kd> !stacks
> Proc.Thread .Thread Ticks ThreadState Blocker
> [fffff80002c521c0 Idle]
> 0.000000 fffff80002c51cc0 0000000 RUNNING nt!
> RtlpBreakWithStatusInstruction
> 0.000000 fffff880009fe040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
> 0.000000 fffff88002f6f040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
> 0.000000 fffff88002fe0040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
> 0.000000 fffff880009bd040 0000000 RUNNING amdppm!ReadIoMemRaw+0x30
> 0.000000 fffff88003093040 ffffdd5b RUNNING amdppm!ReadIoMemRaw+0x30
>
> [… rest of the threads are BLOCKED]
>
>
> Yes I know the structure, and am going to try to peel off the infos…
>
> -pro
>
> On Thu, Apr 5, 2012 at 6:21 AM, Scott Noone wrote:
> I don?t have this data type in my symbols either, I filed a bug against
> the documentation at least.
>
> Luckily the article provides output of the command working with private
> symbols though, so you know the structure layout:
>
> 0: kd> dt nt!TRIAGE_9F_POWER 82b5dae0
> +0x000 Signature : 0x8000
> +0x002 Revision : 1
> +0x004 IrpList : 0x82b78480 _LIST_ENTRY
> +0x008 ThreadList : 0x82b77f28 _LIST_ENTRY
> +0x00c DelayedWorkQueue : 0x82b715bc _TRIAGE_EX_WORK_QUEUE
>
> What’s the bugcheck information for the new crash?
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
> One thing I was trying to find is the type nt!TRIAGE_9F_POWER this is for
> a different crash ( after modifying the hiberfile size configuration, now
> it is 100% of the memory installed ).
>
>
> But on 64bit Win 7, and I understand I’ve stripped os files.
>
> kd> 0: kd> dt nt!TRIAGE_9F_POWER fffff80000b9c518
> Symbol nt!TRIAGE_9F_POWER not found
>
>
> http://msdn.microsoft.com/en-**us/library/windows/hardware/
> ff559329(v=vs.85).aspxhttp:tells how to use it…
>
> -pro
>
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
></http:></http:></http:>

Prokash_Sinha · April 5, 2012, 2:43pm

Absolutely…

As I said earlier that it gave me some clue ( now I’m going to get the
!stacks 2 - which is bit more detail )…

The device Queue has a whole bunch of irp sitting there…

Le’me analyze a bit further.

0: kd> !irp fffffa8007e37010
Irp is active with 3 stacks 2 is current (= 0xfffffa8007e37128)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[16, 2] 0 e1 fffffa80054ca050 00000000 00000000-00000000 pending
\Driver\ahcix64 (IopUnloadSafeCompletion)
Args: 00000000 00000001 00000004 00000000
[0, 0] 0 0 00000000 00000000 00000000-fffffa8008021260

Args: 00000000 00000000 00000000 00000000
0: kd> !devobj fffffa80054ca050
Device object (fffffa80054ca050) is for:
ahcix641Port0Path0Target2Lun0 \Driver\ahcix64 DriverObject fffffa8003accc90
Current Irp 00000000 RefCount 1 Type 0000002d Flags 00001050
Dacl fffff9a100332ef0 DevExt fffffa80054ca1a0 DevObjExt fffffa80054cb420
Dope fffffa80048abfa0 DevNode fffffa80048b2d90
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa80048b1df0 \Driver\Xportfltr
DeviceQueue: fffffa8007761518 fffffa80080802a0 fffffa8007fd9490
fffffa8007fda010
fffffa8007fdab50 fffffa8007fda690 fffffa8007fdb010 fffffa8007fdbca0
fffffa8007fdb7e0 fffffa8007fd9950 fffffa8007fdde10 fffffa8007fdd950
fffffa8007fdd490 fffffa8008018010 fffffa8007fdc320 fffffa8008086950
fffffa800811fb50 fffffa800811f650 fffffa8008152010 fffffa8008152b50
fffffa800811f010 fffffa8008019010 fffffa8008019ca0 fffffa80080197e0
fffffa8008019320 fffffa800801aca0 fffffa800801a7e0 fffffa800801a320
fffffa8008018690 fffffa800805d950 fffffa800805d490 fffffa800805e010
fffffa800805eb50 fffffa800805e690 fffffa800805f010 fffffa800805fca0
fffffa800805de10 fffffa8007fd87e0 fffffa8007fd8320 fffffa8007fd8ca0
fffffa8008060ca0 fffffa80080607e0 fffffa80080602e0 fffffa8008080ca0
fffffa800805f2a0 fffffa800801b490 fffffa800801c010 fffffa800801cb50
fffffa800801c650 fffffa8008059010 fffffa8008059b50 fffffa8008059690
fffffa800801b950 fffffa800805a7e0 fffffa800805a320 fffffa800805bca0
fffffa800805b7e0 fffffa800805b320 fffffa800805ce10 fffffa800805c950
fffffa800805aca0 fffffa80080e17e0

Threads Processed: 591
0: kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr : Args to Child
: Call Site
fffff8800316f4b0 fffff80002ad6992 : fffffa8003a9c040 fffffa8003a9c040
0000000000000000 000000000000000f : nt!KiSwapContext+0x7a
fffff8800316f5f0 fffff80002ad91af : 0000000000000003 fffff8800103b339
fffffa8000000000 fffffa800399cf88 : nt!KiCommitThreadWait+0x1d2
fffff8800316f680 fffff880019b4882 : 0000000000000000 0000000000000000
fffffa8008887a00 fffffa8003c0d300 : nt!KeWaitForSingleObject+0x19f
fffff8800316f720 fffff880019b92e8 : fffffa8008887930 0000000000000000
fffffa80048ab8f0 000000000000001b :
Xportfltr!PortFltrForwardIrpSynchronous+0x92
fffff8800316f780 fffff80002e8817e : 0000000000000000 fffffa8008887930
fffffa800857be90 fffffa80048ab8f0 : Xportfltr!PortFltrDispatchPnp+0x1ac
fffff8800316f7f0 fffff80002e884ea : 0000000000000000 fffffa800857be90
fffff80002bc8250 0000000000000000 : nt!PnpAsynchronousCall+0xce
fffff8800316f830 fffff80002e8a837 : fffff80002ccd200 fffffa80039c0010
0000000000000002 0000000000000000 : nt!PnpQueryDeviceRelations+0xfa
fffff8800316f8f0 fffff80002ebae1c : fffffa80039c0010 fffffa8003a5003c
fffffa8003a56760 0000000000000002 : nt!PipEnumerateDevice+0x117
fffff8800316f950 fffff80002ebb428 : fffff80002ccadc0 0000000000000000
0000000000000001 fffff80002d3cc38 : nt!PipProcessDevNodeTree+0x21c
fffff8800316fbc0 fffff80002bcab97 : 0000000100000003 0000000000000000
0000000000000001 0000000000000000 : nt!PiProcessReenumeration+0x98
fffff8800316fc10 fffff80002adba21 : fffff80002bca870 fffff80002dc7f01
fffff880015a3000 fffffa8003a9c040 : nt!PnpDeviceActionWorker+0x327
fffff8800316fcb0 fffff80002d6ecce : 0000000000000000 fffffa8003a9c040
0000000000000080 fffffa80039f0040 : nt!ExpWorkerThread+0x111
fffff8800316fd40 fffff80002ac2fe6 : fffff88003088180 fffffa8003a9c040
fffff88003093040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff8800316fd80 0000000000000000 : fffff88003170000 fffff8800316a000
fffff8800316f470 0000000000000000 : nt!KiStartSystemThread+0x16

On Thu, Apr 5, 2012 at 10:56 AM, Scott Noone wrote:

> “Scott Noone” wrote in message news:xxxxx@windbg…
>
> You mentioned earlier that this was a filter driver. Any chance it’s a
>> KMDF filter driver and you have KMDF Verifier enabled?
>>
>
> Spoke too soon…Never mind this, I was thinking of an unrelated timeout
> bugcheck around hiber resume (WDF_VIOLATION).
>
> !irp output and full output of !stacks 2 would be useful here though.
>
>
> -scott
>
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
></http:>

Scott_Noone_OSR · April 5, 2012, 4:17pm

Any chance of making the dump available to me somehow? There’s a lot of
overall system state that I’d want to inspect and NNTP is the slowest of all
the KD protocols (though debugging a VM with a virtual COM port sent over a
network connection then pumped into a named pipe on my workstation is a
close second) .

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Prokash Sinha” wrote in message news:xxxxx@windbg…
Absolutely…

As I said earlier that it gave me some clue ( now I’m going to get the
!stacks 2 - which is bit more detail )…

The device Queue has a whole bunch of irp sitting there…

Le’me analyze a bit further.

0: kd> !irp fffffa8007e37010
Irp is active with 3 stacks 2 is current (= 0xfffffa8007e37128)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[16, 2] 0 e1 fffffa80054ca050 00000000 00000000-00000000 pending
\Driver\ahcix64 (IopUnloadSafeCompletion)
Args: 00000000 00000001 00000004 00000000
[0, 0] 0 0 00000000 00000000 00000000-fffffa8008021260

Args: 00000000 00000000 00000000 00000000
0: kd> !devobj fffffa80054ca050
Device object (fffffa80054ca050) is for:
ahcix641Port0Path0Target2Lun0 \Driver\ahcix64 DriverObject fffffa8003accc90
Current Irp 00000000 RefCount 1 Type 0000002d Flags 00001050
Dacl fffff9a100332ef0 DevExt fffffa80054ca1a0 DevObjExt fffffa80054cb420
Dope fffffa80048abfa0 DevNode fffffa80048b2d90
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa80048b1df0 \Driver\Xportfltr
DeviceQueue: fffffa8007761518 fffffa80080802a0 fffffa8007fd9490
fffffa8007fda010
fffffa8007fdab50 fffffa8007fda690 fffffa8007fdb010 fffffa8007fdbca0
fffffa8007fdb7e0 fffffa8007fd9950 fffffa8007fdde10 fffffa8007fdd950
fffffa8007fdd490 fffffa8008018010 fffffa8007fdc320 fffffa8008086950
fffffa800811fb50 fffffa800811f650 fffffa8008152010 fffffa8008152b50
fffffa800811f010 fffffa8008019010 fffffa8008019ca0 fffffa80080197e0
fffffa8008019320 fffffa800801aca0 fffffa800801a7e0 fffffa800801a320
fffffa8008018690 fffffa800805d950 fffffa800805d490 fffffa800805e010
fffffa800805eb50 fffffa800805e690 fffffa800805f010 fffffa800805fca0
fffffa800805de10 fffffa8007fd87e0 fffffa8007fd8320 fffffa8007fd8ca0
fffffa8008060ca0 fffffa80080607e0 fffffa80080602e0 fffffa8008080ca0
fffffa800805f2a0 fffffa800801b490 fffffa800801c010 fffffa800801cb50
fffffa800801c650 fffffa8008059010 fffffa8008059b50 fffffa8008059690
fffffa800801b950 fffffa800805a7e0 fffffa800805a320 fffffa800805bca0
fffffa800805b7e0 fffffa800805b320 fffffa800805ce10 fffffa800805c950
fffffa800805aca0 fffffa80080e17e0

Threads Processed: 591
0: kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr : Args to Child
: Call Site
fffff8800316f4b0 fffff80002ad6992 : fffffa8003a9c040 fffffa8003a9c040
0000000000000000 000000000000000f : nt!KiSwapContext+0x7a
fffff8800316f5f0 fffff80002ad91af : 0000000000000003 fffff8800103b339
fffffa8000000000 fffffa800399cf88 : nt!KiCommitThreadWait+0x1d2
fffff8800316f680 fffff880019b4882 : 0000000000000000 0000000000000000
fffffa8008887a00 fffffa8003c0d300 : nt!KeWaitForSingleObject+0x19f
fffff8800316f720 fffff880019b92e8 : fffffa8008887930 0000000000000000
fffffa80048ab8f0 000000000000001b :
Xportfltr!PortFltrForwardIrpSynchronous+0x92
fffff8800316f780 fffff80002e8817e : 0000000000000000 fffffa8008887930
fffffa800857be90 fffffa80048ab8f0 : Xportfltr!PortFltrDispatchPnp+0x1ac
fffff8800316f7f0 fffff80002e884ea : 0000000000000000 fffffa800857be90
fffff80002bc8250 0000000000000000 : nt!PnpAsynchronousCall+0xce
fffff8800316f830 fffff80002e8a837 : fffff80002ccd200 fffffa80039c0010
0000000000000002 0000000000000000 : nt!PnpQueryDeviceRelations+0xfa
fffff8800316f8f0 fffff80002ebae1c : fffffa80039c0010 fffffa8003a5003c
fffffa8003a56760 0000000000000002 : nt!PipEnumerateDevice+0x117
fffff8800316f950 fffff80002ebb428 : fffff80002ccadc0 0000000000000000
0000000000000001 fffff80002d3cc38 : nt!PipProcessDevNodeTree+0x21c
fffff8800316fbc0 fffff80002bcab97 : 0000000100000003 0000000000000000
0000000000000001 0000000000000000 : nt!PiProcessReenumeration+0x98
fffff8800316fc10 fffff80002adba21 : fffff80002bca870 fffff80002dc7f01
fffff880015a3000 fffffa8003a9c040 : nt!PnpDeviceActionWorker+0x327
fffff8800316fcb0 fffff80002d6ecce : 0000000000000000 fffffa8003a9c040
0000000000000080 fffffa80039f0040 : nt!ExpWorkerThread+0x111
fffff8800316fd40 fffff80002ac2fe6 : fffff88003088180 fffffa8003a9c040
fffff88003093040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff8800316fd80 0000000000000000 : fffff88003170000 fffff8800316a000
fffff8800316f470 0000000000000000 : nt!KiStartSystemThread+0x16

On Thu, Apr 5, 2012 at 10:56 AM, Scott Noone wrote:
“Scott Noone” wrote in message news:xxxxx@windbg…

You mentioned earlier that this was a filter driver. Any chance it’s a KMDF
filter driver and you have KMDF Verifier enabled?

Spoke too soon…Never mind this, I was thinking of an unrelated timeout
bugcheck around hiber resume (WDF_VIOLATION).

!irp output and full output of !stacks 2 would be useful here though.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Prokash_Sinha · April 5, 2012, 4:39pm

What would be best way, you think?

If I could upload somewhere, where you can look at it, that would be
great…

Le’me know the steps, pls…

-pro

On Thu, Apr 5, 2012 at 1:18 PM, Scott Noone wrote:

> Any chance of making the dump available to me somehow? There’s a lot of
> overall system state that I’d want to inspect and NNTP is the slowest of
> all the KD protocols (though debugging a VM with a virtual COM port sent
> over a network connection then pumped into a named pipe on my workstation
> is a close second) .
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Prokash Sinha” wrote in message news:xxxxx@windbg…
>
> Absolutely…
>
> As I said earlier that it gave me some clue ( now I’m going to get the
> !stacks 2 - which is bit more detail )…
>
> The device Queue has a whole bunch of irp sitting there…
>
> Le’me analyze a bit further.
>
> 0: kd> !irp fffffa8007e37010
> Irp is active with 3 stacks 2 is current (= 0xfffffa8007e37128)
> No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>
>> [16, 2] 0 e1 fffffa80054ca050 00000000 00000000-00000000 pending
>>
> \Driver\ahcix64 (IopUnloadSafeCompletion)
> Args: 00000000 00000001 00000004 00000000
> [0, 0] 0 0 00000000 00000000 00000000-fffffa8008021260
>
> Args: 00000000 00000000 00000000 00000000
> 0: kd> !devobj fffffa80054ca050
> Device object (fffffa80054ca050) is for:
> ahcix641Port0Path0Target2Lun0 \Driver\ahcix64 DriverObject fffffa8003accc90
> Current Irp 00000000 RefCount 1 Type 0000002d Flags 00001050
> Dacl fffff9a100332ef0 DevExt fffffa80054ca1a0 DevObjExt fffffa80054cb420
> Dope fffffa80048abfa0 DevNode fffffa80048b2d90
> ExtensionFlags (0x00000800)
> Unknown flags 0x00000800
> AttachedDevice (Upper) fffffa80048b1df0 \Driver\Xportfltr
> DeviceQueue: fffffa8007761518 fffffa80080802a0 fffffa8007fd9490
> fffffa8007fda010
> fffffa8007fdab50 fffffa8007fda690 fffffa8007fdb010 fffffa8007fdbca0
> fffffa8007fdb7e0 fffffa8007fd9950 fffffa8007fdde10 fffffa8007fdd950
> fffffa8007fdd490 fffffa8008018010 fffffa8007fdc320 fffffa8008086950
> fffffa800811fb50 fffffa800811f650 fffffa8008152010 fffffa8008152b50
> fffffa800811f010 fffffa8008019010 fffffa8008019ca0 fffffa80080197e0
> fffffa8008019320 fffffa800801aca0 fffffa800801a7e0 fffffa800801a320
> fffffa8008018690 fffffa800805d950 fffffa800805d490 fffffa800805e010
> fffffa800805eb50 fffffa800805e690 fffffa800805f010 fffffa800805fca0
> fffffa800805de10 fffffa8007fd87e0 fffffa8007fd8320 fffffa8007fd8ca0
> fffffa8008060ca0 fffffa80080607e0 fffffa80080602e0 fffffa8008080ca0
> fffffa800805f2a0 fffffa800801b490 fffffa800801c010 fffffa800801cb50
> fffffa800801c650 fffffa8008059010 fffffa8008059b50 fffffa8008059690
> fffffa800801b950 fffffa800805a7e0 fffffa800805a320 fffffa800805bca0
> fffffa800805b7e0 fffffa800805b320 fffffa800805ce10 fffffa800805c950
> fffffa800805aca0 fffffa80080e17e0
>
> Threads Processed: 591
> 0: kd> kv
> *Stack trace for last set context - .thread/.cxr resets it
> Child-SP RetAddr : Args to Child : Call Site
> fffff8800316f4b0 fffff80002ad6992 : fffffa8003a9c040 fffffa8003a9c040
> 0000000000000000 000000000000000f : nt!KiSwapContext+0x7a
> fffff8800316f5f0 fffff80002ad91af : 0000000000000003 fffff8800103b339
> fffffa8000000000 fffffa800399cf88 : nt!KiCommitThreadWait+0x1d2
> fffff8800316f680 fffff880019b4882 : 0000000000000000 0000000000000000
> fffffa8008887a00 fffffa8003c0d300 : nt!KeWaitForSingleObject+0x19f
> fffff8800316f720 fffff880019b92e8 : fffffa8008887930 0000000000000000
> fffffa80048ab8f0 000000000000001b : Xportfltr!
> PortFltrForwardIrpSynchronous+ 0x92
> fffff8800316f780 fffff80002e8817e : 0000000000000000 fffffa8008887930
> fffffa800857be90 fffffa80048ab8f0 : Xportfltr!PortFltrDispatchPnp+
> 0x1ac
> fffff8800316f7f0 fffff80002e884ea : 0000000000000000 fffffa800857be90
> fffff80002bc8250 0000000000000000 : nt!PnpAsynchronousCall+0xce
> fffff8800316f830 fffff80002e8a837 : fffff80002ccd200 fffffa80039c0010
> 0000000000000002 0000000000000000 : nt!PnpQueryDeviceRelations+**0xfa
> fffff8800316f8f0 fffff80002ebae1c : fffffa80039c0010 fffffa8003a5003c
> fffffa8003a56760 0000000000000002 : nt!PipEnumerateDevice+0x117
> fffff8800316f950 fffff80002ebb428 : fffff80002ccadc0 0000000000000000
> 0000000000000001 fffff80002d3cc38 : nt!PipProcessDevNodeTree+0x21c
> fffff8800316fbc0 fffff80002bcab97 : 0000000100000003 0000000000000000
> 0000000000000001 0000000000000000 : nt!PiProcessReenumeration+0x98
> fffff8800316fc10 fffff80002adba21 : fffff80002bca870 fffff80002dc7f01
> fffff880015a3000 fffffa8003a9c040 : nt!PnpDeviceActionWorker+0x327
> fffff8800316fcb0 fffff80002d6ecce : 0000000000000000 fffffa8003a9c040
> 0000000000000080 fffffa80039f0040 : nt!ExpWorkerThread+0x111
> fffff8800316fd40 fffff80002ac2fe6 : fffff88003088180 fffffa8003a9c040
> fffff88003093040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
> fffff8800316fd80 0000000000000000 : fffff88003170000 fffff8800316a000
> fffff8800316f470 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
>
>
> On Thu, Apr 5, 2012 at 10:56 AM, Scott Noone wrote:
> “Scott Noone” wrote in message news:xxxxx@windbg…
>
> You mentioned earlier that this was a filter driver. Any chance it’s a
> KMDF filter driver and you have KMDF Verifier enabled?
>
> Spoke too soon…Never mind this, I was thinking of an unrelated timeout
> bugcheck around hiber resume (WDF_VIOLATION).
>
> !irp output and full output of !stacks 2 would be useful here though.
>
>
> -scott
>
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServer http:
></http:></http:>