Re: What may be the cause for this crash "NO_PAGES_AVAILABLE"

WINDBG
1

I have been seeing few of them recently. Is this machine a virtual machine
on Vmware?

  1. If Vmware then look for the Ballooning driver Vmmectl.sys it can block a
    chunk of Physical Memory available to the Host.

The Balloon Driver, vmmemctl, Is Unaware of Pinned Pages
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003586

Disabling Balloon Driver
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002586

  1. If it is a SQL Server then it could be the SQL’s MaxServerMemory
    configuration, which is configured to have a major chunk of RAM leaving very
    little for the OS and other apps and services.

  2. Run following commands and then post the output here so that i can
    compare the symptoms with the observations that I had for similar bugcheck
    due to Vmware.

!vm

!memusage <- If you see a large chunk of Memory under AWE then look for
SQL for MaxServerMemory if not SQL then it will be Vmmemctl.sys (Vmware
Ballooning Driver) provided it is a vmware platform

Regards
Pushkar

On Wed, Dec 16, 2009 at 3:45 PM, Karthik Gurumurthy <
xxxxx@nextbitcpu.com> wrote:

BugCheck 4D, {20ed6, 20ed6, 2, 0}

Probably caused by : ntoskrnl.exe ( nt!_woutput+414 )

Followup: MachineOwner

1: 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: 00020ed6, Total number of dirty pages
    Arg2: 00020ed6, Number of dirty pages destined for the pagefile(s).
    Arg3: 00000002, Internal flags.
    Arg4: 00000000, Most recent modified write error status.

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x4D

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 00000000 to 804f9f43

STACK_TEXT:
f7a9fcac 00000000 0000004d 00020ed6 00020ed6 nt!_woutput+0x414

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!_woutput+414
804f9f43 5d pop ebp

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!_woutput+414

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a784394

FAILURE_BUCKET_ID: 0x4D_nt!_woutput+414

BUCKET_ID: 0x4D_nt!_woutput+414

Followup: MachineOwner
— 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

–
Thanks & Regards

Pushkar Prasad | Email: xxxxx@eccellente-it.com | URL:
http://www.eccellente-it.com |

?A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.? -Herm Albright