RE: KB913648 Volume Shadow Copy Service update

Hi Dan,

Thanks for your patience. I posted your issue in our internal forum and I
will get back to you if there is any feedback.

Thanks.


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.
======================================================



--------------------
X-Tomcat-ID: 180459477
References: <5D99363C-DA85-4101-9AE3-6AECF5661F08@xxxxxxxxxxxxx>
<qqEoj0U1GHA.2156@xxxxxxxxxxxxxxxxxxxxx>
<FCEEE082-70D6-4279-84E1-EAD00234E846@xxxxxxxxxxxxx>
<vXzLmT81GHA.396@xxxxxxxxxxxxxxxxxxxxx>
<F1BD8388-F8CE-4620-89BF-4E6907AAA8C3@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: v-xuwen@xxxxxxxxxxxxxxxxxxxx (Vincent Xu [MSFT])
Organization: Microsoft
Date: Fri, 15 Sep 2006 09:00:45 GMT
Subject: RE: KB913648 Volume Shadow Copy Service update
X-Tomcat-NG: microsoft.public.windows.file_system
Message-ID: <Lz247VK2GHA.4280@xxxxxxxxxxxxxxxxxxxxx>
Newsgroups: microsoft.public.windows.file_system
Lines: 376
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.file_system:9792
NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182

Hi Dan,

This is a quick note to let you know that I am researching your issue and
will get back to you as soon as possible. I appreciate your patience.


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: AcbYNxtqOrF4gWNPSSuB4fPHb3bAaA==
X-WBNR-Posting-Host: 67.107.239.103
From: =?Utf-8?B?RGFuIERhdmlz?= <In_Finite@xxxxxxxxxxxxxx>
References: <5D99363C-DA85-4101-9AE3-6AECF5661F08@xxxxxxxxxxxxx>
<qqEoj0U1GHA.2156@xxxxxxxxxxxxxxxxxxxxx>
<FCEEE082-70D6-4279-84E1-EAD00234E846@xxxxxxxxxxxxx>
<vXzLmT81GHA.396@xxxxxxxxxxxxxxxxxxxxx>
Subject: RE: KB913648 Volume Shadow Copy Service update
Date: Thu, 14 Sep 2006 12:51:02 -0700
Lines: 320
Message-ID: <F1BD8388-F8CE-4620-89BF-4E6907AAA8C3@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
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:9784
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.windows.file_system

Vincent,

Without being extraordinarily rude, I feel like I'm talking to a 1st
level
Dell support rep here.

You've already posted this idea about resizing the shadow storage due
to
excessive PP memory usage, however, based on your math of 1 byte per
file, I
shouldn't be exceeding 36MB of PP memory.

I previously stated the following:
typically maintain 15-20 snapshots of 1.8 million files taking around
500GB of storage.

So with all of this out of the way, what would be causing VSS to abort
previous snapshots upon reboot?

-Dan


"Vincent Xu [MSFT]" wrote:

Hi ,

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 as seen in the sample batch file:

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

vssadmin resize shadowstorage /for=f: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=g: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=h: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=i: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=j: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=k: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=l: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=m: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=n: /on=s: /maxsize=30GB
vssadmin resize shadowstorage /for=x: /on=s: /maxsize=10GB

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: AcbXe6FeJZ7OY4OKQB2NKQ7IZ2YGOg==
X-WBNR-Posting-Host: 67.107.239.103
From: =?Utf-8?B?RGFuIERhdmlz?= <In_Finite@xxxxxxxxxxxxxx>
References: <5D99363C-DA85-4101-9AE3-6AECF5661F08@xxxxxxxxxxxxx>
<qqEoj0U1GHA.2156@xxxxxxxxxxxxxxxxxxxxx>
Subject: RE: KB913648 Volume Shadow Copy Service update
Date: Wed, 13 Sep 2006 14:29:01 -0700
Lines: 194
Message-ID: <FCEEE082-70D6-4279-84E1-EAD00234E846@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
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:9775
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.windows.file_system

Vincent,

I'm not sure you read my full post. Please read my full post.

I did provide a poolmon report showing the npp usage.
I'm currently getting an Event ID 20 after a reboot.
I am NOT using /3G
I typically maintain 15-20 snapshots of 1.8 million files taking
around
500GB of storage.

From what I understand, I'm well within sane limits of VSS, yet it
still
fails to maintain snapshots between reboots. This is very
unacceptable
since
both MS & Veritas boast so well about this type of setup.

-Dan


"Vincent Xu [MSFT]" wrote:

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]




.

Relevant Pages

  • RE: KB913648 Volume Shadow Copy Service update
    ... The shadow copies of volume Letter: were aborted because of a failed free ... When responding to posts, please "Reply to Group" via your newsreader so ... KB913648 Volume Shadow Copy Service update ... VOLSNAP.SYS driver used to take and manage volume snapshots ...
    (microsoft.public.windows.file_system)
  • RE: KB913648 Volume Shadow Copy Service update
    ... VOLSNAP is trying to allocate non paged pool memory so that it ... pool for bitmaps for every TB of volume that has snapshots. ... When responding to posts, please "Reply to Group" via your newsreader so ... The shadow copies of volume D: were aborted because of a failed free ...
    (microsoft.public.windows.file_system)
  • RE: KB913648 Volume Shadow Copy Service update
    ... The shadow copies of volume Letter: were aborted because of a failed free ... When responding to posts, please "Reply to Group" via your newsreader so ... Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.file_system:9823 ... VOLSNAP.SYS driver used to take and manage volume snapshots ...
    (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: KB913648 Volume Shadow Copy Service update
    ... You've already posted this idea about resizing the shadow storage due to ... VOLSNAP.SYS driver used to take and manage volume snapshots requires paged ... 65536 bytes of paged pool are allocated. ...
    (microsoft.public.windows.file_system)