Hung IRP after sleep on named pipe? (\FileSystem\Npfs)

WINDBG
1

Dear list,

I’m having serious problems when my Windows 7 PC comes back up from sleep (S3).

At first, everything seems normal, but a (random?) certain app, mostly it’s a VirtualBox or any msiexec instance, will hang on execution, unkillable, burning up one core, its main thread stack starting with something like “0, ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.

After intense googling I went down the road of kernel debugging, which I’ve never done before, besides simple crash dump debugging.

Using LiveKD I was able to find two hung IRPs,
“fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
and
“fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”, both pending on \FileSystem\Npfs:

[3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000 pending
\FileSystem\Npfs
Args: 00001000 00000000 00000000 00000000

I tried looking into that further, but I couldn’t narrow it down to anything.

I’m really desperate for help here, as sleep works pretty well with my current setup, only the reproducable hung IRP on certain apps keeps me from being able to use it daily.

If you need the whole log file of the kd output: http://pastebin.com/AP3SbbMj

Thank you in advance!

Hannes

2

Are you sure that the thread with high CPU utilization is actually spinning
in the kernel? Task Manager, CPU, show kernel times? I’m not that familiar
with Virtual Box and that being said I looked at your live kd details very
quickly.

All the Virtual Box threads that I saw are swapped out waiting on an event
to occur so they are not using CPU
The IRP above that you are referring too is a READ Irp ( the 3 )

[3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000
pending
\FileSystem\Npfs
Args: 00001000 00000000 00000000 00000000

and its currently owned by Named Pipes. Its totally normal for a Read irp
to be waiting on a read from a pipe. When data comes from the other end of
the pipe the data will get inserted into the irps buffer and the irp will
complete so what ever opened the pipe has something to read.

Virtual Box uses named pipes for something ( dont remember what ) and in a
poor implementation it could have a thread spinning waiting for an async IO
call to return but I doubt thats the case.

Anyhow the initial question still stands.

On Thu, Apr 3, 2014 at 10:28 AM, wrote:

> Dear list,
>
> I’m having serious problems when my Windows 7 PC comes back up from sleep
> (S3).
>
> At first, everything seems normal, but a (random?) certain app, mostly
> it’s a VirtualBox or any msiexec instance, will hang on execution,
> unkillable, burning up one core, its main thread stack starting with
> something like “0, ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.
>
> After intense googling I went down the road of kernel debugging, which
> I’ve never done before, besides simple crash dump debugging.
>
> Using LiveKD I was able to find two hung IRPs,
> “fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
> and
> “fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”, both
> pending on \FileSystem\Npfs:
>
> >[3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000
> pending
> \FileSystem\Npfs
> Args: 00001000 00000000 00000000 00000000
>
>
> I tried looking into that further, but I couldn’t narrow it down to
> anything.
>
> I’m really desperate for help here, as sleep works pretty well with my
> current setup, only the reproducable hung IRP on certain apps keeps me from
> being able to use it daily.
>
>
> If you need the whole log file of the kd output:
> http://pastebin.com/AP3SbbMj
>
>
> Thank you in advance!
>
> Hannes
>
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>

3

This output is strangely formatted, it doesn’t appear as though we’re seeing
the actual debugger output.

However, none of the processes shown here have high CPU time. You can see
this in the !process output, for example:

ElapsedTime 01:01:07.043
UserTime 00:00:01.076
KernelTime 00:00:00.280

This means the process was created over an hour ago but has only consumed ~1
second of CPU time total (user+kernel)

-scott
OSR
@OSRDrivers

“James Hardy” wrote in message news:xxxxx@windbg…
Are you sure that the thread with high CPU utilization is actually spinning
in the kernel? Task Manager, CPU, show kernel times? I’m not that familiar
with Virtual Box and that being said I looked at your live kd details very
quickly.

All the Virtual Box threads that I saw are swapped out waiting on an event
to occur so they are not using CPU
The IRP above that you are referring too is a READ Irp ( the 3 )

>[3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000
>pending
\FileSystem\Npfs
Args: 00001000 00000000 00000000 00000000

and its currently owned by Named Pipes. Its totally normal for a Read irp to
be waiting on a read from a pipe. When data comes from the other end of the
pipe the data will get inserted into the irps buffer and the irp will
complete so what ever opened the pipe has something to read.

Virtual Box uses named pipes for something ( dont remember what ) and in a
poor implementation it could have a thread spinning waiting for an async IO
call to return but I doubt thats the case.

Anyhow the initial question still stands.

On Thu, Apr 3, 2014 at 10:28 AM, wrote:
Dear list,

I’m having serious problems when my Windows 7 PC comes back up from sleep
(S3).

At first, everything seems normal, but a (random?) certain app, mostly it’s
a VirtualBox or any msiexec instance, will hang on execution, unkillable,
burning up one core, its main thread stack starting with something like “0,
ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.

After intense googling I went down the road of kernel debugging, which I’ve
never done before, besides simple crash dump debugging.

Using LiveKD I was able to find two hung IRPs,
“fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
and
“fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”, both pending
on \FileSystem\Npfs:

>[3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000
>pending
\FileSystem\Npfs
Args: 00001000 00000000 00000000 00000000

I tried looking into that further, but I couldn’t narrow it down to
anything.

I’m really desperate for help here, as sleep works pretty well with my
current setup, only the reproducable hung IRP on certain apps keeps me from
being able to use it daily.

If you need the whole log file of the kd output:
http://pastebin.com/AP3SbbMj

Thank you in advance!

Hannes

—
WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

4

It is, yes. I’ve started another run and was paying attention to the
virtualbox process itself.
It seems to occur only on a special operation and it’s always the same one
per boot (I guess).

On my current woken-up-from-sleep-state virtualbox is the one, when
starting a particular VM, which
ends up grinding the CPU (with 99% of its total time being kernel time),
with its main thread in this state:

0, ntoskrnl.exe!KiDeliverApc+0x1c7
1, ntoskrnl.exe!KiApcInterrupt+0xd7
2, VBoxDrv.sys!RTThreadPreemptRestore+0x8
3, ntdll.dll!NtDeviceIoControlFile+0xa
4, KernelBase.dll!DeviceIoControl+0x79
5, kernel32.dll!DeviceIoControl+0x7f
6, VBoxRT.dll!SUPR3LoadVMM+0x7a1
7, VBoxVMM.dll!VMMR3EmtRendezvous+0x2906
8, VBoxVMM.dll!EMR3FatalError+0x4884
9, VBoxVMM.dll!EMR3FatalError+0x1e66
10, VBoxVMM.dll!VMR3Create+0x1d64
11, VBoxRT.dll!RTThreadFromNative+0x20f
12, VBoxRT.dll!RTSymlinkRead+0x31a
13, msvcr100.dll!endthreadex+0x43
14, msvcr100.dll!endthreadex+0xdf
15, kernel32.dll!BaseThreadInitThunk+0xd
16, ntdll.dll!RtlUserThreadStart+0x21

Which is different from the one before (and the first one without an irp
call reference), that I’ve posted, still, the VM I was trying to start is
the same and it hung on exactly the same position (ubuntu server VM, right
after USB device detection it decides to switch to clocksource “tsc” and
hangs after that).

Starting a different VM (in this case, ubuntu desktop), everything works
out. After I reboot my machine, everything works well again, though, waking
it up from sleep afterwards results in the same behaviour:

Some process will hang grinding kernel time, most of the time with irp
calls on its main thread’s stack.

I can provide another debug log when it happens to a different process if
that could help.

Thank you for your help so far!

On Thu, 3 Apr 2014 12:02:22 -0700, James Hardy
wrote:

> Are you sure that the thread with high CPU utilization is actually
> spinning in the kernel? Task Manager, CPU, show kernel times? I’m not
> that familiar with Virtual Box and that being said I looked at your live
> kd details very quickly.
>
> All the Virtual Box threads that I saw are swapped out waiting on an
> event to occur so they are not using CPU
> The IRP above that you are referring too is a READ Irp ( the 3 )
>
>> [ 3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000

>> pending
> \FileSystem\Npfs
> Args: 00001000 00000000 00000000
00000000
>
> and its currently owned by Named Pipes. Its totally normal for a Read
> irp to be waiting on a read from a pipe. When data comes from the other
> end of the pipe the data will get inserted into the irps buffer and the
> irp will complete so what ever opened the pipe has something to read.
>
>
> Virtual Box uses named pipes for something ( dont remember what ) and in
> a poor implementation it could have a thread spinning waiting for an
> async IO call to return but I doubt thats the case.
>
> Anyhow the initial question still stands.
>
>
>
>
> On Thu, Apr 3, 2014 at 10:28 AM, wrote:
>
>> Dear list,
>>
>> I’m having serious problems when my Windows 7 PC comes back up from
>> sleep (S3).
>>
>> At first, everything seems normal, but a (random?) certain app, mostly
>> it’s a VirtualBox or any msiexec instance, will hang on execution,
>> unkillable, burning up one core, its main thread stack starting with
>> something like “0, ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.
>>
>> After intense googling I went down the road of kernel debugging, which
>> I’ve never done before, besides simple crash dump debugging.
>>
>> Using LiveKD I was able to find two hung IRPs,
>> “fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
>> and
>> “fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”, both
>> pending on \FileSystem\Npfs:
>>
>>> [ 3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000

>>> pending
>> \FileSystem\Npfs
>> Args: 00001000 00000000 00000000
00000000
>>
>> I tried looking into that further, but I couldn’t narrow it down to
>> anything.
>>
>> I’m really desperate for help here, as sleep works pretty well with my
>> current setup, only the reproducable hung IRP on certain apps keeps me
>> from being able to use it daily.
>>
>> If you need the whole log file of the kd output:
>> http://pastebin.com/AP3SbbMj
>>
>> Thank you in advance!
>>
>> Hannes
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> 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 OSR is hiring!! Info at
> http://www.osr.com/careers 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
–
Hannes Tismer
Herzogstr. 4
41238 Mönchengladbach

5

That’s right, I was using livekd|wtee to capture its output while I tried
to figure out what was going on.

If there’s a better approach, please tell me how.

On Thu, 3 Apr 2014 16:35:02 -0400, Scott Noone wrote:

> This output is strangely formatted, it doesn’t appear as though
> we’re seeing the actual debugger output.
>
> However, none of the processes shown here have high CPU time. You
> can see this in the !process output, for example:
>
> ElapsedTime 01:01:07.043
> UserTime 00:00:01.076
> KernelTime 00:00:00.280
>
> This means the process was created over an hour ago but has only
> consumed ~1 second of CPU time total (user+kernel)

I’ve looked up the thread ID which processhacker showed as the grinding one
and matched it with the cids of the threads with a pending IRP in
livekds output,
and the log I’ve posted was what came out of it.

I’m gonna try the same on the next sleep-wakeup-something-hangs-cycle,
perhaps there’s a pattern to be found.

>
> -scott
> OSR
> @OSRDrivers
>
>
> “James Hardy” wrote in message news:xxxxx@windbg…
> Are you sure that the thread with high CPU utilization is actually
> spinning in the kernel? Task Manager, CPU, show kernel times? I’m
> not that familiar with Virtual Box and that being said I looked at
> your live kd details very quickly.
>
>
>
> All the Virtual Box threads that I saw are swapped out waiting on an
> event to occur so they are not using CPU
> The IRP above that you are referring too is a READ Irp ( the 3 )
>
>> [3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000 pending
> \FileSystem\Npfs
> Args: 00001000 00000000 00000000 00000000
>
> and its currently owned by Named Pipes. Its totally normal for a
> Read irp to be waiting on a read from a pipe. When data comes from
> the other end of the pipe the data will get inserted into the irps
> buffer and the irp will complete so what ever opened the pipe has
> something to read.
>
>
> Virtual Box uses named pipes for something ( dont remember what )
> and in a poor implementation it could have a thread spinning waiting
> for an async IO call to return but I doubt thats the case.
>
> Anyhow the initial question still stands.
>
>
>
>
>
> On Thu, Apr 3, 2014 at 10:28 AM, wrote:
> Dear list,
>
> I’m having serious problems when my Windows 7 PC comes back up from
> sleep (S3).
>
> At first, everything seems normal, but a (random?) certain app,
> mostly it’s a VirtualBox or any msiexec instance, will hang on
> execution, unkillable, burning up one core, its main thread stack
> starting with something like “0,
> ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.
>
> After intense googling I went down the road of kernel debugging,
> which I’ve never done before, besides simple crash dump debugging.
>
> Using LiveKD I was able to find two hung IRPs,
> “fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
> and
> “fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”, both
> pending on \FileSystem\Npfs:
>
>> [3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000 pending
> \FileSystem\Npfs
> Args: 00001000 00000000 00000000 00000000
>
>
> I tried looking into that further, but I couldn’t narrow it down to anything.
>
> I’m really desperate for help here, as sleep works pretty well with
> my current setup, only the reproducable hung IRP on certain apps
> keeps me from being able to use it daily.
>
>
> If you need the whole log file of the kd output: http://pastebin.com/AP3SbbMj
>
>
> Thank you in advance!
>
> Hannes
>
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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

–
Hannes Tismer
Herzogstr. 4
41238 Mönchengladbach

6

And there’s more I noticed:

When resuming from sleep also certain USB devices won’t work (and
won’t be recognized
after plugging into a different port/controller), aswell as the
shutdown process
never ends (reset/hard shutdown needed). Windows doesn’t recognize
that as a faulty
shutdown, though, and continues as if nothing has happened after boot.

On Thu, 03 Apr 2014 21:18:34 +0000, Hannes Tismer
wrote:

> That’s right, I was using livekd|wtee to capture its output while I tried
> to figure out what was going on.
>
> If there’s a better approach, please tell me how.
>
>
>
> On Thu, 3 Apr 2014 16:35:02 -0400, Scott Noone wrote:
>
>> This output is strangely formatted, it doesn’t appear as though
>> we’re seeing the actual debugger output.
>>
>> However, none of the processes shown here have high CPU time. You
>> can see this in the !process output, for example:
>>
>> ElapsedTime 01:01:07.043
>> UserTime 00:00:01.076
>> KernelTime 00:00:00.280
>>
>> This means the process was created over an hour ago but has only
>> consumed ~1 second of CPU time total (user+kernel)
>
> I’ve looked up the thread ID which processhacker showed as the grinding one
> and matched it with the cids of the threads with a pending IRP in
> livekds output,
> and the log I’ve posted was what came out of it.
>
> I’m gonna try the same on the next sleep-wakeup-something-hangs-cycle,
> perhaps there’s a pattern to be found.
>
>>
>> -scott
>> OSR
>> @OSRDrivers
>>
>>
>> “James Hardy” wrote in message news:xxxxx@windbg…
>> Are you sure that the thread with high CPU utilization is actually
>> spinning in the kernel? Task Manager, CPU, show kernel times? I’m
>> not that familiar with Virtual Box and that being said I looked at
>> your live kd details very quickly.
>>
>>
>>
>> All the Virtual Box threads that I saw are swapped out waiting on
>> an event to occur so they are not using CPU
>> The IRP above that you are referring too is a READ Irp ( the 3 )
>>
>>> [3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000 pending
>> \FileSystem\Npfs
>> Args: 00001000 00000000 00000000 00000000
>>
>> and its currently owned by Named Pipes. Its totally normal for a
>> Read irp to be waiting on a read from a pipe. When data comes from
>> the other end of the pipe the data will get inserted into the irps
>> buffer and the irp will complete so what ever opened the pipe has
>> something to read.
>>
>>
>> Virtual Box uses named pipes for something ( dont remember what )
>> and in a poor implementation it could have a thread spinning
>> waiting for an async IO call to return but I doubt thats the case.
>>
>> Anyhow the initial question still stands.
>>
>>
>>
>>
>>
>> On Thu, Apr 3, 2014 at 10:28 AM, wrote:
>> Dear list,
>>
>> I’m having serious problems when my Windows 7 PC comes back up from
>> sleep (S3).
>>
>> At first, everything seems normal, but a (random?) certain app,
>> mostly it’s a VirtualBox or any msiexec instance, will hang on
>> execution, unkillable, burning up one core, its main thread stack
>> starting with something like “0,
>> ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.
>>
>> After intense googling I went down the road of kernel debugging,
>> which I’ve never done before, besides simple crash dump debugging.
>>
>> Using LiveKD I was able to find two hung IRPs,
>> “fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
>> and
>> “fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”,
>> both pending on \FileSystem\Npfs:
>>
>>> [3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000 pending
>> \FileSystem\Npfs
>> Args: 00001000 00000000 00000000 00000000
>>
>>
>> I tried looking into that further, but I couldn’t narrow it down to
>> anything.
>>
>> I’m really desperate for help here, as sleep works pretty well with
>> my current setup, only the reproducable hung IRP on certain apps
>> keeps me from being able to use it daily.
>>
>>
>> If you need the whole log file of the kd output:
>> http://pastebin.com/AP3SbbMj
>>
>>
>> Thank you in advance!
>>
>> Hannes
>>
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> 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
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> 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
>
>
> –
> Hannes Tismer
> Herzogstr. 4
> 41238 Mönchengladbach
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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

Just a guess here but this doesnt look too good

8, VBoxVMM.dll!EMR3FatalError+0x4 (FATAL ERROR in user mode )
884

and if for some reason VBOXDrv.sys driver ( which appears to be the target
of the DeviceIoControl call ) is unhappy and keeps firing APCs you could
chew up cpu cycles

I think that you should probably start a real debug session ( usb, tcpip,
serial ) so that you can break in to the kernel and set some breakpoints to
see what is going on as opposed to the snapshot information you are
getting now.

Setting up Kernel debugging in the debugger.chm help file

0, ntoskrnl.exe!KiDeliverApc+0x1c
7
1, ntoskrnl.exe!KiApcInterrupt+0xd7
2, VBoxDrv.sys!RTThreadPreemptRestore+0x8
3, ntdll.dll!NtDeviceIoControlFile+0xa
4, KernelBase.dll!DeviceIoControl+0x79
5, kernel32.dll!DeviceIoControl+0x7f
6, VBoxRT.dll!SUPR3LoadVMM+0x7a1
7, VBoxVMM.dll!VMMR3EmtRendezvous+0x2906

9, VBoxVMM.dll!EMR3FatalError+0x1e66
10, VBoxVMM.dll!VMR3Create+0x1d64

On Thu, Apr 3, 2014 at 2:43 PM, Hannes Tismer wrote:

> And there’s more I noticed:
>
> When resuming from sleep also certain USB devices won’t work (and won’t be
> recognized
> after plugging into a different port/controller), aswell as the shutdown
> process
> never ends (reset/hard shutdown needed). Windows doesn’t recognize that as
> a faulty
> shutdown, though, and continues as if nothing has happened after boot.
>
>
>
>
>
> On Thu, 03 Apr 2014 21:18:34 +0000, Hannes Tismer
> wrote:
>
> That’s right, I was using livekd|wtee to capture its output while I tried
>> to figure out what was going on.
>>
>> If there’s a better approach, please tell me how.
>>
>>
>>
>> On Thu, 3 Apr 2014 16:35:02 -0400, Scott Noone wrote:
>>
>> This output is strangely formatted, it doesn’t appear as though we’re
>>> seeing the actual debugger output.
>>>
>>> However, none of the processes shown here have high CPU time. You can
>>> see this in the !process output, for example:
>>>
>>> ElapsedTime 01:01:07.043
>>> UserTime 00:00:01.076
>>> KernelTime 00:00:00.280
>>>
>>> This means the process was created over an hour ago but has only
>>> consumed ~1 second of CPU time total (user+kernel)
>>>
>>
>> I’ve looked up the thread ID which processhacker showed as the grinding
>> one
>> and matched it with the cids of the threads with a pending IRP in livekds
>> output,
>> and the log I’ve posted was what came out of it.
>>
>> I’m gonna try the same on the next sleep-wakeup-something-hangs-cycle,
>> perhaps there’s a pattern to be found.
>>
>>
>>> -scott
>>> OSR
>>> @OSRDrivers
>>>
>>>
>>> “James Hardy” wrote in message
>>> news:xxxxx@windbg…
>>> Are you sure that the thread with high CPU utilization is actually
>>> spinning in the kernel? Task Manager, CPU, show kernel times? I’m not that
>>> familiar with Virtual Box and that being said I looked at your live kd
>>> details very quickly.
>>>
>>>
>>>
>>> All the Virtual Box threads that I saw are swapped out waiting on an
>>> event to occur so they are not using CPU
>>> The IRP above that you are referring too is a READ Irp ( the 3 )
>>>
>>> [3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000
>>>> pending
>>>>
>>> \FileSystem\Npfs
>>> Args: 00001000 00000000 00000000 00000000
>>>
>>> and its currently owned by Named Pipes. Its totally normal for a Read
>>> irp to be waiting on a read from a pipe. When data comes from the other end
>>> of the pipe the data will get inserted into the irps buffer and the irp
>>> will complete so what ever opened the pipe has something to read.
>>>
>>>
>>> Virtual Box uses named pipes for something ( dont remember what ) and in
>>> a poor implementation it could have a thread spinning waiting for an async
>>> IO call to return but I doubt thats the case.
>>>
>>> Anyhow the initial question still stands.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 3, 2014 at 10:28 AM, wrote:
>>> Dear list,
>>>
>>> I’m having serious problems when my Windows 7 PC comes back up from
>>> sleep (S3).
>>>
>>> At first, everything seems normal, but a (random?) certain app, mostly
>>> it’s a VirtualBox or any msiexec instance, will hang on execution,
>>> unkillable, burning up one core, its main thread stack starting with
>>> something like “0, ntoskrnl.exe!PoStartNextPowerIrp+0x17e7”.
>>>
>>> After intense googling I went down the road of kernel debugging, which
>>> I’ve never done before, besides simple crash dump debugging.
>>>
>>> Using LiveKD I was able to find two hung IRPs,
>>> “fffffa80241660d0: (0006,0118) Flags: 00062900 Mdl: 00000000”
>>> and
>>> “fffffa8023b97770: (0006,0118) Flags: 00062900 Mdl: 00000000”, both
>>> pending on \FileSystem\Npfs:
>>>
>>> [3, 0] 0 1 fffffa8013546bd0 fffffa801706ff20 00000000-00000000
>>>> pending
>>>>
>>> \FileSystem\Npfs
>>> Args: 00001000 00000000 00000000 00000000
>>>
>>>
>>> I tried looking into that further, but I couldn’t narrow it down to
>>> anything.
>>>
>>> I’m really desperate for help here, as sleep works pretty well with my
>>> current setup, only the reproducable hung IRP on certain apps keeps me from
>>> being able to use it daily.
>>>
>>>
>>> If you need the whole log file of the kd output:
>>> http://pastebin.com/AP3SbbMj
>>>
>>>
>>> Thank you in advance!
>>>
>>> Hannes
>>>
>>>
>>>
>>> —
>>> WINDBG is sponsored by OSR
>>>
>>> OSR is hiring!! Info at http://www.osr.com/careers
>>>
>>> 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
>>>
>>> OSR is hiring!! Info at http://www.osr.com/careers
>>>
>>> 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
>>>
>>
>>
>> –
>> Hannes Tismer
>> Herzogstr. 4
>> 41238 M?nchengladbach
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> 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
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>