Volume Shadow Copy problems

[at]

I've been trying to find the solution to a problem that makes audio
(recording or playback) unreliable. Something is constantly accessing
the disks on this vista machine (2 internal SATA drives and 3 external
USB drives).

Turning the Volume Shadow Copy service off eliminates the disk
thrashing and makes it possible to record or play audio files again,
but it also kills System Restore.

I edited the Registry to add all files on drives D, M, N, and Z to
"FilesNotToSnapshot". That reduces the thrashing a lot, but it still
happens and there are still audio problems, albeit not as many.

This is a 2.66GHz dual-core system with 2GB of RAM. It gets a 4.0
Vista performance score, so it seems that it should be capable of
playing audio files (Winamp or Itunes) without skipping and
stuttering.

If there is a way to set VSS so that it's active only when a backup
application needs it and when the system needs it to create a Restore
Point, I'd like to know how to accomplish this.

Thanks!
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups

 

[Jon]

Adding whole drives to 'FilesNotToSnapshot' is dangerous, since you could
potentially end up with System Restore deleting a whole load of legitimate
files on those drives, when you run a restore eg .exe files. You'd be better
turning off System Restore totally for those particular drives imho, which
you can do via 'System Protection'

--
Jon


in message
news:[email protected]...

 

[TechByter]

Adding whole drives to 'FilesNotToSnapshot' is dangerous, since you could
potentially end up with System Restore deleting a whole load of legitimate
files on those drives, when you run a restore eg .exe files. You'd be better
turning off System Restore totally for those particular drives imho, which
you can do via 'System Protection'

That's what's so puzzling about this. I had turned off System Restore
for all drives except C, but the disk thrashing continued. This seems
to be illustrating one of the maxims that I live by:
"Logical devices aren't."
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups

 

[Jon]

That's what's so puzzling about this. I had turned off System Restore
for all drives except C, but the disk thrashing continued. This seems
to be illustrating one of the maxims that I live by:
"Logical devices aren't."

Suggests that System Restore isn't the cause of the disk thrashing.

If you look in 'Reliability and Performance monitor' - 'Disk' section
(right pane), and look at the Image / File / Read / Write columns then it
may reveal the true culprit.

 

[TechByter]

If you look in 'Reliability and Performance monitor' - 'Disk' section
(right pane), and look at the Image / File / Read / Write columns then it
may reveal the true culprit.

I've had that open almost constantly in the past month and it's almost
always "system" reading from or writing to C:\System Volume
Information\{key} where {key} is a ridiculously long key value. In
some cases, I see something like this as the file name:
Device\HarddiskVolumeShadowCopy99\AUDIO\SomeFile.mp3
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups

 

[Jon]

I've had that open almost constantly in the past month and it's almost
always "system" reading from or writing to C:\System Volume
Information\{key} where {key} is a ridiculously long key value. In
some cases, I see something like this as the file name:
Device\HarddiskVolumeShadowCopy99\AUDIO\SomeFile.mp3

Ok, it does sound like System Restore then, writing to the latest snapshot
image, although perhaps drive C: is the problematic drive, rather than the
others.

Those long key values are the particular restore points, which also
encompasses previous versions.

mp3 isn't a monitored extension,

Monitored File Extensions
http://msdn2.microsoft.com/en-us/library/aa378870.aspx

(BTW Microsoft that list needs revising - it's missing a few, and some of
those in the list aren't monitored)

so I *think* that that means if you exclude it from your C: snapshot (in a
similar way to the way you excluded files on other drives, using the
registry key you mentioned) then it won't be deleted when you use a restore
point to restore. I'd hate to think of you having all your mp3 files deleted
on my advice, so it would be best to test out that theory first on a test
folder first.

Another option is to disable the automatic System Restore point in Task
Scheduler that runs at startup, in favour of your own scheduler, but I seem
to recall that being a bit tricky, since I think it's reset when you set a
System Protection point manually.

Anyhow a couple of ideas to play with.

 

[TechByter]

so I *think* that that means if you exclude it from your C: snapshot (in a
similar way to the way you excluded files on other drives, using the
registry key you mentioned) then it won't be deleted when you use a restore
point to restore. I'd hate to think of you having all your mp3 files deleted
on my advice, so it would be best to test out that theory first on a test
folder first.

Thanks for the references and the assistance. I'm still a Vista newbie
(or is that n00b?) so I'm mainly groping around in the dark. From what
I've read, System Restore isn't supposed to tinker with user files
("System Restore does not restore user data or documents, so it will
not cause users to lose their files, e-mail, browsing history, or
favorites." Source:
http://msdn2.microsoft.com/en-us/library/aa378724(VS.85).aspx). Or
does my adding these to the 'FilesNotToSnapshot' key in the Registry
put them at risk?

Microsoft says "The files that are monitored or excluded from
monitoring are specified in the file
%windir%\system32\restore\Filelist.xml", but the only file I find in
that location is MachineGuid.txt. That file consists of a single line
with the GUID and Search can't find filelist.xml on the C drive.

Another option is to disable the automatic System Restore point in Task
Scheduler that runs at startup, in favour of your own scheduler, but I seem
to recall that being a bit tricky, since I think it's reset when you set a
System Protection point manually.

If the problem persists, I could probably turn off VSS, but then I
would need to remember to enable it every day and make a manual system
restore point.

I notice that VSS always runs with normal I/O priority. Is there a way
to set it to lower priority or would that be barking up several wrong
trees at the same time?

I've attached 20080106-114239.png, which shows what the process does.
It just fires off these processes for no apparent reason.
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups

 

[Jon]

Thanks for the references and the assistance. I'm still a Vista newbie
(or is that n00b?) so I'm mainly groping around in the dark.

As are we all ....


From what

I've read, System Restore isn't supposed to tinker with user files
("System Restore does not restore user data or documents, so it will
not cause users to lose their files, e-mail, browsing history, or
favorites." Source:
http://msdn2.microsoft.com/en-us/library/aa378724(VS.85).aspx). Or
does my adding these to the 'FilesNotToSnapshot' key in the Registry
put them at risk?

True as far as it goes, but the grey area is over what is to be regarded as
'data' or as a 'document', and what is not.

We'd probably all agree that .txt and .doc files were "documents", and .exe
/ .dll files weren't, but how about .chm / .hlp / .msi / .ocx / .mp3 / vbs
/ .vbe / .js / .ex_ / .gi_ / .wsf files ?

Answers on a postcard.

Microsoft says "The files that are monitored or excluded from
monitoring are specified in the file
%windir%\system32\restore\Filelist.xml", but the only file I find in
that location is MachineGuid.txt. That file consists of a single line
with the GUID and Search can't find filelist.xml on the C drive.

Yep, I looked for that very same file recently too. Exists on XP, but not on
Vista. Vista's System Restore works differently.

I don't profess to know all the ins and outs of it at this stage, but I
believe the extensions are hard-coded into the dlls in Vista, rather than
the flexibility that there was under XP. I'm happy to be corrected on this
one, though

If the problem persists, I could probably turn off VSS, but then I
would need to remember to enable it every day and make a manual system
restore point.

I notice that VSS always runs with normal I/O priority. Is there a way
to set it to lower priority or would that be barking up several wrong
trees at the same time?

I don't know how to lower its i/o priority, but you could certainly lower
its overall priority eg via a startup script. The value of doing so would be
pretty debatable, as a long-term solution.

I've attached 20080106-114239.png, which shows what the process does.
It just fires off these processes for no apparent reason.

Yep, saw that - that is odd. I don't know what else to suggest at this
stage, other than to experiment with some of the earlier suggestions + your
own suggestions, keep reading, and see what works.

Anyhow hope that helps a bit.

 

[TechByter]

We'd probably all agree that .txt and .doc files were "documents", and .exe
/ .dll files weren't, but how about .chm / .hlp / .msi / .ocx / .mp3 / vbs
/ .vbe / .js / .ex_ / .gi_ / .wsf files ?

Hmmm. Good point.

I don't know how to lower its i/o priority, but you could certainly lower
its overall priority eg via a startup script. The value of doing so would be
pretty debatable, as a long-term solution.

My short-term solution is to simply shut off VSS entirely and to turn
it on once per day (or week) to create a restore point. When I do
that, the system works fine. This is not a viable long-term solution,
though. I'm hoping that SP1 may resolve the problem, but I suspect
that it won't.

Yep, saw that - that is odd. I don't know what else to suggest at this
stage, other than to experiment with some of the earlier suggestions + your
own suggestions, keep reading, and see what works.

At least I'm not encountering a "been there, done that, got the
T-shirt" problem.
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups