Talk:Windows Registry

Notation

I've seen registry values referenced in the form (key path)|(value name). Is this use of "|" widely understood? --203.206.183.160 04:17, 14 July 2006 (UTC)

As far as I know the only limitation on value names is that they can not start with a backslash. Key names, I believe, can contain any character but backslash anywhere in them and must be at least one character long. So a pipe character could (I believe) be used at the start of a value name, the middle of a value name, the end of a key name, etc, etc. I don't think that the notation that you describe would work for all registry paths. You can find some information *in MSDN and there's a grammar that may or may not be correct at the end of *this thread.

MSDN says that a value name cannot start with a back-slash, but it actually can. I have found examples of it in the registry and win32 doesn't care if you use a leading forward slash in a value name. --24.67.212.211 01:21, 20 March 2007 (UTC)

Anyone knows anything about key classes?

I examined the Win32 API, and I found out that every registry key (the thingies resembling directories) has a "class" property that can be read by RegQueryInfoKey function for example. I googled a lot, but I could not find anything that describes what the hell is this.

If somebody knows of a page that describes it, could she post a link here? I could then add this info to the article and reference the link. Thanks.

Wigy 15:39, 6 December 2005 (UTC)

Here's a link to someone else asking the same question. [1]. The consensus among the replies seems to be that it's completely unused at the present time. The documentation quoted says that there are no such classes defined, so there isn't much point in adding any info. Every single registry key in the world has a null string for this property, and no program accesses it (not even regedit!). I think we can safely say it had an intended use at one point in the distant past, made it to the API, and was then abandoned completely.

Me 14:55, 10 June 2006 (-8)

The class attribute is used in odd places. How it is used I don't know. Here's this: [2]. Good luck.

Registry Keys?

I've created a section with a list of a few useful keys in it. This might or might not belong here; I hope others will add to it, at which point it might become a useful page in itself. JulesH 00:18, 16 July 2005 (UTC)

I know plenty of useful registry keys (and a few not so useful ones) but I'm pretty sure they don't belong to a Wikipedia article; listing "useful" keys in a how-to way is not very encyclopedic. They could make for an interesting Wikibooks module, though. JRM · Talk 18:22, 19 July 2005 (UTC)

JRM please don't start the whole Deletionist vs Inclusionist thing again.

JulesH I think your idea is wonderful, this is after all a computing encyclopedia as well as a more traditional history and philosophy encyclopedia (if you don't believe me look for yourself - computing far outways many more traditional (boring?) encyclopedia topics.

The mission of this site is to have "free distribution, free editing and wide range of topics"

"Wikipedia's goal is to create a free, reliable encyclopedia—indeed, the largest encyclopedia in history, in terms of both breadth and depth."

Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing. --Jimmy Wales, Wikipedia founder

That "sum of all human knowledge" includes the Windows registry (even if everyone in the world should use GNU/Linux ;)

Zeth 19:32, 27 July 2005 (UTC) Zeth

"JRM please don't start the whole Deletionist vs Inclusionist thing again." Uhm, again? And how is that even relevant? I'm not talking about deleting the article. I'm not even talking about deleting the information! What I'm saying is:

• What is or is not a "useful" registry key is completely subjective. How is an encyclopedia supposed to decide on this? How's that for the neutral point of view and original research?
• Wikibooks is perfect for this sort of endeavour. Game strategy guides, cookbooks and yes, registry how-tos all find their place there. It was created for this sort of thing.
• Jimbo's quote could be taken to mean "Wikipedia should include anything anyone could ever write down". But Jimbo didn't mean that. His quote shouldn't be taken literally, or there would be no guidelines at all as to what Wikipedia does and doesn't include. There are, however, things that Wikipedia is not.

Incidentally, please don't split up discussion in a "yes" and "no" side. This is highly unproductive because it emphasizes difference and disagreement, rather than focusing on reaching consensus. JRM · Talk 00:48, 31 July 2005 (UTC)

Registry keys

I actually think that a seperate article could be created that deals with a lot of Windows registry keys. Especially in HKEY_CLASSES_ROOT. That's just my $0.02. - Ta bu shi da yu 07:41, 5 October 2005 (UTC)

== Deleted external link to: "Inside the Registry (article by Mark Russinovich of sysinternals.com)" because it requires subscription to see the artitcle. 192.171.10.24 21:46, 5 January 2006 (UTC)

Registry edit blocking

Iv been using spybot to block most application from editing(it usually asks when i install things) the registry and i was wonder what the effect would be? I have not noticed any changes. Is this a safe thing to do and should this be in some way included in the article.--Whywhywhy 12:26, 28 January 2006 (UTC)

It just blocks known keys used by spyware and adware, such as the Internet Explorer start page. It does not block registry editing in general. That would not be very productive ;)... Lofote 12:30, 26 June 2006 (UTC)

Added Sections for HKEYs

• More modular and easier to reference to a subsection of this topic from other articles.
• IF one section expands too far such as HKLM this could be seperated into its own topic easily. SNIa 17:42, 18 February 2006 (UTC)
• Cross references are made to each HKEY section from the Windows NT Startup Process
• HKCR
• HKCU
• HKLM
• HKU
• HKCC

Corrected HKCR Entry

HKCR is a compilation of HKCU\Software\Classes and HKLM\Software\Classes not only on XP but also 2000 and 2003 server. Important detail for anyone trying to write something into this key that needs to be accessible to another user!

Section: Problems with Windows 9x OS

--207.81.225.190 23:52, 10 June 2006 (UTC)

On Windows 9x computers, an older installation can have a very large registry that slows down the computer's startup and can make the computer unstable. This has led to frequent criticisms that the registry leads to instability. However, these problems occur far less often on the Windows NT family of systems, including Windows XP.

I don't see that the above is all that valid.

The speed of the registry has improved from 9x to XP. 9x uses LI structures to index its keys. These structures are just a list of file offsets within a registry hive. NT/2k/XP use LF and LH structures, which contain hashes of the subkey names. In order to look up a record under 9x one has to read subkeys from disk, a slow process. Under NT/2k/XP one can first check the hash in the index and, if it matches, then look up the subkey and check for a match. The LF/LH method is a lot faster than LI. Also, NT disk access is far more effecient than that of 9x.

Though the speed of the registry has unquestionably increased I would argue that registry-related stability issues have actually increased in number and severity in NT/2k/XP, especially XP. Aside from the LF/LH (and RI, different story) registry keys very little else has changed in the binary structure of the hive database.

NT/2k/XP certainly have a more stable kernel. That combined with NTFS would, I would think, lead to less hive corruption resulting from filesystem corruption. However I have only rarely run into binary registry corruption that has been so severe as to be difficult to recover from. Most of the registry-related stability problems that I have experienced have been a result of the data stored in the registry and not the registry itself.

The complexity and importance of the data stored in the registry has grown massively since 9x days. I find that issues with bad software/bad drivers or improperly loaded software/drivers is far worse in more modern Windows OSes than old ones. Note that I am not talking about overall system stability, just stability that pertains to settings in the registry.

Anyhow, NT kernel == more stable; NT filesystem == more stable, faster; NT registry speed == faster; NT stability specifically from registry issues == I would say worse, other would say otherwise. I would say that the grand sum total of the "Problems with Windows 9x OS" section along with what I have written ammounts to about squat. I would have just removed the section, but I don't like to just delete things out of the blue.

Lofote 12:34, 26 June 2006 (UTC) Having to start a lot of programs at startup slows down the computer. This is correct for all Windows systems, as it would be on Linux and anything else - easy formula: Much too load = slower too load. This has nothing to do with the registry, except that the apps to autostart are enumerated in the registry. But it would not be different if that information came from somewhere else, in contrary it would be even slower, because the reading of this information from an indexed registry is faster. Lofote 12:34, 26 June 2006 (UTC)

207.81.225.190 19:58, 14 August 2006 (UTC) I never said anything about system startup speed relating to registry implemenation. I was commenting on changes in system stability between 9x and NT due to their registry use. I probably shouldn't have mentioned speed at all as it was a bit of a red herring. The hashed structures in newer registry implementations do improve access speed to keys with lots of subkeys. In cases where one has to repeatedly traverse through keys with lots and lots of subkeys the speed issues do become significant.

Win32 API?

This doesn't make sense: Both are "written for the Win32 API" so where is the difference?

• REGEDIT.EXE was written for the Win32 API and supported right-clicking of entries in a tree view to adjust properties and other settings.
• REGEDT32.EXE was written for the Win32 API and required all actions to be performed from the top menu bar.

— Preceding unsigned comment added by Lofote (talk • contribs) 26 June 2006

That was a change introduced in this edit by User:Yuhong last year. I don't know enough about Windows programming to comment further. Anyone? —mjb 23:21, 25 July 2006 (UTC)

Hello, I've found the Microsoft Support page that is relevant to your questions and doubts; sorry I can't check and edit the article, I'm pretty busy with Pink Floyd related articles for now.Cheers.--Doktor Who 21:58, 30 July 2006 (UTC)

The article seems to have it right now. In pre-XP Regedit.exe is easy to use, but has some ugly shortcomings (.reg files don't store classes, no way to modify access control). Regedt32.exe is a pain to use but is reasinably complete. Both of these programs use the win32 registry API. I guess they've added the missing features to regedit and dumpted regedt32 in XP. I don't have access to an XP box right now so I can't confirm.

On my machine when i run Regedt32.exe, it closes and brings up regedit.exe i can see in the process list of task manager, is supposed to be normal, i do have full admin rights. —The preceding unsigned comment was added by 71.131.134.213 (talk) 05:38, 19 February 2007 (UTC).

"^ Microsoft's Windows 2000 Security Hardening Guide version 1.3, published May 15, 2003, says "It is highly recommended to use regedt32.exe (a.k.a. the Windows NT registry editor) and not regedit.exe (a.k.a. the Windows 95 registry editor) to modify registry settings. Both editors ship with Windows 2000 and regedit.exe is generally perceived as easier to use. However, regedit.exe does not support all the registry data types and will convert certain types it does not understand. Certain values will not be read properly if they are converted and this can cause serious problems with the system, including failure to boot."

".. In Windows XP and Windows Server 2003, Regedt32.exe is a small program that just runs Regedit.exe."

So um i dont understand, run regedt32 instead of regedit so regedt32 can start regedit?? sounds like a big contradicting to me. —The preceding unsigned comment was added by 71.131.134.213 (talk) 05:46, 19 February 2007 (UTC).

Prior to Windows XP regedit.exe was easy to use, but broken/incomplete. regedt32.exe, on the other hand, was more complete but had a horrible interface. Microsoft fixed regedit.exe and dumped regedt32.exe for XP. In XP (and Vista, I assume) regedt32.exe has been replaced with a dummy program that runs regedit.exe.--24.67.212.211 21:30, 16 March 2007 (UTC)

Policy files

Since Windows 95, administrators can use a special file to be merged into the registry, a policy file. The policy file allows administrators to enforce registry settings such as preventing users from changing the background picture of the desktop. The default extension for the policy file is .pol. The policy file filters the settings it enforces on a per user basis and per user group basis. To do that the policy file merges into the registry, preventing users from circumventing it by simply changing back the settings. The policy file is usually distributed through a LAN, but can be placed on the local computer.

Actually this is not correct. Policy files do not prevent changing settings back at all within the current session (they will be reoverwritten at next logon/startup. On Win9x based system the only way to ensure those settings are not set back is to ensure that absolutely no way exists to open regedit, apply a reg file or any other program that can chance it back. On locked down Win9x systems this usually means disabling 99% of the Explorer interface incl. open/save dialogs of most applications, otherwise there will be a way to set it back. On Windows NT-based systems this is a bit different, because the HKCU\Policies keys are non-writable for users. Policies enable administrators to write information there, the users (and even a triggered login script by the admin) are not able to change values there. However any policy that is not inside the protected HKCU\Policies key (or HKLM of course) is open for editing by the user. That is why there are two locations for many options: one inside normal HKCU keys and one for the Policies. The second one is by default unset, as soon as there is a value there, the first one is not used at all. So HKCU\Policies configuration gets a higher priority if existing by Explorer and most of the Windows shell programs. (Such a behaviour must be explicitely supported by the application however). In similar cases -when user-dependand config is not required- both a HKCU and a HKLM configuration key exists, working the same way. Lofote 10:19, 30 August 2006 (UTC)

Can one select multiple keys and change permissions to all of them at once ?

Useful, as some registry cleaners report bad enties that can't be deleted due to permission settings. Of course these nice programs report that they deleted those entries, just to come up with them in the next scan. There are progs (registry finder for - random - instance) that allow selecting multiple keys, but only to "delete" them (with or without quotes, depending on permission settings), not to edit their permissions. Probably one could come up with a piece of code that could do that - I am not into progamming at all. The Ubik 17:44, 22 September 2006 (UTC)

The answer is probably "Yes, if you're prepared to go through a bit of effort."

Since you'll most likely need a completely custom solution, you'll probably have to implement it yourself (doing a websearch aforehand wouldn't hurt though). Learn the basics of a programming language (must be able to make Win32 API calls) and download the Platform SDK and prepare for debugging in the wee hours of the morning...

So's to get you started "Registry Key Security and Access Rights" in the Platform SDK seems an article that may apply. You'll probably need the function "RegSetKeySecurity". Hope this helps... Shinobu 01:18, 23 September 2006 (UTC)

Take a look at subinacl.exe (you can download it from microsoft). It provides a command line interface to windows file and registry (and I think some other things) permissions. The interface is horrible, but once you've figured it out once then you can make a batch file to set permissions on whatever part of the registry/filesystem you like.--24.67.212.211 21:33, 16 March 2007 (UTC)

A book on registy hacks

What about writing a book on registry hacks. Just the hacks bothing about the history etc whatsoever. Anyone interested? --seXie^♭♭_c 08:20, 17 November 2006 (UTC)

HKEY_DYN_DATA

Where's this section? At least we must mention it. MrFirewall 13:50, 16 January 2007 (UTC)

Improving the description of what's in HKCU

HKEY_USERS contains subkeys corresponding to the HKEY_CURRENT_USER keys for each user registered on the machine

Perhaps "registered on the machine" could be changed to something more specific. According to this Microsoft KB article HKEY_USERS "Contains all the actively loaded user profiles on the computer". That's clearer -- "registered" could be misunderstood as defined rather than defined and active. —The preceding unsigned comment was added by 59.144.1.19 (talk) 06:31, 29 January 2007 (UTC).

Vista's Registry

This article needs to be updated to include the location of the Registry on Windows Vista. Cobalt2020 22:07, 7 February 2007 (UTC)

Command line Editing of Registry

Origanal text..

Command line editing

On NT-based ** systems the registry can be manipulated from the command line with the reg.exe utility. It is included in Windows XP and can be downloaded separately for previous versions. ---

Revised to include windows 98 as a system type

74.116.173.139 18:11, 27 February 2007 (UTC)

Restored links

I undid an edit that removed a number of extremely useful links. If the "Low-level Registry and SAM Information" link isn't a good reference source then I don't know what is. --24.67.212.211 19:47, 14 March 2007 (UTC)

Capitalization of Registry

Does anyone know why this article is uncapitalized, as in "Windows registry"? Windows Registry, as in "the" Windows Registry is a proper noun in every sense of the word.

As similar examples, compare "Microsoft Word", "Internet Explorer", and "Windows Update". These are all proper nouns, as these describe a specific product, not a typical word, explorer, or update. Similarly, Do Not Call Registry describes a specific registry, as does Massachusetts Registry of Motor Vehicles. As a counter-example, domain name registry generically refers to any organization that maintains such a registry. Reswobslc 02:31, 30 March 2007 (UTC)

fixed Lyml 19:46, 25 April 2007 (UTC)

{098f2470-bae0-11cd-b579-08002b30bfeb}

Dirty old clsid's. Now, it is possible that the registry is compressed in some way that these clsid's aren't wasting ridiculous amounts of space, but I don't believe that's the case.

CLSID's are stored as strings, there are six characters ({,-,-,-,-,}) that are common to all of them, and the remaining characters are always one of (0-9) or (a-f), so it works out about 5x the size it needs to be, resulting in an inefficient database etc..

I'm not saying CLSID's are a bad idea, just that they're stored inefficiently, and that I should never have to look at them.

If someone wants to incorporate that rant... Open to feedback T boyd 22:20, 27 April 2007 (UTC)

Registry Structure

...typically look up their settings by first checking for them in "HKEY_CURRENT_USER\Software\Vendor's name\Application's name\Version\Setting name", and if the setting is not found looking instead in the same location under the HKEY_LOCAL_MACHINE key. When writing settings back, the reverse approach is used — HKEY_LOCAL_MACHINE is written first, but if that cannot be written to (which is usually the case if the logged in user is not an administrator), the setting is stored in HKEY_CURRENT_USER instead.

Is there a citation for this comment? I'm not sure this is entirely accurate. HKLM is per-machine settings and HKCU is per-user settings. An application may, indeed, write settings as described above, but that's not fitting with modern security practices, especially Microsoft Best Practices. Attempting to write a system-wide setting (HKLM) first just because you can (instead of writing to the admin's HKCU hive) seems like bad coding and not how the registry was intended to be used. In the above scenario, HKLM should be the "default" setting and HKCU should contain user preferences that differentiate. In this case, HKCU would be written to no matter what access you have, not HKLM. HKLM would only be written if the default values were to change. But I don't find this scenario to be "typical" to me at all. In my experience, HKLM is only written to when a setting is system-oriented (OS related, installation related, things the user shouldn't worry about) OR if the program mistakenly believes all users have HKLM write access (many legacy apps do). Whereas HKCU should be used for all user preferences and settings -- things you don't share with other users typically. I rarely see a double-read, double-write scenario as described above. Additionally, if you look at GPOs, for example, even with settings that contain a separate user and machine setting, the machine setting overrides the user setting, which is opposite of what the above statement says. Stating this is typical use of the registry seems suspect to me. Or at the very least, an administrative headache. :-) Thx1200 14:18, 8 May 2007 (UTC)