--
8O)
Koldbear
Please reply to the Newsgroup
"RossH" <rhe...@nospam.bigpond.net.au> wrote in message news:u48FhjHxAHA.1620@tkmsftngp05...
Using System Restore in Windows Millennium:
http://members.home.net/winhelp98/restore.htm
_____________________________
Mike Burgess Microsoft MVP DTS
Information isn't free if you can't find it!
http://members.home.net/winhelp98/
Please post replies to this Newsgroup, email address is invalid
--
"RossH" <rhe...@nospam.bigpond.net.au> wrote in message
news:u48FhjHxAHA.1620@tkmsftngp05...
"Mike Burgess" <winh...@NOhome.com> wrote in message
news:uv2RxcIxAHA.1968@tkmsftngp05...
Yes, the frequency of automatic checkpoints can indeed be changed although I
am not sure of the benefits of doing so. Your post has prompted me to test
this in practice and I am now getting an automatic checkpoint every hour -
provided the system is idle.
If you really want to change System Restore's behaviour you need to be
prepared to work with the registry with all the risks that that might
involve. However, the details are as follows:
The frequency of automatic checkpoints is controlled by the binary value
"Next" found at
HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\RegSnapShotInterval
and also
HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\Cfg\RegSnapShotInter
val
The default hex value "a" represents a 10 hour interval. I have amended
this on this PC to "1" and following resetting of System Restore (this may
not be necessary) I am now getting automatic checkpoints every hour when the
machine is left idle and around every three hours or so when in use
(probably represents me getting a cup of coffee with the machine then being
idle).
--
Mike Maltby
mi...@mcmaltby.fsnet.co.uk
"RossH" <rhe...@nospam.bigpond.net.au> wrote ...
"RossH" <rhe...@nospam.bigpond.net.au> wrote ...
>Yes, the frequency of automatic checkpoints can indeed be changed although I
>am not sure of the benefits of doing so. Your post has prompted me to test
>this in practice and I am now getting an automatic checkpoint every hour -
>provided the system is idle.
>The frequency of automatic checkpoints is controlled by the binary value
>"Next" found at
>HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\RegSnapShotInterval
>and also
>HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\Cfg\RegSnapShotInter
>val
Is one of these a "master", updating the other, or do they have
different effects? Do you usually set both?
>The default hex value "a" represents a 10 hour interval. I have amended
>this on this PC to "1" and following resetting of System Restore (this may
>not be necessary) I am now getting automatic checkpoints every hour when the
>machine is left idle and around every three hours or so when in use
How wide is the value field? Thinking of very large values that would
effectively stop SR from making automatic checkpoints.
As SR is a state rather than file system backup, I'd use it explicitly
to preserve a state just before a 'widow-maker' install (e.g.
DirectX, or any other badly-behaved or MSware install that cannot be
trusted to uninstall itself properly).
But for the other 99% of the time that I am not in the process of
performing such installs, I'd want SR to do nothing, and specifically
to not consume massive wads of space in "engine-room" C:.
All the above can be done by selectively dis- and re-enabling SR, but
there's an added requirement; when SR is enabled, I'd like all SR data
sets to correspond to *known* states (ideally labeled as such, e.g.
"Before installing DirectX 8", "Before installing IE 6" etc.) rather
than some arbitrary state, e.g. possibly midway through an unattended
install (e.g. idle time while waiting for the inevitable reboot).
>--------------- ----- ---- --- -- - - -
Hello DOS mode my old friend
I've come to hack with you again
>--------------- ----- ---- --- -- - - -
Next is a dword so could presumably be set to something reasonably large but
have not tried setting it to any other value than 1 or a. I've now set it
to 30H (48 hours) and will see if it cuts back the creation of auto
checkpoints to every other day.
BTW if you want to reduce the space used by SR on your boot volume you can
reduce the space allocated. MS sets a minimum of 200MB but I am currently
using 100MB having set the value Min (another dword) to 64H. This dword
being found at
HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\ReservedDiskSpace
and
HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\Cfg\ReservedDiskSpac
e
I agree about only using SR to restore to a known state. Known states can
be created either by annotating manual checkpoints, using installers that
automatically create such checkpoints before starting an install. In my
case I log details of all installs using SFC so I always know the state of
an automatic checkpoint by reference to my SFC log.
Are you using the string "System Restore" at
HKLM\System\CurrentControlSet\Services\VxD\VxDMon for switching SR on and
off? Using this value to toggle SR on and off has the interesting side
effects of:
a) retaining existing checkpoints and related data when off
b) switching off archiving when off (useful if dumping crud from an SR
protected volume
c) not rebuilding vxdmon.dat when switched back on (unlike when using the
GUI) nor does it create a new checkpoint.
Incidentally I can confirm that it is vxdmon.dat that is actually used by
stmgr.exe to control what both SR and SFP are monitoring with vxdmon.dat
being built from FileList.xml each time that SR is cycled. If you are not
cycling SR to rebuild vxdmon.dat and are editing FileList.xml to remove SFP
protected items it is essential to remove the corresponding entries from
sfpdb.sfp (as you do) but not necessary if cycling SR. The draw back of
your method is that it is possible that a later update will add an entry to
sfpdb.sfp and thus re-enable the protection of a file you thought
unprotected since it still appears in vxdmon.dat. Cycling SR so as to
remove the reference to the protected file from vxdmon.dat would prevent a
file becoming "protected" behind your back.
Still looking for the registry corruption that appears to be causing some
users to see what I refer to as the "wininit.ini problem" although it
appears that in many cases a simple scanreg /fix is enough to cure the
problem.
--
Mike Maltby
mi...@mcmaltby.fsnet.co.uk
<cqu...@iafrica.com> wrote ...
>I've only played with "Next" for a couple of days. I suspect that the value
>HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\RegSnapShotInterval
>is the one that is used with the one at
>HKLM\Softw...\Micr...\Wind...\CurrentVer...\StateMgr\Cfg\RegSnapShotInterval
>being the base reference value used each time SR is cycled on.
>Next is a dword so could presumably be set to something reasonably large but
>have not tried setting it to any other value than 1 or a. I've now set it
>to 30H (48 hours) and will see if it cuts back the creation of auto
>checkpoints to every other day.
I note that numeric values in registry (such as NoDriveTypeAutoRun)
are often 4 bytes long, tho not sure if that's to be 32-bit data
register friendly from a performance viewpoint. Sounds good, tho;
FFFF would code for a lot of hours :-)
>BTW if you want to reduce the space used by SR on your boot volume you can
>reduce the space allocated. MS sets a minimum of 200MB but I am currently
>using 100MB having set the value Min (another dword) to 64H. This dword
>being found at
>HKLM\Software\Microsoft\Windows\CurrentVersion\StateMgr\ReservedDiskSpace
>and
>HKLM\Softw...\Micr...\Wind...\CurrentVers...\StateMgr\Cfg\ReservedDiskSpace
>I agree about only using SR to restore to a known state. Known states can
>be created either by annotating manual checkpoints, using installers that
>automatically create such checkpoints before starting an install.
That's one of the strategic reasons I want to be able to tame SR,
rather than rely on its exclusion - new sware may make no "undo"
provisions other than SR (tho clearly SR won't replace uninstall)
>Are you using the string "System Restore" at
>HKLM\System\CurrentControlSet\Services\VxD\VxDMon for switching SR on and
>off? Using this value to toggle SR on and off has the interesting side
>effects of:
>a) retaining existing checkpoints and related data when off
>b) switching off archiving when off (useful if dumping crud from an SR
>protected volume
>c) not rebuilding vxdmon.dat when switched back on (unlike when using the
>GUI) nor does it create a new checkpoint.
I hadn't been using registry (via .reg) to disable SR since I tried to
reproduce the effect of System, Performance, Troubleshooting, Disable
SR via .reg (it failed to work). Dunno if I was doing the same thing;
at the time the discussion suggested the lack of reboot had caused the
failure, but not sure whether this was inevitable or not (AFAICRl, I'd
applied the .reg and still found SR bloat after reboot)
>Incidentally I can confirm that it is vxdmon.dat that is actually used by
>stmgr.exe to control what both SR and SFP are monitoring with vxdmon.dat
>being built from FileList.xml each time that SR is cycled.
By "cycled", do you mean enabled/disabled?
>If you are not cycling SR to rebuild vxdmon.dat and are editing
>FileList.xml to remove SFP protected items it is essential to remove
>the corresponding entries from sfpdb.sfp (as you do) but not necessary
>if cycling SR.
OK, that sounds familiar from editing modem AT command strings via
regedit - the edits evaporate as soon as any "font door" changes cause
Windows to refresh the regsitry from the modem's .inf, so my SOP has
always been to edit the .inf (which is ;commentable) and then force a
registry update e.g. by "re-installing" the modem.
In this case, I'd edit FILELIST.XML and then cycle SR to refresh.
>The draw back of your method is that it is possible that a later update
>will add an entry to sfpdb.sfp and thus re-enable the protection of a file
>you thought unprotected since it still appears in vxdmon.dat.
OK; yes, that's a real threat in the context of WSH.
>Cycling SR so as to remove the reference to the protected file from
>vxdmon.dat would prevent a file becoming "protected" behind your back.
Hm. So, if I do my usual edits before disabling SR and then disable
SR, would that have the desired effect? (looking for an SOP that
involves as few hard-to-remember steps as possible)
Or is it the re-enabling of SR that updates the file?
>Still looking for the registry corruption that appears to be causing some
>users to see what I refer to as the "wininit.ini problem" although it
>appears that in many cases a simple scanreg /fix is enough to cure the
>problem.
With no other edits, that would suggest a structure rather than
content problem (I'd expect "/fix" to preserve all content that is
structurally sound, thus fail to fix a content problem)
<posted more food for thought - will think and digest>
> >Still looking for the registry corruption that appears to be causing some
> >users to see what I refer to as the "wininit.ini problem" although it
> >appears that in many cases a simple scanreg /fix is enough to cure the
> >problem.
>
> With no other edits, that would suggest a structure rather than
> content problem (I'd expect "/fix" to preserve all content that is
> structurally sound, thus fail to fix a content problem)
My thoughts exactly and for this reason I am a bit confused. That scanreg
/fix has been able to cure the "restart Me before using SR or "wininit""
problem suggests that Me may have problems with the registry that have yet
to see the light of day.
--
Mike Maltby
mi...@mcmaltby.fsnet.co.uk