DRIVER_POWER_STATE_FAILURE

NTDEV
1

Hello there,

I am implementing hibernate feature of my Windows PV drivers for Xen. My bus driver will enumerate network and disk child devices which are serviced by a NDIS miniport and SCSI miniport drivers. The problem I meet is that if I attach 1 disk and 1 network device. My disk driver can pass Sleep Stress with I/O test case, which will hibernate and resume system for several times. But if I attach 7 disk and 1 network device, system can be hibernated and resumed for 2 times but BSOD with error code 0x9F in my bus driver when system resumes from hibernation for the 3rd time. From memory dump file analyzing, my bus driver blocks a set power IRP for a child device PDO. In that routine, I just set IRP status to success and call IoCompleleRequest to finish the IRP. It seems that some IRP complete routine block that IRP. Why does it just happen in a multi disk system? How can I address the problem?

WLK version: 1.5

WDK version: 7600.16385.0

OS version: Windows server 2008 x86 with SP2

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)

A driver is causing an inconsistent power state.

Arguments:

Arg1: 00000003, A device object has been blocking an Irp for too long a time

Arg2: 86316030, Physical Device Object of the stack

Arg3: 863bc018, Functional Device Object of the stack

Arg4: 97aecf20, The blocked IRP

Debugging Details:

PEB is paged out (Peb.Ldr = 7ffd800c). Type “.hh dbgerr001” for details

PEB is paged out (Peb.Ldr = 7ffd800c). Type “.hh dbgerr001” for details

DRVPOWERSTATE_SUBCODE: 3

IRP_ADDRESS: 97aecf20

DEVICE_OBJECT: 863bc018

DRIVER_OBJECT: 8631bb48

IMAGE_NAME: mybus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ba89595

MODULE_NAME: mybus

FAULTING_MODULE: 8250c000 mybus

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: cscript.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 8184a3fb to 818e6b8d

STACK_TEXT:

8039dd6c 8184a3fb 0000009f 00000003 86316030 nt!KeBugCheckEx+0x1e

8039ddc8 8184a018 8039de40 81913878 81913800 nt!PopCheckIrpWatchdog+0x1ad

8039de08 818c330b 819274e0 00000000 97dcf31a nt!PopCheckForIdleness+0x343

8039df28 818c2ecb 8039df70 00000002 8039df78 nt!KiTimerListExpire+0x367

8039df88 818c3635 00000000 00000000 00045656 nt!KiTimerExpiration+0x22a

8039dff4 818c12f5 94c7dbf0 00000000 00000000 nt!KiRetireDpcList+0xba

8039dff8 94c7dbf0 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x45

WARNING: Frame IP not in any known module. Following frames may be wrong.

818c12f5 00000000 0000001b 00c7850f bb830000 0x94c7dbf0

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0x9F_VRF_IMAGE_mybus.sys

BUCKET_ID: 0x9F_VRF_IMAGE_mybus.sys

Followup: MachineOwner

0: kd> !irql

Debugger saved IRQL for processor 0x0 – 2 (DISPATCH_LEVEL)

0: kd> !irp 97aecf20

Irp is active with 3 stacks 2 is current (= 0x97aecfb4)

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 863bc018 00000000 81af1bf3-93aa4760 Success Error Cancel pending

\Driver\mybus nt!PopSystemIrpCompletion

Args: 00015500 00000000 00000005 00000003

[0, 0] 0 0 00000000 00000000 00000000-93aa4760

Args: 00000000 00000000 00000000 00000000

0: kd> !devobj 86316030

Device object (86316030) is for:

NTPNP_PCI0006 \Driver\pci DriverObject 862e1b28

Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040

Dacl 85970e90 DevExt 863160e8 DevObjExt 86316480 DevNode 863138b0

ExtensionFlags (0x80000000) DOE_DESIGNATED_FDO

AttachedDevice (Upper) 863bc018 \Driver\mybus

Device queue is not busy.

0: kd> !devobj 863bc018

Device object (863bc018) is for:

\Driver\mybus DriverObject 8631bb48

Current Irp 00000000 RefCount 0 Type 00000022 Flags 00000000

DevExt 863bc0d0 DevObjExt 863c2050

ExtensionFlags (0xb0000800) DOE_RAW_FDO, DOE_DESIGNATED_FDO

Unknown flags 0x10000800

AttachedTo (Lower) 86316030 \Driver\pci

Device queue is not busy.

--------------end---------------

Any more info you need, please let me know.

Thanks

Wayne

2

From the analysis it’s your FDO that blocks the IRP, not your child PDO.

3

Sorry, I made a mistake. Some resource will be exhausted if I attach lots of child devices.

Thanks
Wayne

4

Are you using work items in the power up path? Have you !poreqlist and !poaction to see what the current outstanding power irps are? Have you run !stacks to see what every thread is doing?

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Wayne Gong
Sent: Thursday, March 25, 2010 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE

Sorry, I made a mistake. Some resource will be exhausted if I attach lots of child devices.

Thanks
Wayne

—
NTDEV 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

5

> Are you using work items in the power up path? Have you !poreqlist

and !poaction to see what the current outstanding power irps are? Have you
run !stacks to see what every thread is doing?

I didn’t use work items in power up path.
I’ve figured out what’s the problem. When I wake up my child device, it will allocate some resource from bus driver. I made some stupid fault that didn’t release such resource when powering down child device. Then resource will be exhausted if I attach lots of child device and hibernate/resume system for several times. Now hibernate feature should work fine. Running WHQL test to confirm it.

Thanks
Wayne

6

God forbid you use system workitem in a paging device path. Because of
someone’s thing for saving non-paged memory, the worker threads wait in a
mode that allows their stack to swap out. Been there seen that. At least
under Windows 2003. Not sure if that’s still the case in 2008+.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Are you using work items in the power up path? Have you !poreqlist and
!poaction to see what the current outstanding power irps are? Have you run
!stacks to see what every thread is doing?

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Wayne Gong
Sent: Thursday, March 25, 2010 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE

Sorry, I made a mistake. Some resource will be exhausted if I attach lots of
child devices.

Thanks
Wayne

—
NTDEV 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

7

No, the worker threads do not do a user mode (unless that is the actual work item callback which does the wait) in the worker item thread pool. The problem is that you can get stuck behind a work item which is in the middle of processing a page fault (by touching paged pool or code). If you are the paging device and you must be the one to service the page fault, but are stuck behind that item, you dead lock.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alexander Grigoriev
Sent: Thursday, March 25, 2010 8:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DRIVER_POWER_STATE_FAILURE

God forbid you use system workitem in a paging device path. Because of someone’s thing for saving non-paged memory, the worker threads wait in a mode that allows their stack to swap out. Been there seen that. At least under Windows 2003. Not sure if that’s still the case in 2008+.

“Doron Holan” wrote in message news:xxxxx@ntdev…
Are you using work items in the power up path? Have you !poreqlist and !poaction to see what the current outstanding power irps are? Have you run !stacks to see what every thread is doing?

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Wayne Gong
Sent: Thursday, March 25, 2010 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE

Sorry, I made a mistake. Some resource will be exhausted if I attach lots of child devices.

Thanks
Wayne

—
NTDEV 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

—
NTDEV 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

8

Then why the debugger was showing “stack swapped out”, and the thread was
deadlocked waiting for paging in(while being queued a workitem necessary for
a driver to bring the paging path up).

“Doron Holan” wrote in message
news:xxxxx@ntdev…
No, the worker threads do not do a user mode (unless that is the actual work
item callback which does the wait) in the worker item thread pool. The
problem is that you can get stuck behind a work item which is in the middle
of processing a page fault (by touching paged pool or code). If you are the
paging device and you must be the one to service the page fault, but are
stuck behind that item, you dead lock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexander Grigoriev
Sent: Thursday, March 25, 2010 8:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DRIVER_POWER_STATE_FAILURE

God forbid you use system workitem in a paging device path. Because of
someone’s thing for saving non-paged memory, the worker threads wait in a
mode that allows their stack to swap out. Been there seen that. At least
under Windows 2003. Not sure if that’s still the case in 2008+.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Are you using work items in the power up path? Have you !poreqlist and
!poaction to see what the current outstanding power irps are? Have you run
!stacks to see what every thread is doing?

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Wayne Gong
Sent: Thursday, March 25, 2010 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE

Sorry, I made a mistake. Some resource will be exhausted if I attach lots of
child devices.

Thanks
Wayne

—
NTDEV 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

—
NTDEV 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

9

Oh, and by the way, Win 2008 is still doing that. Do !stacks 1 on a box
that’s been heavily exercised.

“Alexander Grigoriev” wrote in message
news:xxxxx@ntdev…
> Then why the debugger was showing “stack swapped out”, and the thread was
> deadlocked waiting for paging in(while being queued a workitem necessary
> for a driver to bring the paging path up).
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> No, the worker threads do not do a user mode (unless that is the actual
> work item callback which does the wait) in the worker item thread pool.
> The problem is that you can get stuck behind a work item which is in the
> middle of processing a page fault (by touching paged pool or code). If
> you are the paging device and you must be the one to service the page
> fault, but are stuck behind that item, you dead lock.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexander
> Grigoriev
> Sent: Thursday, March 25, 2010 8:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DRIVER_POWER_STATE_FAILURE
>
> God forbid you use system workitem in a paging device path. Because of
> someone’s thing for saving non-paged memory, the worker threads wait in a
> mode that allows their stack to swap out. Been there seen that. At least
> under Windows 2003. Not sure if that’s still the case in 2008+.
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Are you using work items in the power up path? Have you !poreqlist and
> !poaction to see what the current outstanding power irps are? Have you run
> !stacks to see what every thread is doing?
>
> d
>
> tiny phone keyboard + fat thumbs = you do the muth
>
>
>
> -----Original Message-----
> From: Wayne Gong
> Sent: Thursday, March 25, 2010 7:35 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE
>
>
> Sorry, I made a mistake. Some resource will be exhausted if I attach lots
> of child devices.
>
> Thanks
> Wayne
>
> —
> NTDEV 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
>
>
>
>
> —
> NTDEV 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
>
>
>
>

10

Stack please

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Alexander Grigoriev
Sent: Friday, March 26, 2010 7:14 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:DRIVER_POWER_STATE_FAILURE

Oh, and by the way, Win 2008 is still doing that. Do !stacks 1 on a box
that’s been heavily exercised.

“Alexander Grigoriev” wrote in message
news:xxxxx@ntdev…
> Then why the debugger was showing “stack swapped out”, and the thread was
> deadlocked waiting for paging in(while being queued a workitem necessary
> for a driver to bring the paging path up).
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> No, the worker threads do not do a user mode (unless that is the actual
> work item callback which does the wait) in the worker item thread pool.
> The problem is that you can get stuck behind a work item which is in the
> middle of processing a page fault (by touching paged pool or code). If
> you are the paging device and you must be the one to service the page
> fault, but are stuck behind that item, you dead lock.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexander
> Grigoriev
> Sent: Thursday, March 25, 2010 8:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DRIVER_POWER_STATE_FAILURE
>
> God forbid you use system workitem in a paging device path. Because of
> someone’s thing for saving non-paged memory, the worker threads wait in a
> mode that allows their stack to swap out. Been there seen that. At least
> under Windows 2003. Not sure if that’s still the case in 2008+.
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Are you using work items in the power up path? Have you !poreqlist and
> !poaction to see what the current outstanding power irps are? Have you run
> !stacks to see what every thread is doing?
>
> d
>
> tiny phone keyboard + fat thumbs = you do the muth
>
>
>
> -----Original Message-----
> From: Wayne Gong
> Sent: Thursday, March 25, 2010 7:35 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE
>
>
> Sorry, I made a mistake. Some resource will be exhausted if I attach lots
> of child devices.
>
> Thanks
> Wayne
>
> —
> NTDEV 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
>
>
>
>
> —
> NTDEV 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
>
>
>
>

—
NTDEV 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

11

4: kd> vertarget
Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP (8
procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 6002.18160.x86fre.vistasp2_gdr.091208-0542
Machine Name:
Kernel base = 0x8200d000 PsLoadedModuleList = 0x82124c70
Debug session time: Sat Mar 27 08:03:56.715 2010 (UTC - 7:00)
System Uptime: 9 days 20:56:29.874
4: kd> !stacks 1
Proc.Thread .Thread Ticks ThreadState Blocker

Max cache size is : 1048576 bytes (0x400 KB)
Total memory in cache : 0 bytes (0 KB)
Number of regions cached: 0
0 full reads broken into 0 partial reads
counts: 0 cached/0 uncached, 0.00% cached
bytes : 0 cached/0 uncached, 0.00% cached
** Prototype PTEs are implicitly decoded
[85c03c10 System]
4.000008 85c03968 000552e GATEWAIT nt!MmZeroPageThread+0x129
4.000010 85c04020 3425393 Blocked nt!PopIrpWorkerControl+0x25
4.000014 85c04d78 34064c3 Blocked nt!PopIrpWorker+0x129
4.000018 85c04ad0 34249aa Blocked nt!PopIrpWorker+0x129
4.00001c 85c05020 3425393 Blocked nt!ExpWorkerThread+0xd5
4.000020 85c05d78 3425393 Blocked nt!ExpWorkerThread+0xd5
4.000024 85c05ad0 00102e6 Blocked nt!ExpWorkerThread+0xd5
4.000028 85c05828 0010b00 Blocked nt!ExpWorkerThread+0xd5
4.00002c 85c05580 0061245 Blocked nt!ExpWorkerThread+0xd5
4.000030 85c052d8 0000076 Blocked nt!ExpWorkerThread+0xd5
4.000034 85c06020 0001eb6 Blocked nt!ExpWorkerThread+0xd5
4.000038 85c06d78 0061245 Blocked nt!ExpWorkerThread+0xd5
4.00003c 85c06ad0 0010b00 Blocked nt!ExpWorkerThread+0xd5
4.000040 85c06828 0010b00 Blocked nt!ExpWorkerThread+0xd5
4.000044 85c06580 000026c Blocked nt!ExpWorkerThread+0xd5
4.000048 85c062d8 0048987 Blocked Stack paged out
4.00004c 85c07020 0befc64 Blocked Stack paged out
4.000050 85c07d78 3424943 Blocked Stack paged out
4.000054 85c07ad0 000000a Blocked nt!ExpWorkerThread+0xd5
4.000058 85c07828 34240d0 Blocked Stack paged out
4.00005c 85c07580 0007acc Blocked Stack paged out
4.000060 85c072d8 00003ad Blocked nt!ExpWorkerThread+0xd5
4.000064 85c08020 0000025 Blocked
nt!ExpWorkerThreadBalanceManager+0x68

4: kd> !thread 85c06580
THREAD 85c06580 Cid 0004.0044 Teb: 00000000 Win32Thread: 00000000 WAIT:
(WrQueue) UserMode Non-Alertable
8210f13c QueueObject
Not impersonating
DeviceMap 8e4086a0
Owning Process 85c03c10 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 54677867 Ticks: 620 (0:00:00:09.672)
Context Switch Count 976903
UserTime 00:00:00.000
KernelTime 00:00:11.996
Win32 Start Address nt!ExpWorkerThread (0x820b2d25)
Stack Init 8e892000 Current 8e891c70 Base 8e892000 Limit 8e88f000 Call 0
Priority 13 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
8e891c88 820b9352 85c06580 8e7bc120 85c06608 nt!KiSwapContext+0x26 (FPO:
[Uses EBP] [0,0,4])
8e891ccc 820b3744 85c06580 8210f13c 85c06580 nt!KiSwapThread+0x44f
8e891d30 820b2dfa 8210f13c 00000001 00000000 nt!KeRemoveQueueEx+0x741
8e891d7c 821e2c42 9f8808f8 5e431c90 00000000 nt!ExpWorkerThread+0xd5
8e891dc0 8204bf4e 820b2d25 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

4: kd> !thread 85c062d8
THREAD 85c062d8 Cid 0004.0048 Teb: 00000000 Win32Thread: 00000000 WAIT:
(WrQueue) UserMode Non-Alertable
8210f13c QueueObject
Not impersonating
DeviceMap 8e4086a0
Owning Process 85c03c10 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 54381136 Ticks: 297351 (0:01:17:18.705)
Context Switch Count 808914
UserTime 00:00:00.000
KernelTime 00:00:08.907
Win32 Start Address nt!ExpWorkerThread (0x820b2d25)
Stack Init 8e896000 Current 8e895c70 Base 8e896000 Limit 8e893000 Call 0
Priority 13 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5
Kernel stack not resident.
ChildEBP RetAddr Args to Child
8e895c88 820b9352 85c062d8 8e785120 85c06360 nt!KiSwapContext+0x26 (FPO:
[Uses EBP] [0,0,4])
8e895ccc 820b3744 85c062d8 8210f13c 85c062d8 nt!KiSwapThread+0x44f
8e895d30 820b2dfa 8210f13c 00000001 00000000 nt!KeRemoveQueueEx+0x741
8e895d7c 821e2c42 00000000 5e435c90 00000000 nt!ExpWorkerThread+0xd5
8e895dc0 8204bf4e 820b2d25 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

And I verified these are actual threads that handle IoQueueWorkItem.

Windows 7/2008R2 doesn’t do that anymore:

0: kd> !thread fffffa80069f8040
THREAD fffffa80069f8040 Cid 0004.0024 Teb: 0000000000000000 Win32Thread:
0000000000000000 WAIT: (WrQueue) KernelMode Non-Alertable
fffff800018665a0 QueueObject
Not impersonating
DeviceMap fffff8a000007e80
Owning Process fffffa80069e0b30 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 3293697 Ticks: 912124 (0:03:57:09.225)
Context Switch Count 36676
UserTime 00:00:00.000
KernelTime 00:00:02.652
Win32 Start Address nt!ExpWorkerThread (0xfffff800016d0050)
Stack Init fffff8800276fdb0 Current fffff8800276f9f0
Base fffff88002770000 Limit fffff8800276a000 Call 0
Priority 13 BasePriority 13 UnusualBoost 0 ForegroundBoost 0 IoPriority 2
PagePriority 5
Child-SP RetAddr : Args to Child
: Call Site
fffff8800276fa30 fffff800016ca052 : fffff98001c9cfc0 fffffa80069f8040
0000000000000000 fffff88001476673 : nt!KiSwapContext+0x7a
fffff8800276fb70 fffff800016cdac1 : fffff8800148dd68 fffffa80069f8040
fffff88000000000 fffff88001476734 : nt!KiCommitThreadWait+0x1d2
fffff8800276fc00 fffff800016d0139 : fffff80001866500 fffff800019bc504
fffffa80069f8040 0000000000000002 : nt!KeRemoveQueueEx+0x301
fffff8800276fcb0 fffff80001966166 : 0000000000000000 fffffa80069f8040
0000000000000080 fffffa80069e0b30 : nt!ExpWorkerThread+0xe9
fffff8800276fd40 fffff800016a1486 : fffff880026a4180 fffffa80069f8040
fffff880026af0c0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff8800276fd80 0000000000000000 : fffff88002770000 fffff8800276a000
fffff8800276f9f0 0000000000000000 : nt!KxStartSystemThread+0x16

Finally! Take it, covetous knights, guardians of the non-paged memory…

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Stack please

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Alexander Grigoriev
Sent: Friday, March 26, 2010 7:14 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:DRIVER_POWER_STATE_FAILURE

Oh, and by the way, Win 2008 is still doing that. Do !stacks 1 on a box
that’s been heavily exercised.

“Alexander Grigoriev” wrote in message
news:xxxxx@ntdev…
> Then why the debugger was showing “stack swapped out”, and the thread was
> deadlocked waiting for paging in(while being queued a workitem necessary
> for a driver to bring the paging path up).
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> No, the worker threads do not do a user mode (unless that is the actual
> work item callback which does the wait) in the worker item thread pool.
> The problem is that you can get stuck behind a work item which is in the
> middle of processing a page fault (by touching paged pool or code). If
> you are the paging device and you must be the one to service the page
> fault, but are stuck behind that item, you dead lock.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alexander
> Grigoriev
> Sent: Thursday, March 25, 2010 8:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DRIVER_POWER_STATE_FAILURE
>
> God forbid you use system workitem in a paging device path. Because of
> someone’s thing for saving non-paged memory, the worker threads wait in a
> mode that allows their stack to swap out. Been there seen that. At least
> under Windows 2003. Not sure if that’s still the case in 2008+.
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Are you using work items in the power up path? Have you !poreqlist and
> !poaction to see what the current outstanding power irps are? Have you run
> !stacks to see what every thread is doing?
>
> d
>
> tiny phone keyboard + fat thumbs = you do the muth
>
>
>
> -----Original Message-----
> From: Wayne Gong
> Sent: Thursday, March 25, 2010 7:35 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] DRIVER_POWER_STATE_FAILURE
>
>
> Sorry, I made a mistake. Some resource will be exhausted if I attach lots
> of child devices.
>
> Thanks
> Wayne
>
> —
> NTDEV 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
>
>
>
>
> —
> NTDEV 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
>
>
>
>

—
NTDEV 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