COMMAND
kernel
SYSTEMS AFFECTED
WinNT
PROBLEM
Michael Clarke found following. He discovered a bug with NT
v4.0-SP6a registry size growth and overwriting of user profiles.
This bug was exposed when the SMS v2.0-SP2 client runs into a
condition where it continually creates new registry keys and
values filling the system registry with thousands of crap entries
- thus slowly (over a period of weeks) increasing the size of the
registry until one day the user logons on...
When the system registry becomes bigger that the "Maximum Registry
Size" set in Control Panel=>Virtual Memory and a user logons on NT
will "backup" the users profile by changing the directory from
"winnt\profiles\username" to "winnt\profiles\username.bak" and
then creating an new "winnt\profiles\username" from the default
user profile - presumably to reduce the size of the registry and
allow the logon to complete - which does not work when it's the
system registry that is too big.
Here's the bug: When the user logons on the first time after the
registry size is exceeded they get a default profile and their
original profile is renamed username.bak. Soooo, the user sees
an error message and promptly logs off and then on again. The
seconded time the user logs on after the registry size is
exceeded NT OVERWRITES the username.bak with the first default
profile created thus wiping out the users original NT profile
directory and all it contained.
See Q189119 for Microsoft's description of what happens when the
Registry Size Limit (RSL) is exceeded. Note it does not mention
this profile username.bak overwrite bug.
This bug seems to be a SEB since Michael could write a small "time
bomb" program that slowly or quickly consumes the registry and
thus wiping out another users profile.
Additional notes:
1) Microsoft support says that they will amend Q189119 to
include a description of this additional bug.
2) Microsoft SMS support says that they are working on a Q
article and fix for the runaway SMS v2.0-SP1 client agent
that fills the registry with crap. This will be a SMS
v2.0-SP2 post hot fix since SMS SP is now in beta.
3) Various registry ACL lockdown scenarios were not tested to
"fix" or workaround this problem.
4) Michael has not recreated this problem with something other
than the runaway SMS v2.0-SP1 client.
5) Michael has not found a way to reduce the size of the
registry (winnt\config\ SOFTWARE) file after this problem
occurs. We have one server with a 71 Mb registry and many
workstations with 20Mb+ registries because of this problem.
SOLUTION
Curtis Anderson posted following. If you have the NT Resource
Kit's MV.EXE utility you can use this batch routine.
@echo off
echo Updating compressed Registry files...
rdisk /s-
echo Expanding compressed Registry files to usable format...
EXPAND %systemroot%\REPAIR\DEFAULT._ %temp%\DEFAULT
EXPAND %systemroot%\REPAIR\SAM._ %temp%\SAM
EXPAND %systemroot%\REPAIR\SECURITY._ %temp%\SECURITY
EXPAND %systemroot%\REPAIR\SOFTWARE._ %temp%\SOFTWARE
EXPAND %systemroot%\REPAIR\SYSTEM._ %temp%\SYSTEM
Echo Moving new registry files to CONFIG directory....
MV /X /D %temp%\DEFAULT %systemroot%\SYSTEM32\CONFIG\DEFAULT
MV /X /D %temp%\SAM %systemroot%\SYSTEM32\CONFIG\SAM
MV /X /D %temp%\SECURITY %systemroot%\SYSTEM32\CONFIG\SECURITY
MV /X /D %temp%\SOFTWARE %systemroot%\SYSTEM32\CONFIG\SOFTWARE
MV /X /D %temp%\SYSTEM %systemroot%\SYSTEM32\CONFIG\SYSTEM
Echo.
Echo.
Echo REBOOT to move and activate the new registry files
echo.
echo.
pause
This will effectively remove any "white space" in the registry
files as the backup with RDISK does not save empty space. Speeds
up your system nicely too, especially after cranking a registry
down from 38 MB to 12 (personal experience).