RE: KB913648 Volume Shadow Copy Service update

Hi,

Based on the error event log, I performed lots of research and I found some
possible cause:



Cause 1
A driver installed on the system is using an excessive amount of non-paged
pool. This may indicate a memory leak. See ¡°SOX040818700038 Error returned
while creating the volume shadow copy:80¡±

Solution
Install Poolmon.exe and monitor on the system. Poolmon will list which pool
tags are consuming non-paged pool. We can then determine the driver by
matching up the pool tag in the KB. If the KB does not contain a good
pointer we can then try the following. On the system in question run the
following command.

findstr /mi <PoolTagListing> <Path to search>

This will search inside of all files in the search path and point out those
that contain the suspect pool tag. We can then attempt to eliminate each
driver in the listing. Be sure to search %systemroot%\system32 as well as
\program files

Cause 2:
VOLSNAP.SYS driver used to take and manage volume snapshots requires paged
pool memory to keep track of previous versions of files. The amount of
paged pool used for a snapshot with sufficiently many files touched on it
is about 1 byte per file. Whenever a new block of 65536 files is touched,
65536 bytes of paged pool are allocated. However, this also all depends on
how many snapshots are currently mounted. This works out so that a server
with 2 million files or less and 64 snapshots will always stay below the
recommended 128 MB of paged pool threshold. A server with more files might
be able to manipulate the snapshot storage size so that fewer than 64
snapshots are kept.

Solution:
Reduce the amount of snapshot storage used for all volumes so that your
total paged pool usage stays within limits. You can use VSSADMIN.EXE to
re-size the shadow storage size.

EXAMPLE: (where s: is the volumes used for shadow copies)

vssadmin resize shadowstorage /for=<drive letter>: /on=s: /maxsize=36GB



Cause 3:
3GB enabled in the boot.ini. In some cases, if we look at the drivers that
are currently installed, the size of the snapshot storage, and the amount
of data being written on the server, we may just run out of pool space.
With 3GB enabled reduces the amount of pool we have available to us
compared to a system without 3GB.

Solution:
Remove the 3GB switch from the boot.ini

Hope this helps.

Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



--------------------
Thread-Topic: KB913648 Volume Shadow Copy Service update
thread-index: AcbTgKv2vb6ymLO6Q/i3OMAz6uA1Sg==
X-WBNR-Posting-Host: 67.107.239.103
From: =?Utf-8?B?RGFuIERhdmlz?= <In_Finite@xxxxxxxxxxxxxx>
Subject: KB913648 Volume Shadow Copy Service update
Date: Fri, 8 Sep 2006 12:55:02 -0700
Lines: 56
Message-ID: <5D99363C-DA85-4101-9AE3-6AECF5661F08@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.windows.file_system
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.file_system:9744
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.windows.file_system

UPDATE: The NPP problem seems to have subsided, but probably because the
VSS
changes are minimal and the bitmap for the snapshot hasn't exceeded the
remaining NPP. What has not changed is that after a reboot, we still
lose
any previous snapshots.

Event ID: 20
Source: VolSnap
The shadow copies of volume D: were aborted because of a failed free
space
computation.

Are there any new VolSanp updates that I can't find or is there soem kind
of
alternate solution I'm missing?

OLD POST=============
KB article http://support.microsoft.com/kb/913648/en-us promsies hope,
yet
fails to deliver.

I'm using Veritas Backup Exec 10d CPS to pull from 4 other servers to an
8TB
volume (D:\CPS\BD1\); we're about 50% capacity right now. Changes are
fairly
minimal through the day, ranging from a few hundred MB to maybe a couple
GB.
CPS is a writer for VSS and takes hourly snapshots to a dedicated shadow
drive/volume (E:\).

Oh, things work great for about 4 days until the inevitable VolSnap Event
ID: 5
"The shadow copy of volume D: could not be created due to insufficient
non-paged memory pool for a bitmap structure."

Yah, well I've been following the VSS updates as they become available,
each
with its own set of promises unfulfilled. What's really whacky about
this
error is that it claims the NPP is exhausted. I'm using Mark's 'System
Information', which shows NPP Limit is 261,756MB of which only 135,328MB
have
been consumed (Poolmon shows the same usage). This must infer that VSS
is
asking for more than 126,428MB to create its bitmap, or that in its
request,
doesn't leave enough NPP leftover. Within the first two days of a reboot
NPP
is right up there near 125MB used, so why does the next 10MB kill it?



Top 15 offenders of NPP
VoSm Nonp 61,042,712 [volsnap.sys - Bitmap allocations]
CMpa Nonp 16,083,968 [nt!cm - registry post apcs]
MmCm Nonp 8,757,520 [nt!mm - Calls made to MmAllocateC
CM44 Nonp 8,042,152 Unknown Driver
SeTd Nonp 2,661,440 [nt!se - Security Token dynamic pa
LSwi Nonp 2,584,576 [<unknown> - initial work context
MmCa Nonp 2,443,616 [nt!mm - Mm control areas for mapp
Vad Nonp 1,514,544 [nt!mm - Mm virtual address descri
TCPt Nonp 1,456,480 Unknown Driver
File Nonp 1,354,232 [<unknown> - File objects]
Pool Nonp 1,134,592 [<unknown> - Pool tables, etc.]
Thre Nonp 906,672 [nt!ps - Thread objects]
NDpp Nonp 702,864 [ndis.sys - packet pool]
Even Nonp 593,216 [<unknown> - Event objects]
Devi Nonp 551,160 [<unknown> - Device objects]



.

Relevant Pages

  • RE: KB913648 Volume Shadow Copy Service update
    ... I did provide a poolmon report showing the npp usage. ... I typically maintain 15-20 snapshots of 1.8 million files taking around ... A driver installed on the system is using an excessive amount of non-paged ... Poolmon will list which pool ...
    (microsoft.public.windows.file_system)
  • RE: KB913648 Volume Shadow Copy Service update
    ... When responding to posts, please "Reply to Group" via your newsreader so ... You've already posted this idea about resizing the shadow storage due to ... VOLSNAP.SYS driver used to take and manage volume snapshots requires ...
    (microsoft.public.windows.file_system)
  • Re: errors that keep on coming up
    ... Param3= Memory contents of the pool block ... Read below or type Verifier in Start Run and choose the max in the wizard. ... How to Use Driver Verifier to Troubleshoot Windows Drivers ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: errors that keep on coming up
    ... Param3= Memory contents of the pool block ... Read below or type Verifier in Start Run and choose the max in the wizard. ... How to Use Driver Verifier to Troubleshoot Windows Drivers ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: BSOD BAD_POOL_HEADER
    ... memory which was allocated for another driver. ... Parameter 2 - The pool entry we were looking for within the page. ... i.e. turn on Special Pool + Pool Tracking for all drivers. ...
    (microsoft.public.development.device.drivers)
Loading