\WINNT\SYSTEM32\CONFIG\SYSTEM file size problem - prevention?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there a way of pro-actively reducing the size of the
\WINNT\SYSTEM32\CONFIG\SYSTEM file before it reaches a size which will cause
the "Windows could not start because the following file is missing or
corrupt" error?

There seems to be a lot of information out there about how to recover once
the problem has occurred, but nothing to suggest how to stop it from
happening in the first place.

In our scenario we run a fleet of several hundred Windows 2000 Pro
workstations which are accessed every day by students. These days each
student comes armed with a USB storage device which they plug in to the
workstation they happen to be using that day.

We are finding that each time a user plugs in a new USB device, Windows 2000
adds an entry to the HKLM\ Systems\CurrentControlSet\enum\USB and
HKLM\Systems\CurrentControlSet\enum\USBStore hives in the registry. With a
high turnover of students using the computers we are seeing a lot of
different devices being registered in this way.

In turn this causes the \systemroot\config\SYSTEM file to grow. As the
maximum size of this file appears to be 13 MB, we are starting to see
machines failing to boot with the error “Windows could not start because the
following file is missing or corrupt:\WINNT\SYSTEM32\CONFIG\SYSTEM “.
Recovering from this error is a painful process requiring us to visit the
affected machine and use the Recovery console (or re-image the machine).

Deleting the entries in the registry wuld be easy to automate, but this does
not appear to impact on the size of the SYSTEM file, and registry cleaners
and registry defrags have had no effect. The only information that seems to
be around on the Microsoft site, or on the web relates to using the recovery
console, which is fine for a one off solution, but with a couple of hundred
PCs which might start to develop the problem we are hoping to find a way of
preventing it from happening in the first place.

Any suggestions would be appreciated, or even some confirmation that what we
want to be able to do just isn't possible without using something like Deep
Freeze.

Thanks, Sarah
 
Sarah G said:
Is there a way of pro-actively reducing the size of the
\WINNT\SYSTEM32\CONFIG\SYSTEM file before it reaches a size which will cause
the "Windows could not start because the following file is missing or
corrupt" error?

There seems to be a lot of information out there about how to recover once
the problem has occurred, but nothing to suggest how to stop it from
happening in the first place.

In our scenario we run a fleet of several hundred Windows 2000 Pro
workstations which are accessed every day by students. These days each
student comes armed with a USB storage device which they plug in to the
workstation they happen to be using that day.

We are finding that each time a user plugs in a new USB device, Windows 2000
adds an entry to the HKLM\ Systems\CurrentControlSet\enum\USB and
HKLM\Systems\CurrentControlSet\enum\USBStore hives in the registry. With a
high turnover of students using the computers we are seeing a lot of
different devices being registered in this way.

In turn this causes the \systemroot\config\SYSTEM file to grow. As the
maximum size of this file appears to be 13 MB, we are starting to see
machines failing to boot with the error "Windows could not start because the
following file is missing or corrupt:\WINNT\SYSTEM32\CONFIG\SYSTEM ".
Recovering from this error is a painful process requiring us to visit the
affected machine and use the Recovery console (or re-image the machine).

Deleting the entries in the registry wuld be easy to automate, but this does
not appear to impact on the size of the SYSTEM file, and registry cleaners
and registry defrags have had no effect. The only information that seems to
be around on the Microsoft site, or on the web relates to using the recovery
console, which is fine for a one off solution, but with a couple of hundred
PCs which might start to develop the problem we are hoping to find a way of
preventing it from happening in the first place.

Any suggestions would be appreciated, or even some confirmation that what we
want to be able to do just isn't possible without using something like Deep
Freeze.

Thanks, Sarah
Click to expand...

Have you considered the possibility that your problems in starting
Win2000 might not at all be related to the ***size*** of the system
registry file but rather to its contents? I think this is far more probable.

In your situation I would do this:
- Use regback.exe to create a backup of the registry.
- Let the machine run until it fails.
- Copy the saved registry files back over the flawed originals.

If your system disk uses the FAT32 file system then you can
perform the last step by booting the machine with a Win98
boot disk. If it uses NTFS then you can do it equally easily
with a Bart PE boot CD.

Some people use imaging techniques when operating in a
highly volatile environment: They simply restore each machine
to the standard image at the end of each day.
 
Thanks for your speedy comments.

I appreciate that there are a number of dcumented ways of resolving the
problem once it occurs, but all require an administrator to go to the machine
(physically or virtually). Restoring a backup of the registry is certainly a
fix once a machine is broken, but we are trying to avoid all of this by
preventing the problem in the first place.

We have certainly looked at refreshing images in the past or using Deep
Freeze type technologies, but up until now have found this unecessary. Our
research indicates that the size is the root cause of the issues we are
seeing. If there is no way of preventing the continual growth of the
config\system file we may need to revist this idea.

Good system management points to prevention rather than cure, and I just
have difficulty accepting that a essential file like this can just keeping
growing in size and cannot be managed. The eternal optomist, I keep telling
myself "There must be a way..."

Sarah
 
I fully agree with your philsophy but I'm uncomfortable with
your identification of the root cause. Unless you can really
nail it down you might find that you're solving the wrong
problem when attempting to limit the size of the registry.
 
The registry is organized as a B-tree and is _very_ fast to search,
insert and delete items. Your students using the machines probably do
many, many registry accesses all of which take a bit of time. Note my
Quicken database is bigger than my registry and it is fast to use.
As another poster said, you need to track down the root cause of the
slowness, but you don't have to worry about the size of the registry files.
 
Stubby said:
That talks about damaged system hive. Damage is different than being
Click to expand...
big.

Yes, it does:
"Windows 2000 may be unable to load the registry if it is too large."
 
The former talks about a situation that can be caused by system hive bloat.
The system hive must be small enough to fit in the 16 megabytes (MB) of
memory are available during the startup process for Windows 2000.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| > Actually the size of the system hive in Windows 2000 is a concern.
| > http://support.microsoft.com/?kbid=269075
| That talks about damaged system hive. Damage is different than being
big.
|
|
| > It got better with Windows Server 2003
| > http://support.microsoft.com/kb/302594/
| This talks about how big the system hive can be, but doesn't express any
| concern about it being "too big". It cites the article above.
 
I vaguely remember reading an article somewhere which stated that runaway
registry growth was caused by defective software. It's possible that a
program is adding and deleting keys in such a way that the size of the
file grows rapidly even though the cumulate size of the contents is not
changing significantly. A way to detect this might be to compare the size
of the system file in \WINNT\system32\config with
\WINNT\repair\RegBack\system resulting from a recent backup. If the files
differ significantly is size, this sort of thing may be th cause of the
excessive growth.
 
Hi folks,

Just to close this question off, we have resolved the issue using a Symantec
utility called vxscrub. It strips out all the data about mounted volumes (in
our case USB stoarge device information in the USBSTOR) and shrinks the
registry. As it is ommand line utility we have scheduled it to run as part
of our normal maintenance.

http://seer.entsupport.symantec.com/docs/277301.htm

Many thanks to Tim from commander.com for identifying this utility for us.

Regards, Sarah
 
Thanks for the feedback - very useful. I wish more posters
would do this when they finally find a solution for their
problem . . .

If the utility is stable then you might want to run it as a
regular scheduled job, e.g. once a week. It would reduce
your maintenance work.


Sarah G said:
Hi folks,

Just to close this question off, we have resolved the issue using a Symantec
utility called vxscrub. It strips out all the data about mounted volumes (in
our case USB stoarge device information in the USBSTOR) and shrinks the
registry. As it is ommand line utility we have scheduled it to run as part
of our normal maintenance.

http://seer.entsupport.symantec.com/docs/277301.htm

Many thanks to Tim from commander.com for identifying this utility for us.

Regards, Sarah

Dave Patrick said:
The former talks about a situation that can be caused by system hive bloat.
The system hive must be small enough to fit in the 16 megabytes (MB) of
memory are available during the startup process for Windows 2000.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| > Actually the size of the system hive in Windows 2000 is a concern.
| > http://support.microsoft.com/?kbid=269075
| That talks about damaged system hive. Damage is different than being
big.
|
|
| > It got better with Windows Server 2003
| > http://support.microsoft.com/kb/302594/
| This talks about how big the system hive can be, but doesn't express any
| concern about it being "too big". It cites the article above.
Click to expand...
Click to expand...
 
Very good tip! Thank you very much for the information!

John

Sarah said:
Hi folks,

Just to close this question off, we have resolved the issue using a Symantec
utility called vxscrub. It strips out all the data about mounted volumes (in
our case USB stoarge device information in the USBSTOR) and shrinks the
registry. As it is ommand line utility we have scheduled it to run as part
of our normal maintenance.

http://seer.entsupport.symantec.com/docs/277301.htm

Many thanks to Tim from commander.com for identifying this utility for us.

Regards, Sarah

:

The former talks about a situation that can be caused by system hive bloat.
The system hive must be small enough to fit in the 16 megabytes (MB) of
memory are available during the startup process for Windows 2000.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| > Actually the size of the system hive in Windows 2000 is a concern.
| > http://support.microsoft.com/?kbid=269075
| That talks about damaged system hive. Damage is different than being
big.
|
|
| > It got better with Windows Server 2003
| > http://support.microsoft.com/kb/302594/
| This talks about how big the system hive can be, but doesn't express any
| concern about it being "too big". It cites the article above.
Click to expand...
Click to expand...
 
Ditto, thanks for letting us know.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Hi folks,
|
| Just to close this question off, we have resolved the issue using a
Symantec
| utility called vxscrub. It strips out all the data about mounted volumes
(in
| our case USB stoarge device information in the USBSTOR) and shrinks the
| registry. As it is ommand line utility we have scheduled it to run as
part
| of our normal maintenance.
|
| http://seer.entsupport.symantec.com/docs/277301.htm
|
| Many thanks to Tim from commander.com for identifying this utility for us.
|
| Regards, Sarah
 
Back
Top