famous \Winnt\System32\Config\Systemced

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

Guest

Hello All,
This issue is killing me right now. The Helpdesk in my company have rebuilt
atleast 10 machines now with the famous systemced error. I understand when
the hive gets fragmemented & goes over 16MB system crashes. We have followed
following doc in fixing the workstaions
http://support.microsoft.com/?kbid=269075.

My questions is we have couple of machines that were built from scratch not
by imaging & they were in production for only few weeks before they died from
the systemced error.

I was wondering on what causes some machine to crash due to this error &
others never have this issue or its a ticking time bomb waiting to explode?
So can we expect all of our win2k machines to go through this issue?


Thanks in advance.....
 
No, not normal. You'll need to get to the bottom of what you're installing
that is causing the registry bloat.

--

Regards,

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

:
| Hello All,
| This issue is killing me right now. The Helpdesk in my company have
rebuilt
| atleast 10 machines now with the famous systemced error. I understand when
| the hive gets fragmemented & goes over 16MB system crashes. We have
followed
| following doc in fixing the workstaions
| http://support.microsoft.com/?kbid=269075.
|
| My questions is we have couple of machines that were built from scratch
not
| by imaging & they were in production for only few weeks before they died
from
| the systemced error.
|
| I was wondering on what causes some machine to crash due to this error &
| others never have this issue or its a ticking time bomb waiting to
explode?
| So can we expect all of our win2k machines to go through this issue?
|
|
| Thanks in advance.....
|
 
Dave,
Thanks for your response, Funny thing is all the machines have same programs
installed. We have pretty strict restrictions on what can be installed.
Machines are audited regularly. Machines are scanned regularly for viruses &
are updated regularly from WSUS. Updates are throughly tested in test
environment prior to rollout.

Lost on this issue, not sure on where to start looking.

Thanks again for your response.

Pete
 
Well you never did tell us..... was the registry corrupt or bloated on the
affected machines?

--

Regards,

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

:
| Dave,
| Thanks for your response, Funny thing is all the machines have same
programs
| installed. We have pretty strict restrictions on what can be installed.
| Machines are audited regularly. Machines are scanned regularly for viruses
&
| are updated regularly from WSUS. Updates are throughly tested in test
| environment prior to rollout.
|
| Lost on this issue, not sure on where to start looking.
|
| Thanks again for your response.
|
| Pete
 
Dave,
We did start using regmon from sysinternal. I thought you might have a idea
on certain programs (ex: office with certain sp level) that had known issues.

Thanks again for your response....
 
No, none that I know of. Windows 2000 and SP4 have been out long enough now
that something like that would have long-ago been discovered.

Something to try. (of course you'll need to catch it before it blows up
again) but;

Programs|Accessories|System Tools|Backup, then choose ERD, then if you check
the box for "Also backup....", then the reg will also be backed up to
%systemroot%\repair\RegBack
leaving the
%systemroot%\repair\
directory files intact as original installation. This should compact the
hive during the backup.

Then compare the size of the system hive found in;
%systemroot%\repair\RegBack
with that of the in use hive found in;
%systemroot%\system32\config

If you see an improvement in size then you can replace registry hives from
within the recovery console by copying the files from
%systemroot%\repair\regback
to
%systemroot%\system32\config
(the system hive is all that should be necessary at this point)

This might indicate some process using the registry as a temporary data
store.

To start the Recovery Console, start the computer from the Windows 2000
Setup CD or the Windows 2000 Setup floppy disks. If you do not have Setup
floppy disks and your computer cannot start from the Windows 2000 Setup CD,
use another Windows 2000-based computer to create the Setup floppy disks. At
the "Welcome to Setup" screen. Press F10 or R to repair a Windows 2000
installation, and then press C to use the Recovery Console. The Recovery
Console then prompts you for the administrator password. If you do not have
the correct password, Recovery Console does not allow access to the
computer. If an incorrect password is entered three times, the Recovery
Console quits and restarts the computer. Note If the registry is corrupted
or missing or no valid installations are found, the Recovery Console starts
in the root of the startup volume without requiring a password. You cannot
access any folders, but you can carry out commands such as chkdsk, fixboot,
and fixmbr for limited disk repairs. Once the password has been validated,
you have full access to the Recovery Console, but limited access to the hard
disk. You can only access the following folders on your computer: drive
root, %systemroot% or %windir%

--

Regards,

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

:
| Dave,
| We did start using regmon from sysinternal. I thought you might have a
idea
| on certain programs (ex: office with certain sp level) that had known
issues.
|
| Thanks again for your response....
 
Can you describe a little more about these systems? We have seen this
problem from multiple sources: DHCP, DNS, DFS (really too many shares in
general), systems with lots of printers (I believe this was fixed before
SP4), Storage (especially systems with very active PnP - snapshotting would
be an example, or even flaky interconnects), USB (again, flaky connections
can cause lots of device objects to be created but it would take a lot).

http://support.microsoft.com/kb/277222/en-us describes the storage issue and
how to recover
http://support.microsoft.com/kb/837330/en-us discusses an issue related to
group policy
http://support.microsoft.com/kb/269075/ discusses an issue with an older
Promise ATA controller

The scrubber tool is discussed in 277222 - this only targets disk storage
related "stale" registry entries. If you see the backing store (system file)
go above 10MB, you are heading for trouble. In might even be too late since
the current control set will replicate to Last Known Good after the next
boot. There are resource kit tools to check the size of various keys - this
can be helpful in locating the bloat.

This problem should not be related to Office or other application software
since they use the software hive, not the system hive. That's not subject to
the 16MB maximum.

Dave Patrick said:
No, none that I know of. Windows 2000 and SP4 have been out long enough
now
that something like that would have long-ago been discovered.

Something to try. (of course you'll need to catch it before it blows up
again) but;

Programs|Accessories|System Tools|Backup, then choose ERD, then if you
check
the box for "Also backup....", then the reg will also be backed up to
%systemroot%\repair\RegBack
leaving the
%systemroot%\repair\
directory files intact as original installation. This should compact the
hive during the backup.

Then compare the size of the system hive found in;
%systemroot%\repair\RegBack
with that of the in use hive found in;
%systemroot%\system32\config

If you see an improvement in size then you can replace registry hives from
within the recovery console by copying the files from
%systemroot%\repair\regback
to
%systemroot%\system32\config
(the system hive is all that should be necessary at this point)

This might indicate some process using the registry as a temporary data
store.

To start the Recovery Console, start the computer from the Windows 2000
Setup CD or the Windows 2000 Setup floppy disks. If you do not have Setup
floppy disks and your computer cannot start from the Windows 2000 Setup
CD,
use another Windows 2000-based computer to create the Setup floppy disks.
At
the "Welcome to Setup" screen. Press F10 or R to repair a Windows 2000
installation, and then press C to use the Recovery Console. The Recovery
Console then prompts you for the administrator password. If you do not
have
the correct password, Recovery Console does not allow access to the
computer. If an incorrect password is entered three times, the Recovery
Console quits and restarts the computer. Note If the registry is corrupted
or missing or no valid installations are found, the Recovery Console
starts
in the root of the startup volume without requiring a password. You cannot
access any folders, but you can carry out commands such as chkdsk,
fixboot,
and fixmbr for limited disk repairs. Once the password has been validated,
you have full access to the Recovery Console, but limited access to the
hard
disk. You can only access the following folders on your computer: drive
root, %systemroot% or %windir%

--

Regards,

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

:
| Dave,
| We did start using regmon from sysinternal. I thought you might have a
idea
| on certain programs (ex: office with certain sp level) that had known
issues.
|
| Thanks again for your response....
Click to expand...
 
Jeff & Dave,
Thanks for you input with the systemced issue that I am having.

Jeff here are details on machines that were getting systemced issue.

All of them dell workstation with win2k OS with sp4. All of them are getting
their ip from DHCP, couple of them might have reservation from DHCP.

These machines have only 1 harddrive with no external raid controller.
Group Policy, we are not pushing down any compliticated settings besides
normal such as Password & audit policies.

I read up on the scrubber tool & it would not apply in my situation because
all of these machines are running win2k professional with built in harddrive.

Thanks again,
Pete

Jeff Goldner said:
Can you describe a little more about these systems? We have seen this
problem from multiple sources: DHCP, DNS, DFS (really too many shares in
general), systems with lots of printers (I believe this was fixed before
SP4), Storage (especially systems with very active PnP - snapshotting would
be an example, or even flaky interconnects), USB (again, flaky connections
can cause lots of device objects to be created but it would take a lot).

http://support.microsoft.com/kb/277222/en-us describes the storage issue and
how to recover
http://support.microsoft.com/kb/837330/en-us discusses an issue related to
group policy
http://support.microsoft.com/kb/269075/ discusses an issue with an older
Promise ATA controller

The scrubber tool is discussed in 277222 - this only targets disk storage
related "stale" registry entries. If you see the backing store (system file)
go above 10MB, you are heading for trouble. In might even be too late since
the current control set will replicate to Last Known Good after the next
boot. There are resource kit tools to check the size of various keys - this
can be helpful in locating the bloat.

This problem should not be related to Office or other application software
since they use the software hive, not the system hive. That's not subject to
the 16MB maximum.

Dave Patrick said:
No, none that I know of. Windows 2000 and SP4 have been out long enough
now
that something like that would have long-ago been discovered.

Something to try. (of course you'll need to catch it before it blows up
again) but;

Programs|Accessories|System Tools|Backup, then choose ERD, then if you
check
the box for "Also backup....", then the reg will also be backed up to
%systemroot%\repair\RegBack
leaving the
%systemroot%\repair\
directory files intact as original installation. This should compact the
hive during the backup.

Then compare the size of the system hive found in;
%systemroot%\repair\RegBack
with that of the in use hive found in;
%systemroot%\system32\config

If you see an improvement in size then you can replace registry hives from
within the recovery console by copying the files from
%systemroot%\repair\regback
to
%systemroot%\system32\config
(the system hive is all that should be necessary at this point)

This might indicate some process using the registry as a temporary data
store.

To start the Recovery Console, start the computer from the Windows 2000
Setup CD or the Windows 2000 Setup floppy disks. If you do not have Setup
floppy disks and your computer cannot start from the Windows 2000 Setup
CD,
use another Windows 2000-based computer to create the Setup floppy disks.
At
the "Welcome to Setup" screen. Press F10 or R to repair a Windows 2000
installation, and then press C to use the Recovery Console. The Recovery
Console then prompts you for the administrator password. If you do not
have
the correct password, Recovery Console does not allow access to the
computer. If an incorrect password is entered three times, the Recovery
Console quits and restarts the computer. Note If the registry is corrupted
or missing or no valid installations are found, the Recovery Console
starts
in the root of the startup volume without requiring a password. You cannot
access any folders, but you can carry out commands such as chkdsk,
fixboot,
and fixmbr for limited disk repairs. Once the password has been validated,
you have full access to the Recovery Console, but limited access to the
hard
disk. You can only access the following folders on your computer: drive
root, %systemroot% or %windir%

--

Regards,

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

:
| Dave,
| We did start using regmon from sysinternal. I thought you might have a
idea
| on certain programs (ex: office with certain sp level) that had known
issues.
|
| Thanks again for your response....
Click to expand...
Click to expand...
 
OK, something else must be creating lots of junk in the system hive. (DHCP
issue occurs on DHCP server, not client). You can analyze this using various
resource kit tools. For simple configurations I would expect only a few MBs
in the system hive, but it looks like you are maxed out. Verify this by
checking the size of system in the system32\config directory. If system (no
extensions) is larger than 10MB you are in trouble.

I would first try to narrow down the key that is bloating. Start at
HKEY_LOCAL_MACHINE. Also look for extra control sets that get created on a
failed boot - you should normally see two plus a link to one of them
(CurrentControlSet). You will also see MountedDevices - make sure it's not
too big, normally only about a screenful but will vary depending on how many
extra disks devices, like USB keys, you have. dureg is one tool that can
help but I just ran it on XP and the numbers aren't making sense - I have
used it on Win2K successfully though.

http://www.microsoft.com/downloads/...e1-a45e-4445-90a7-6e0342e5dc03&DisplayLang=en

(HKLM\System\Enum\USB might be one place to look)

Another approach is to use regmon from sysinternals and try to catch who is
writing to this hive if you notice it is increasing. You should filter out
all the other activity and only select Log Writes. A normal running system
should show no (or few) updates to the hive.


Pete said:
Jeff & Dave,
Thanks for you input with the systemced issue that I am having.

Jeff here are details on machines that were getting systemced issue.

All of them dell workstation with win2k OS with sp4. All of them are
getting
their ip from DHCP, couple of them might have reservation from DHCP.

These machines have only 1 harddrive with no external raid controller.
Group Policy, we are not pushing down any compliticated settings besides
normal such as Password & audit policies.

I read up on the scrubber tool & it would not apply in my situation
because
all of these machines are running win2k professional with built in
harddrive.

Thanks again,
Pete

Jeff Goldner said:
Can you describe a little more about these systems? We have seen this
problem from multiple sources: DHCP, DNS, DFS (really too many shares in
general), systems with lots of printers (I believe this was fixed before
SP4), Storage (especially systems with very active PnP - snapshotting
would
be an example, or even flaky interconnects), USB (again, flaky
connections
can cause lots of device objects to be created but it would take a lot).

http://support.microsoft.com/kb/277222/en-us describes the storage issue
and
how to recover
http://support.microsoft.com/kb/837330/en-us discusses an issue related
to
group policy
http://support.microsoft.com/kb/269075/ discusses an issue with an older
Promise ATA controller

The scrubber tool is discussed in 277222 - this only targets disk storage
related "stale" registry entries. If you see the backing store (system
file)
go above 10MB, you are heading for trouble. In might even be too late
since
the current control set will replicate to Last Known Good after the next
boot. There are resource kit tools to check the size of various keys -
this
can be helpful in locating the bloat.

This problem should not be related to Office or other application
software
since they use the software hive, not the system hive. That's not subject
to
the 16MB maximum.

Dave Patrick said:
No, none that I know of. Windows 2000 and SP4 have been out long enough
now
that something like that would have long-ago been discovered.

Something to try. (of course you'll need to catch it before it blows up
again) but;

Programs|Accessories|System Tools|Backup, then choose ERD, then if you
check
the box for "Also backup....", then the reg will also be backed up to
%systemroot%\repair\RegBack
leaving the
%systemroot%\repair\
directory files intact as original installation. This should compact
the
hive during the backup.

Then compare the size of the system hive found in;
%systemroot%\repair\RegBack
with that of the in use hive found in;
%systemroot%\system32\config

If you see an improvement in size then you can replace registry hives
from
within the recovery console by copying the files from
%systemroot%\repair\regback
to
%systemroot%\system32\config
(the system hive is all that should be necessary at this point)

This might indicate some process using the registry as a temporary data
store.

To start the Recovery Console, start the computer from the Windows 2000
Setup CD or the Windows 2000 Setup floppy disks. If you do not have
Setup
floppy disks and your computer cannot start from the Windows 2000 Setup
CD,
use another Windows 2000-based computer to create the Setup floppy
disks.
At
the "Welcome to Setup" screen. Press F10 or R to repair a Windows 2000
installation, and then press C to use the Recovery Console. The
Recovery
Console then prompts you for the administrator password. If you do not
have
the correct password, Recovery Console does not allow access to the
computer. If an incorrect password is entered three times, the Recovery
Console quits and restarts the computer. Note If the registry is
corrupted
or missing or no valid installations are found, the Recovery Console
starts
in the root of the startup volume without requiring a password. You
cannot
access any folders, but you can carry out commands such as chkdsk,
fixboot,
and fixmbr for limited disk repairs. Once the password has been
validated,
you have full access to the Recovery Console, but limited access to the
hard
disk. You can only access the following folders on your computer: drive
root, %systemroot% or %windir%

--

Regards,

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

:
| Dave,
| We did start using regmon from sysinternal. I thought you might have
a
idea
| on certain programs (ex: office with certain sp level) that had known
issues.
|
| Thanks again for your response....
Click to expand...
Click to expand...
Click to expand...
 
Back
Top