Corrupted registry key -- can't delete

Stan Brown · Jul 31, 2006

At work I have a customer who has a corrupted registry key.

He can't delete it: after "are you sure?" and "Yes", he gets "Error
deleting key - cannot delete [keyname]".

He can't set permissions: when right-clicking and selecting
"Permissions" he gets "You do not have permission to view the current
permission settings for [keyname], but you can make permission
changes." (!) Clicking OK, he gets the permissions window but the top
half (users and groups) is empty. When he clicks "Add" and adds his
own user ID, copied from a different key, and clicks OK he gets
"unable to modify permissions". (This last message might be
paraphrased; the others are verbatim.) All the other subkeys have
normal-looking permission lists, as does the parent.

The key is one of a group created by software under HKCU, say
HKCU\AMD\4C00
for brevity. AMD and 4C00 are abbreviations, for convenience.

I had him export HKCU\AMD and verified that 4C00 wasn't exported but
the other subkeys were. Then I sent him a .REG file that deletes the
parent, HKCU\AMD. (Our software will recreate the subkeys at install
time.) When he ran the .REG file it deleted all the other subkeys,
not the problem one.

So how can he delete this problem key?

Wesley Vogel · Aug 1, 2006

Error deleting key - cannot delete usually means a Permissions problem.

Try this...
Reset the registry permissions
As soon as you have found the registry subkey that has the incorrect
permissions, update the permissions for that subkey.

To update the permissions of the registry subkey, follow these steps:
a. Click Start, click Run, type regedit and then click OK to start
Registry Editor.
b. Locate and right-click the registry subkey:
and then click Permissions.
c. Under Group or user names, click Administrators.
d. Under Permissions for Administrators, make sure that the Allow check box
for the following entries is selected:
* Full Control
* Read
e. Click Apply and then click OK.
f. On the File menu, click Exit to quit Registry Editor.

Open the Registry Editor again and see if you can delete the key now.

If not, try this...
Start | Run | Type: regedit | OK |
Navigate to >>>
the said key
Right click the key in the left hand pane | Permissions... | Advanced
button | Owner tab | click the new owner and then click OK.

[[You can take ownership of a registry key if you are logged on as an
administrator or if you have been specifically assigned the permission to
take ownership of the registry key by the current owner. ]]

See permissions, registry in Registry Editor HELP.

To assign permissions to a registry key
http://www.microsoft.com/resources/...xp/all/proddocs/en-us/regedit_permit_key.mspx

To assign special access to a registry key
http://www.microsoft.com/resources/...ll/proddocs/en-us/regedit_assign_specacc.mspx

To grant Full Control of a registry key
http://www.microsoft.com/resources/.../xp/all/proddocs/en-us/regedit_yield_own.mspx

To add users or groups to the audit list
http://www.microsoft.com/resources/...proddocs/en-us/regedit_audit_key_adduser.mspx

To add users or groups to the Permissions list
http://www.microsoft.com/resources/...roddocs/en-us/regedit_permit_key_adduser.mspx

To remove a user or group from the Permissions list
http://www.microsoft.com/resources/...proddocs/en-us/regedit_permit_key_remove.mspx

To take ownership of a registry key
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/regedit_take_own.mspx

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

Stan Brown said:
At work I have a customer who has a corrupted registry key.

He can't delete it: after "are you sure?" and "Yes", he gets "Error
deleting key - cannot delete [keyname]".

He can't set permissions: when right-clicking and selecting
"Permissions" he gets "You do not have permission to view the current
permission settings for [keyname], but you can make permission
changes." (!) Clicking OK, he gets the permissions window but the top
half (users and groups) is empty. When he clicks "Add" and adds his
own user ID, copied from a different key, and clicks OK he gets
"unable to modify permissions". (This last message might be
paraphrased; the others are verbatim.) All the other subkeys have
normal-looking permission lists, as does the parent.

The key is one of a group created by software under HKCU, say
HKCU\AMD\4C00
for brevity. AMD and 4C00 are abbreviations, for convenience.

I had him export HKCU\AMD and verified that 4C00 wasn't exported but
the other subkeys were. Then I sent him a .REG file that deletes the
parent, HKCU\AMD. (Our software will recreate the subkeys at install
time.) When he ran the .REG file it deleted all the other subkeys,
not the problem one.

So how can he delete this problem key?

Doug Knox MS-MVP · Aug 1, 2006

It is possible to create a registry key with permissions so tight that it cannot be deleted by any normal means.

Assuming that the key in question is actually in HKCU, have them log on to a different account, the built-in Administrator account is preferable. Then see www.dougknox.com, Win XP Tips, Advanced Registry Editing for a method of accessing the original user's NTUSER.DAT file.

If that doesn't work, you can look into utilities such as Bart's PE, which creates a bootable CD that can run Windows applications such as Regedit. Along with the tip above, this will allow easy editing of the Registry key in question. Similar to Bart's PE is UBCD (Universal Boot CD)

http://www.nu2.nu/pebuilder/

http://www.ultimatebootcd.com/

Stan Brown · Aug 1, 2006

Mon, 31 Jul 2006 17:09:08 -0600 from Wesley Vogel <123WVogel955
@comcast.net>:

To update the permissions of the registry subkey, follow these steps:
a. Click Start, click Run, type regedit and then click OK to start
Registry Editor.
b. Locate and right-click the registry subkey:
and then click Permissions.
c. Under Group or user names, click Administrators.

Wesley, thanks for responding. But perhaps you missed where I said
that there were no users or groups listed in the Permissions box for
this subkey -- that part of the dialog box as blank.

Stan Brown · Aug 1, 2006

Thanks Doug. I will pass this along, with credit to you!

Mon, 31 Jul 2006 19:14:49 -0400 from Doug Knox MS-MVP

Stan Brown · Aug 1, 2006

Mon, 31 Jul 2006 19:14:49 -0400 from Doug Knox MS-MVP

It is possible to create a registry key with permissions so tight
that it cannot be deleted by any normal means.

Assuming that the key in question is actually in HKCU, have them
log on to a different account, the built-in Administrator account
is preferable. Then see www.dougknox.com, Win XP Tips, Advanced
Registry Editing for a method of accessing the original user's
NTUSER.DAT file.

If that doesn't work, you can look into utilities such as Bart's
PE, which creates a bootable CD that can run Windows applications
such as Regedit. Along with the tip above, this will allow easy
editing of the Registry key in question. Similar to Bart's PE is
UBCD (Universal Boot CD)

http://www.nu2.nu/pebuilder/

http://www.ultimatebootcd.com/

Whoops! I realize I misspoke -- misread my notes when I was typing my
article. The key in question is a sub-subkey under HKCR
(HKEY_CLASSES_ROOT), not HKCU (HKEY_CURRENT_USER). Does that make a
difference? I'm guessing that HKCR is not in the user hive but in the
system hive.

Could it be edited in Safe Mode, perhaps?

Sorry for the misleading original article!

Wesley Vogel · Aug 1, 2006

Stan, I also missed what #$%#$% key you're referring to.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

Wesley Vogel · Aug 1, 2006

Stan,

The DEFAULT access permissions assigned for HKEY_CLASSES_ROOT are:
Admin-Full Control
Creator Owner-Full Control
Everyone-Special (Query, Set, Create, Enumerate, Notify, Delete, Read)
System-Full Control

The next two sentences should be of some interest.

To change the settings for the interactive user, changes should be made
under HKEY_CURRENT_USER\Software\Classes rather than HKEY_CLASSES_ROOT.

To change the default settings, changes should be made under
HKEY_LOCAL_MACHINE\Software\Classes.

Here's some info on HKEY_CLASSES_ROOT from various sources.

HKEY_CLASSES_ROOT is actually a pointer into the HKEY_LOCAL_MACHINE
subtree-specifically, HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Changes made in
HKEY_CLASSES_ROOT are immediately reflected in HKEY_LOCAL_MACHINE, since
they occupy the same space.

HKEY_CLASSES_ROOT is a subtree that is an alias of another key within HKLM -
specifically HKLM\Software\Classes. Specifically, HKCR is a merging of both
HKLM\Software\Classes and HKCU\Software\Classes.

HKEY_CLASSES_ROOT
Contains information used by various OLE technologies and file-class
association data. A particular key or value exists in HKEY_CLASSES_ROOT if a
corresponding key or value exists in either
HKEY_LOCAL_MACHINE\SOFTWARE\Classes or HKEY_CURRENT_USER\SOFTWARE\Classes.
If a key or value exists in both places, the HKEY_CURRENT_USER version is
the one that appears in HKEY_CLASSES_ROOT.

HKEY_CLASSES_ROOT
Is a subkey of HKEY_LOCAL_MACHINE\Software. The information stored here
ensures that the correct program opens when you open a file by using Windows
Explorer. This key is sometimes abbreviated as "HKCR." Starting with Windows
2000, this information is stored under both the HKEY_LOCAL_MACHINE and
HKEY_CURRENT_USER keys. The HKEY_LOCAL_MACHINE\Software\Classes key contains
default settings that can apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings which override the
default settings and apply only to the interactive user. The
HKEY_CLASSES_ROOT key provides a view of the registry that merges the
information from these two sources. HKEY_CLASSES_ROOT also provides this
merged view for programs designed for previous versions of Windows. To
change the settings for the interactive user, changes should be made under
HKEY_CURRENT_USER\Software\Classes rather than HKEY_CLASSES_ROOT. To change
the default settings, changes should be made under
HKEY_LOCAL_MACHINE\Software\Classes. If you write keys to a key under
HKEY_CLASSES_ROOT, the system stores the information under
HKEY_LOCAL_MACHINE\Software\Classes. If you write values to a key under
HKEY_CLASSES_ROOT, and the key already exists under
HKEY_CURRENT_USER\Software\Classes, the system will store the information
there instead of under HKEY_LOCAL_MACHINE\Software\Classes.

The HKEY_CLASSES_ROOT subtree contains two types of data:

1. Data that associates file types with programs. The file type subkeys in
HKEY_CLASSES_ROOT have the same name as the file name extension for the file
type, such as .exe. File type associations are stored in the registry, but
you should use Windows Explorer to change them. In Windows Explorer, from
the Tools menu, click Folder Options, and then click the File Types tab.

2. Configuration data for COM objects, Visual Basic programs, or other
automation. The configuration subkeys either use the program IDs (such as
for COM, VB, automation, and scripting) or parent keys for other classes of
information (such as for CLSID, Interface, TypeLib, AppId, and so on).

The content of HKEY_CLASSES_ROOT comes from two sources:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\SOFTWARE\Classes.
If a subkey or entry appears in either location, it also appears in
HKEY_CLASSES_ROOT. If the values of entries in the two Classes subkeys
conflict, only the value in HKEY_CURRENT_USER\SOFTWARE\Classes appears in
HKEY_CLASSES_ROOT.

Note
If an entry exists in both HKEY_LOCAL_MACHINE\SOFTWARE\Classes and
HKEY_CURRENT_USER\SOFTWARE\Classes, the value of the entry in
HKEY_CURRENT_USER\SOFTWARE\Classes takes precedence.

If you create a new key or subkey in HKEY_CLASSES_ROOT, it will also be
created in HKEY_LOCAL_MACHINE\SOFTWARE\Classes. If you create a new entry in
this same key or subkey, that entry will also appear in that key or subkey
in HKEY_LOCAL_MACHINE\SOFTWARE\Classes.

If you create a new entry in an existing subkey, where that entry will
appear depends on whether the subkey already exists in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes or HKEY_CURRENT_USER\SOFTWARE\Classes:

If the subkey exists in both HKEY_CURRENT_USER\SOFTWARE\Classes and
HKEY_LOCAL_MACHINE\SOFTWARE\Classes, the entry will appear in that subkey in
HKEY_CURRENT_USER\SOFTWARE\Classes only.

If the subkey already exists only in HKEY_CURRENT_USER\SOFTWARE\Classes, the
entry will appear in that subkey in HKEY_CURRENT_USER\SOFTWARE\Classes.

If the subkey already exists only in HKEY_LOCAL_MACHINE\SOFTWARE\Classes,
the entry will appear in that subkey in HKEY_LOCAL_MACHINE\SOFTWARE\Classes.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

Doug Knox MS-MVP · Aug 1, 2006

Hi Stan,

HKEY_CLASSES_ROOT is actually a link to HKEY_LOCAL_MACHINE\Software\Classes

In order to adjust the permissions on this file you need to do a couple of things.

1) Boot the computer with the XP CD and enter Recovery Console (Press R the first time a "repair" option is offered). You'll need the Administrator password. You can also boot into Recovery Console if you have it installed as a boot time option.

2) Once in Recovery Console enter the following commands:

CD \Windows\System32\Config
COPY SOFTWARE SOFTWARE_COPY

3) Reboot normally.

4) Load Regedit and highlight HKEY_LOCAL_MACHINE. Go to File, Load Hive and browse to Windows\System32\Config and choose SOFTWARE_COPY. You'll be asked for a name, I use LoadedHive

5) Expand LoadedHive and then Classes. Locate the registry entry/key you wish to change in this branch of the Registry.

6) When done, highlight LoadedHive and go to File, Unload Hive.

7) Reboot with the XP CD and enter Recovery Console again.

8) Enter the following commands

CD \Windows\System32\Config
REN SOFTWARE SOFTWARE_ORIG
REN SOFTWARE_COPY SOFTWARE

9) Reboot normally and the changes you made to the registry key/value should be in place.

Stan Brown · Aug 1, 2006

Doug, thanks so much! You da man!

Stan

Tue, 1 Aug 2006 16:40:18 -0400 from Doug Knox MS-MVP

Stan Brown · Aug 1, 2006

Hmm -- not sure whether this is a per-user or a default for all
users, but following your hints I will find out and advise my
customer accordingly. Thanks, ans also a big thanks to Doug for the
step-by-step procedure!

Tue, 1 Aug 2006 12:48:24 -0600 from Wesley Vogel <123WVogel955
@comcast.net>:

Doug Knox MS-MVP · Aug 2, 2006

Good luck! Bart's PE is also a good choice for this, as you can copy/manipulate the Software hive in a GUI type environment, without having to use Recovery Console.

Wesley Vogel · Aug 2, 2006

Well, Doug's da man! ;-)

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In