Cache Manager Lazy Writes(Write-Behind) Requests ...

OSR_Community_User · September 11, 2002, 3:10pm

Hi all,

I am wondering if it may or will cause any problems if it keeps taking a long time processing
Cache Manager Lazy-Write-Requests.

I am investigating a crash and suspecting that it is caused by fsd spending a lot of time processing write requests.

Below is a Bugcheck Analysis info.,.

Thanks,

Ilya.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 4D, {0, 0, 379b, 8e32}

Probably caused by : ntoskrnl.exe ( nt!MiEnsureAvailablePageOrWait+1c7 )

Followup: MachineOwner

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

NO_PAGES_AVAILABLE (4d)
No free pages available to continue operations.
If kernel debugger available “!vm 3”.
This bugcheck can occur for the following reasons:

A driver has blocked, deadlocking the modified or mapped
page writers. Examples of this include mutex deadlocks or
accesses to paged out memory in filesystem drivers, filter
drivers, etc. This indicates a driver bug.
If parameter 1 or 2 is large, then this is a possibility. Type
“!vm 3” in the kernel debugger.
The storage driver(s) are not processing requests. Examples
of this are stranded queues, non-responding drives, etc. This
indicates a driver bug.
If parameter 1 or 2 is large, then this is a possibility. Type
“!process 0 7” in the kernel debugger.
Not enough pool is available for the storage stack to write out
modified pages. This indicates a driver bug.
If parameter 3 is small, then this is a possibility. Type
“!vm” and “!poolused 2” in the kernel debugger.
A high priority realtime thread has starved the balance set
manager from trimming pages and/or starved the modified writer
from writing them out. This indicates a bug in the component
that created this thread.
This one is hard to determine, try “!ready”
All the processes have been trimmed to their minimums and all
modified pages written, but still no memory is available. The
freed memory must be stuck in transition pages with non-zero
reference counts - thus they cannot be put on the freelist.
A driver is neglecting to unlock the pages preventing the
reference counts from going to zero which would free the pages.
This may be due to transfers that never finish and the driver
never aborts or other driver bugs.
If parameter 4 is large, then this is a possibility. But it
is very hard to find the driver. Try “!process 0 1” and look
for any that have a lot of locked pages.
If the problem cannot be found, then try booting with /DEBUG and a kernel
debugger attached, so if it reproduces, a debug session can be initiated
to identify the cause.
Arguments:
Arg1: 00000000, Total number of dirty pages
Arg2: 00000000, Number of dirty pages destined for the pagefile(s).
Arg3: 0000379b, Nonpaged pool available at time of bugcheck (in pages).
Arg4: 00008e32, Number of transition pages that are currently stranded.

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 4D

LAST_CONTROL_TRANSFER: from 8043e789 to 80445aba

STACK_TEXT:
f6857cf0 8043e789 003ffffc c03d9534 81428d80 nt!MiEnsureAvailablePageOrWait+0x1c7
f6857d50 8043e0fa c03d9534 c03d9534 00000001 nt!MiMakeOutswappedPageResident+0x20
f6857d7c 80460382 81428d00 00000000 00000000 nt!MmInPageKernelStack+0x10e
f6857d90 80460347 00000000 00000000 00000000 nt!KiInSwapKernelStacks+0x2f
f6857da8 804524f6 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x80
f6857ddc 80465b62 804602c7 00000000 00000000 nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

…
Ilya Levin
File System Developer
xxxxx@softricity.com

Softricity, Inc.
332 Congress Street
Boston, MA 02210
617.695.0336 x168
www.softricity.com - Powering Software as a Service
…

Dan_Partelly · September 11, 2002, 4:32pm

Those are not “lazy write” requests. Unfortunately is hard for me to
determine a possible cause here. What is your dirver here ? a FSF or a FSD ?
Also , “Long time” is a very relative value. What do you mean by it ?

How your FSD or FSF process / interfers with paging IO writes ? How does the
crash occures ? Very early after system boot up, or later, at random time
periods ?

I would look for PFNs with high reference counts first.

Ciao, Dan

----- Original Message -----
From: “Ilya Levin”
To: “File Systems Developers”
Sent: Wednesday, September 11, 2002 10:06 PM
Subject: [ntfsd] Cache Manager Lazy Writes(Write-Behind) Requests …

Hi all,

I am wondering if it may or will cause any problems if it keeps taking a
long time processing
Cache Manager Lazy-Write-Requests.

I am investigating a crash and suspecting that it is caused by fsd spending
a lot of time processing write requests.

Below is a Bugcheck Analysis info.,.

Thanks,

Ilya.

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

Bugcheck Analysis

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

Use !analyze -v to get detailed debugging information.

BugCheck 4D, {0, 0, 379b, 8e32}

Probably caused by : ntoskrnl.exe ( nt!MiEnsureAvailablePageOrWait+1c7 )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************

Bugcheck Analysis

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

NO_PAGES_AVAILABLE (4d)
No free pages available to continue operations.
If kernel debugger available “!vm 3”.
This bugcheck can occur for the following reasons:
1. A driver has blocked, deadlocking the modified or mapped
page writers. Examples of this include mutex deadlocks or
accesses to paged out memory in filesystem drivers, filter
drivers, etc. This indicates a driver bug.
If parameter 1 or 2 is large, then this is a possibility. Type
“!vm 3” in the kernel debugger.
2. The storage driver(s) are not processing requests. Examples
of this are stranded queues, non-responding drives, etc. This
indicates a driver bug.
If parameter 1 or 2 is large, then this is a possibility. Type
“!process 0 7” in the kernel debugger.
3. Not enough pool is available for the storage stack to write out
modified pages. This indicates a driver bug.
If parameter 3 is small, then this is a possibility. Type
“!vm” and “!poolused 2” in the kernel debugger.
4. A high priority realtime thread has starved the balance set
manager from trimming pages and/or starved the modified writer
from writing them out. This indicates a bug in the component
that created this thread.
This one is hard to determine, try “!ready”
5. All the processes have been trimmed to their minimums and all
modified pages written, but still no memory is available. The
freed memory must be stuck in transition pages with non-zero
reference counts - thus they cannot be put on the freelist.
A driver is neglecting to unlock the pages preventing the
reference counts from going to zero which would free the pages.
This may be due to transfers that never finish and the driver
never aborts or other driver bugs.
If parameter 4 is large, then this is a possibility. But it
is very hard to find the driver. Try “!process 0 1” and look
for any that have a lot of locked pages.
If the problem cannot be found, then try booting with /DEBUG and a kernel
debugger attached, so if it reproduces, a debug session can be initiated
to identify the cause.
Arguments:
Arg1: 00000000, Total number of dirty pages
Arg2: 00000000, Number of dirty pages destined for the pagefile(s).
Arg3: 0000379b, Nonpaged pool available at time of bugcheck (in pages).
Arg4: 00008e32, Number of transition pages that are currently stranded.

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

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 4D

LAST_CONTROL_TRANSFER: from 8043e789 to 80445aba

STACK_TEXT:
f6857cf0 8043e789 003ffffc c03d9534 81428d80
nt!MiEnsureAvailablePageOrWait+0x1c7
f6857d50 8043e0fa c03d9534 c03d9534 00000001
nt!MiMakeOutswappedPageResident+0x20
f6857d7c 80460382 81428d00 00000000 00000000 nt!MmInPageKernelStack+0x10e
f6857d90 80460347 00000000 00000000 00000000 nt!KiInSwapKernelStacks+0x2f
f6857da8 804524f6 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x80
f6857ddc 80465b62 804602c7 00000000 00000000 nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

…
Ilya Levin
File System Developer
xxxxx@softricity.com

Softricity, Inc.
332 Congress Street
Boston, MA 02210
617.695.0336 x168
www.softricity.com - Powering Software as a Service
…

—
You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

Dan_Partelly · September 11, 2002, 5:00pm

I was asking for what you mean by “a lot of time” because IIRC Mm can block
up to several minutes before ensuring this bugcheck.

----- Original Message -----
From: “Ilya Levin”
To: “File Systems Developers”
Sent: Wednesday, September 11, 2002 10:06 PM
Subject: [ntfsd] Cache Manager Lazy Writes(Write-Behind) Requests …

Hi all,

I am wondering if it may or will cause any problems if it keeps taking a
long time processing
Cache Manager Lazy-Write-Requests.

I am investigating a crash and suspecting that it is caused by fsd spending
a lot of time processing write requests.

Below is a Bugcheck Analysis info.,.

Thanks,

Ilya.

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

Bugcheck Analysis

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

Use !analyze -v to get detailed debugging information.

BugCheck 4D, {0, 0, 379b, 8e32}

Probably caused by : ntoskrnl.exe ( nt!MiEnsureAvailablePageOrWait+1c7 )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************

Bugcheck Analysis

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

NO_PAGES_AVAILABLE (4d)
No free pages available to continue operations.
If kernel debugger available “!vm 3”.
This bugcheck can occur for the following reasons:
1. A driver has blocked, deadlocking the modified or mapped
page writers. Examples of this include mutex deadlocks or
accesses to paged out memory in filesystem drivers, filter
drivers, etc. This indicates a driver bug.
If parameter 1 or 2 is large, then this is a possibility. Type
“!vm 3” in the kernel debugger.
2. The storage driver(s) are not processing requests. Examples
of this are stranded queues, non-responding drives, etc. This
indicates a driver bug.
If parameter 1 or 2 is large, then this is a possibility. Type
“!process 0 7” in the kernel debugger.
3. Not enough pool is available for the storage stack to write out
modified pages. This indicates a driver bug.
If parameter 3 is small, then this is a possibility. Type
“!vm” and “!poolused 2” in the kernel debugger.
4. A high priority realtime thread has starved the balance set
manager from trimming pages and/or starved the modified writer
from writing them out. This indicates a bug in the component
that created this thread.
This one is hard to determine, try “!ready”
5. All the processes have been trimmed to their minimums and all
modified pages written, but still no memory is available. The
freed memory must be stuck in transition pages with non-zero
reference counts - thus they cannot be put on the freelist.
A driver is neglecting to unlock the pages preventing the
reference counts from going to zero which would free the pages.
This may be due to transfers that never finish and the driver
never aborts or other driver bugs.
If parameter 4 is large, then this is a possibility. But it
is very hard to find the driver. Try “!process 0 1” and look
for any that have a lot of locked pages.
If the problem cannot be found, then try booting with /DEBUG and a kernel
debugger attached, so if it reproduces, a debug session can be initiated
to identify the cause.
Arguments:
Arg1: 00000000, Total number of dirty pages
Arg2: 00000000, Number of dirty pages destined for the pagefile(s).
Arg3: 0000379b, Nonpaged pool available at time of bugcheck (in pages).
Arg4: 00008e32, Number of transition pages that are currently stranded.

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

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 4D

LAST_CONTROL_TRANSFER: from 8043e789 to 80445aba

STACK_TEXT:
f6857cf0 8043e789 003ffffc c03d9534 81428d80
nt!MiEnsureAvailablePageOrWait+0x1c7
f6857d50 8043e0fa c03d9534 c03d9534 00000001
nt!MiMakeOutswappedPageResident+0x20
f6857d7c 80460382 81428d00 00000000 00000000 nt!MmInPageKernelStack+0x10e
f6857d90 80460347 00000000 00000000 00000000 nt!KiInSwapKernelStacks+0x2f
f6857da8 804524f6 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x80
f6857ddc 80465b62 804602c7 00000000 00000000 nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

…
Ilya Levin
File System Developer
xxxxx@softricity.com

Softricity, Inc.
332 Congress Street
Boston, MA 02210
617.695.0336 x168
www.softricity.com - Powering Software as a Service
…

—
You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

OSR_Community_User · September 12, 2002, 9:24am

Dan ,
It is FSD, and it can spend up to a minute in the write-request before failing or succeeding it.
Once FSD gets into this state, where it takes a long time to process the write request,
the system becomes very unresponsive, and after 20 minutes or so it KeBugChecks.
Thanks,
Ilya.

…
Ilya Levin
File System Developer
xxxxx@softricity.com

Softricity, Inc.
332 Congress Street
Boston, MA 02210
617.695.0336 x168
www.softricity.com - Powering Software as a Service
…