Talk:Windows Registry

Assessment of Microsoft registry usage

"The Windows registry was introduced to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs.[1] These files tended to be scattered all over the system, which made them difficult to track." The part "which made them difficult to track" seems to be a positiv assessment of the registry. But the port from one server to another of the registry is not easy and the current usage of the registry make it impossible to transfer between 32- and 64-bit windows version. Most ".ini" datas could be transfered without problem, if the "not operation system" related informations would be stored in ".ini" files.

It seems to better to delete the "which made them difficult to track" part or to write "which made them difficult to track, but easy to port between different servers.". —Preceding unsigned comment added by 195.145.45.7 (talk) 17:32, 8 November 2007 (UTC)

Agreed!--Bstard12 (talk) 18:31, 15 November 2011 (UTC)

Reorganize Advantages and Disadvantages section into a Rationale Section (up front) and a Criticisms section (at the end)

The "Advantages and Disadvantages" section was tagged with the suggestion that its content be integrated into the article. I've integrated the "Pro" points into a new Rationale section that explains the evolution of the registry from the simple .INI files that preceded it. Please contribute to this new section. One point from the Pros list didn't seem to fit:

• Portions of settings like any subset of an application configuration can be saved in a text-based .REG file, which can be edited with any text editor later. .REG files can easily be merged back into the registry both by unattended batch file or by the user just double-clicking on the file without harming any setting that is not explicitly stated in the .REG file. This is very useful for administrators and support personnel who want to pre-set or pre-configure only a few options like approving the EULA of a certain application.

I've integrated the "Cons" into a new Criticism section. Please contribute to this section, as the current material needs a broader, more coherent view. Ross Fraser (talk) 05:22, 19 June 2010 (UTC)

I've further reorganized the Criticism section, as one of the bullet points in the list was an agglomeration of three separate points. I've also removed the following unsourced statement:

While damaged configuration files can have the same result to other operating systems, the damage can be more easily repaired by booting to another operating system, and using a text editor.

Apart from being ungrammatical, it doesn't seem to make much sense. If you can edit a damaged computer's config files via booting from an external system, you should also be able to edit its registry using regedit. Ross Fraser (talk) 07:35, 27 December 2010 (UTC)

The Criticisms section is now the second one on the page. Shouldn't that be moved somewhere toward the end? Billyoneal (talk) 17:49, 18 February 2011 (UTC)

Registry in Windows 3.0

The registry actually appears with programs like "MS-Word for windows" 2.0. Regedit runs under Windows 3.0, and even the default setup for Windows 3.1 on its original release had registry entries fro WinWord 2.0. --Wendy.krieger (talk) 11:06, 29 January 2011 (UTC)

Yes, indeed - but what's your point? Socrates2008 (Talk) 11:32, 29 January 2011 (UTC)

Several points of criticism irrelevant/incorrect

I think the bullet under criticism

Because information required for loading device drivers is stored in the registry,[4] a damaged System registry may prevent a Windows system from booting successfully, since some device drivers won't be loaded, preventing the affected devices from working. Device drivers are stored in a key called HKLM\System\CurrentControlSet, which is a symbolic link that alternates between HKLM\System\CurrentControlSet001 and HKLM\System\CurrentControlSet002, thereby allowing the "last known configutation" boot option to provide a mechanism of reverting to the last configutation that successfully started the system.

needs to be removed. The issue here is that broken configuration will break any system. Just because that configuration happens to be in the Registry on Windows does not mean that the Registry is at fault. Thoughts? Billyoneal (talk) 17:48, 18 February 2011 (UTC)

Similar deal with

The parts of the registry may have to be kept in sync with the file system (e.g., deleting an application rather than uninstalling it, may leave associated configuration items such as COM registration entries in the registry if the application is legacy and does not leverage side-by-side registry-free configuration.[5])

This is again an issue with configuration in general, not with the registry. For example, if you nuke a PHP extension file, but don't nuke the link to that file in php.ini, PHP is going to complain (to say the least).

Thoughts? Billyoneal (talk) 17:59, 18 February 2011 (UTC)

Probably a bit of Microsoft bashing has been going on this section, along with some incomplete/inaccurate information mixed with some synthesis. Socrates2008 (Talk) 11:10, 19 February 2011 (UTC)

Can't agree with your analysis here. Just because these sort of problems don't always originate in the Registry doesn't mean that it shouldn't be noted that they can and do originate in the Registry sometimes. Whether or not you consider it a valid criticism, it's a criticism that many people have with the Registry or any centralized collection of dynamic links and settings independent of the applications themselves. We're not here to apologize for system design choices.

In either case, it's not appropriate to use a 'Dubious' tag, since the facts are not in doubt; you're just asserting that the fact does not need to be mentioned in the article, not that their assertion is untrue. In the meantime I've rewritten the section for clarity. — Chromancer ^talk/_cont 18:09, 24 April 2011 (UTC)

I still think that section needs work though. Even if one accepts the claims there at face value, they are not criticisms of the registry. They are criticisms of Windows, and perhaps they should be moved to Microsoft Windows. The Registry (as a system) does not know or care that Windows happens to stuff driver information in there. Billyoneal (talk) 06:19, 11 June 2011 (UTC)

There's a lot of Microsoft bashing in an article on the Windows Registry, because it is one of the worst features of Windows and is the cause of much criticism of Microsoft. It doesn't matter whether it's bashing. It only matters if it's true. It would be different if it were one of the good features of Windows. (BTW, as a Mac owner, I bash Apple all the time.) Bostoner (talk) 03:15, 2 August 2011 (UTC)

Was about to make a new section but saw this one... Why is this section called Criticism? It does not contain any criticism, and it's sources are two MS KB articles. The fact that messing with system properties can have harmful affects on the system is not a 'criticism', it's simply a fact. The section should be renamed, or integrated elsewhere. Criticism would require reliable sources to ... well...criticize the registry? The section is currently akin to an automobile article containing a Criticism section stating that the fuel port may accept fluids other than gasoline, which may lead to the engine not working. I have no issue with this fact being IN the article, it's true. It is not a "criticism" however on it's own. -- ferret (talk) 17:41, 16 May 2012 (UTC)

A lot of unsourced MS bashing was going on and has been deleted. I have deleted several "criticisms" after having tagged them as needing citations for longer periods. The current one is also tagged and has no proper in-context sourcing. So unless someone comes up with a good source for the claim - other than the obvious that changing system configuration may render the system unstable - the entire section is about to go. There may be valid criticism of the registry, but such criticism cannot be the opinions of WP editors - not matter how frustrated they may be with the registry. To qualify as criticism under this section it must be criticism and it must have been voiced by a reliable and verifiable source. I.e. merely stating that someone have experienced a problem which could have been caused by the registry is not criticism. Useerup (talk) 20:12, 16 May 2012 (UTC)

If you read the ref link, it says on that page:

"WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk."

Why have you put "citation needed" when 2 citations have been provided? If you want me to go and fetch a load of refs and add even more points of criticism then I will. I was going to forget about the criticisms, until Useerup has complained about that single criticism. TurboForce (talk) 22:56, 16 May 2012 (UTC)

The reference issue is irrelevant. The sentence as it stands, with the references it has, is a neutral fact. It is not a criticism, so should not be in a "Criticism" section. -- ferret (talk) 23:46, 16 May 2012 (UTC)

I've boldly moved the statement to a more appropriate place and removed the empty criticism section. -- ferret (talk) 23:49, 16 May 2012 (UTC)

Thanks! I agree with your edit.--Useerup (talk) 05:38, 17 May 2012 (UTC)

There should be a section, maybe call it "limitations", because the Windows Registry does have its downsides, especially if users edit the registry manually and make an incorrect change. The registry can be directly written to by other programs, the worse offenders being them "Registry Cleaner" programs, which don't actually improve performance, but can delete traces of a previously "un-installed" program. I have seen many installers falsely think the program is installed because its registry entries have been left behind from an attempted removal of the program. This can happen when the user tries to "fix" a broken program by un-installing it and re-installing it.

Why don't all operating systems go back to the "old" way of installing software, i.e. by copying files into a single directory per program? It would make life much easier. :) TurboForce (talk) 14:40, 17 May 2012 (UTC)

Your comment is actually more directed towards how modern installers/uninstallers work than the registry. There's nothing REQUIRING the installation of a program to use the registry. It's a choice that the industry follows. If you want to use the Control Panel's "remove program", then it must be in the registry, because that's how the program gets "registered".... But there's no requirement to use the registry or the control panel. -- ferret (talk) 16:49, 17 May 2012 (UTC)

I agree Ferret. Ever since the registry was introduced to replace INI files, I have never understood why program installers don't remove *all* of their junk from the registry and it's still a problem today as it was nearly two decades' ago. If all programs tomorrow did NOT use the registry and instead kept their own files, libraries and saved settings (e.g. a list of high scores for a game) in one directory, there would not be the tangle of mess which happens when registry entries get left behind. Removing them by hand is a tedious and risky task!

A problem I have seen many times is Windows thinking something exists when it does not, because there are abandoned registry entries left behind. I have seen Control Panel applets which don't work when double-clicked, 'ghost' entries in combo boxes e.g. default e-mail program showing e-mail programs which have been uninstalled etc.

Does anyone know why un-installers don't remove every trace of an installed program from the Windows Registry? I have been asking myself that question for years. TurboForce (talk) 22:16, 17 May 2012 (UTC)

They do, when correctly written. Unfortunately that's up to the individual software developers, and even they can't protect from the user simply deleting files at random, etc. -- ferret (talk) 01:32, 18 May 2012 (UTC)

@ferret Thank you for answering my question. :)

Maybe someone can invent a program – lets call it foo123 – which runs silently in the background and records every change made to the registry when the user installs a program and also records which folders get created, since many of these get created when installed, but not deleted when un-installing, especially inside "Program Files". When the program is un-installed, the leftovers which have not been removed by the uninstaller could be removed by foo123.

The registry does grow bigger and bigger the longer the computer is used and as one person says, it has become "a trash heap of miscellaneous junk settings for every rinky-dink application on the planet" read more. My experience is 100% frustration with the registry and the registry is a bad idea which has got out of control. The "Zero Install" method is the ultimate solution to messy installs, according to the page from this link.

'Whose' fault is it that the registry grows out of control with junk? The registry design itself? The program installers or both? Does this problem contribute to "Windows rot"? A bigger registry must take longer to load during Windows startup compared to the smaller registry that exists when Windows has just been cleanly installed? TurboForce (talk) 12:42, 18 May 2012 (UTC)

Moving Section 'Criticism' down a bit.

Well, the title speaks for itself. I think the section 'Criticism' should be moved downwards, because most articles from my experience, has the section 'Criticism' more to the bottom of the article, if at all. — Preceding unsigned comment added by Enoch exe inc (talk • contribs) 16:34, 17 June 2011 (UTC)

Criticism needs to be near the top, because it's so central to the Windows Registry. Bostoner (talk) 03:15, 2 August 2011 (UTC)

Inaccurate Information on OS X

OS X has 2 Library's. One is for user-specific configuration, and one is for system-wide configuration. An application can allow both types of configuration, with some configuration features applying to both and some to only one. There's another Library folder, but it's not really for configuration. Bostoner (talk) 03:15, 2 August 2011 (UTC)

Single point of failure

So I'm interested in this criticism, and why it's been re-added with a blog-type reference. From a purely engineering perspective, a single point of failure is something that does not have redundancy built in, so that failure of a single component would cause the whole system that it's a part of to fail. So back to the Registry: What does the editor mean by the Registry being a single point of failure? Does he mean that individual Windows applications stop working because the Registry "fails"? Or that the Windows operating system itself stops working? How exactly does the Registry itself fail - does the database backing it become physically corrupted (through disk error for example), or does it become logically corrupted internally? Who or what corrupts it, any why? Most home systems are not fault tolerant with components such as RAID5, multiple power supplies, fault tolerant memory, clustering etc, so surely any component of such a system, even a configuration file such as a "critical" .INI file on the filesystem, is a single point of failure? Or is this more of an "all the eggs are in one basket" argument as far as the centralisation of application settings is concerned, meaning that it's too easy for someone who does not know what they are doing to inadvertently modify unrelated settings that have unintended consequences? If that's the case, then it's got nothing to do with single points of failure... Socrates2008 (Talk) 11:36, 10 September 2011 (UTC)

Let me say up front that I have no special interest in either praising or critiquing Windows. What I find most interesting about the Registry is that is arguably the feature of Windows that most sets Windows apart from other operating systems like Linux, OS X, etc. This in turn makes it one of the most interesting features in the design of Windows. It was nearly two years ago that I took apart a crude "Pros and Cons" section in this article and rearranged the text into a Rationale section and a Criticisms section that have since grown to (somewhat) better capture the engineering trade-offs that went into the original design of the Registry. Both sections need more work; specifically, they need more text and references, not fewer. Unfortunately, like many current WP articles, this one overall is still heavily focused on "what does this man-made object/system consist of" (its anatomy) and is a bit light on answering "why is this man-made object/system designed the way it is" (its design principles).

As for the specifics of the single point of failure criticism, the following web link is typical of a Registry SPOF: http://answers.microsoft.com/en-us/windows/forum/windows_xp-system/xp-registry-file-failure-error-on-start-up/ebde8a40-e333-4140-83a0-84953caa2de5

You'll note that the entry refers to the dreaded XP error STOP: C00000218 {Registry File Failure} "The registry cannot load the hive". The Microsoft engineer helpfully explains that if the user has the Windows XP CD at hand, they can boot from the CD and proceed from there to the recovery console and restore a previous registry version. What isn't explained is that if the user doesn't have a Windows XP CD at hand (and as many laptops today don't ship with one because Windows is pre-installed, this is not an unlikely scenario), the user now has a boat anchor. So in answer to your question, yes this is a SPOF in the fundamental sense that Windows can't boot without a functioning reigistry and therefore the whole computer fails to function. The user cannot do anything at all except perhaps boot another copy of Windows from an external bootable medium. It's also important to note that the Windows recovery console is a feature introduced in Windows XP specifically to deal with the SPOF, so it may be fairer to say that the Registry is an SPOF which did not exist in versions of Windows prior to Windows 95 and whose severity has been mitigated in more recent versions by the introduction in XP of a comprehensive Registry checkpoint facility to provide automatic back up of the Registry and manually initiated restoration of previously backed up copies.

There is one more point to be made about the above link. Despite being a blog, I would argue that this is still a perfectly valid WP reference. It is a blog entry at microsoft.com that has information provided by a Microsoft staff member in an official capacity. Official company blog entries like this are often the only detailed source of information on technical issues that haven't been thoroughly edited to ensure that nothing said about a company's product can be construed in anything other than a glowing context. I would argue the same is true of the IBM DeveloperWorks article from their technical library.

Finally, it worries me that despite the Rationale section having only one reference, no one has added {citation needed} to its many statements. By contrast, despite the Criticism section having five references, it also has one {citation needed} and is engaged on an almost monthly basis by one editor or another wanting to remove or etiolate one of its points. We need to ensure balanced coverage, even when some of the text is in a less-than-perfect, work-in-progress state. Ross Fraser (talk) 03:06, 15 September 2011 (UTC)

Thanks for your long reply. The Registry certainly has its faults, but that does not mean to say a disk error or a power failure that results in file corruption, and ultimately a stop error like C00000218 per your example, is the fault of the Registry itself. e.g. What if the file that became corrupted through a disk hardware error happened to be some other file, such as kernel32.dll - you'd simply get a different BSOD stop error, apparently pointing to some other fault. I happened to experience a scenario today where a faulty disk was causing stop errors that appeared to point to the USB subsystem. My point is that a hardware error can effect any critical binary or configuration file in a system that does not have redundancy built in, and in ways that are not always obvious from the error. There's no Registry-specific (re)design that can compensate for this failure mode because the SPOF is in underlying hardware.

The risk of someone deleting or changing the wrong value on the other hand is a shortcoming that even Microsoft takes seriously, hence the caveat attached to every KB article that contains a registry edit. But that's not a SPOF discussion.

PS: WP does not accept discussion forums as reliable references. Socrates2008 (Talk) 12:37, 15 September 2011 (UTC)

You've missed the point. It is not simply a question of a file being unreadable due to a disk hardware failure. The registry can become corrupted and therefore unloadable without any failure in hardware. There is a cottage industry of registry cleaners and fixers to address this problem. The very introduction of the recovery console by Microsoft serves no other purpose than to address this serious SPOF problem with the registry. I've found a Microsoft Knowledgebase article "How to recover from a corrupted registry that prevents Windows XP from starting" that specifically deals with registry corruption -- not hard disk failures, but corruption -- and added it as a reference. There is nothing self-published about MS KB articles.

See also the following warning on the fagility of registry edits and their ability to irretrievably brick a system even when the edits are made via the Registry Editor: "Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk." -- from Microsoft KB article 256986 (http://support.microsoft.com/kb/256986) Ross Fraser (talk) 23:31, 15 September 2011 (UTC)

Well, no. As I suspected, you're confusing Registry database corruption with junk configuration data that has been written into its database (and that is perfectly readable). Stop error C00000218 is caused by a hardware error when a registy hive can't be mounted, not because there are missing configuraion items in it. Normal reading and writing operations to the Registry do not corrupt it - if that were the case, there'd be a critical hotfix released immediately. The Registry cleaner cottage industry can't fix a Registry that is corrupted, because a corrupted hive can't be mounted for editing; you would need to follow a procedure such as that outlined in KB307545 (or one of the other recovery procedures). Calling the Registry a single point of failure in the context of a hardware failure would be completely inappropriate as its failure is an effect, not a cause.

Logical "corruption" on the other hand is where the Registry database itself can be mounted and is functioning perfectly, but someone (or some process) has written junk data into it, or deleted some data of importance to another process - hence the std caveats that apply when the uninitiated start using Regedit. If someone had finger trouble and accidently deleted everything in the database, they could potentially use Regedit (or any other application such as a Registry Cleaner) to put everything back, or they could follow the same recovery procedure as that for a corrupt Registry by restoring the underlying Registry database files. A number of valid criticisms of the Registry are centred around this aspect of its design that centralises the settings of unrelated components and applications, thereby making it too easy for applications to modify settings they shouldn't, to make conflicting changes or to leave orphaned data behind after uninstallation. The resolution is not to add redundancy as one would with a SPOF, but rather to apply modular design by isolating settings of different applications, as .Net now does with its XML-based approach to configuration. Socrates2008 (Talk) 10:58, 17 September 2011 (UTC)

I'm very close to putting an NPOV tag on this article, as your deletion of the this criticism without further discussion is suspect to say the least. You also haven't read KB article 256986 which has nothing whatsoever to do with hardware errors. If you don't think the reference to KB307545 is appropriate, then delete THAT REFERENCE. To assume that the overall point refers merely to hardware errors is a gross misreading of the text. Ross Fraser (talk) 21:57, 18 September 2011 (UTC)

I'm actively discussing this this with you, and have put forward a number of points that you have not answered, yet your best response is to threaten to put a POV tag on the article and to revert my edit?

While you're thinking how to answer my previous post on this page, here's some more background that might help - I am a subject matter expert in this field, so if I have a POV, it has come about from analysing hundreds of crash dumps (BSODs) with stop errors like the one you provided by example. Microsoft lists 3 reasons for Registry corruption: 1) Power failure (hardware related) 2) File corruption, notably through hardware failure and 3) incomplete writes during shutdown (hardware or maybe drivers). I would add memory corruption in the case of Windows 9x, because processes did not run in their own memory space back then and could therefore in theory corrupt anything in memory. If there is any evidence that the Registry can somehow become "corrupted" of its own account through software error, I can assure you that Microsoft will have an avalanche of severity A support calls logged by its enterprise customers like myself demanding a fix in hours. Of course this is original research from the point of verifiability at Wikipedia, so we have to find the refs to support the article content. When someone who doesn't know what they are talking about is quoted and supplied as a reference, or when an editor argues to use a (misguided) discussion forum as a reference, I'd certainly call that POV. You're going to struggle to find a hotfix for Registry corruption - so how do we deal with the reference for that? So please feel free to place whatever tags you wish, but it's not going to correct the obvious errors of fact and inappropriate use of very specific engineering terminology.

From the discussion thus far it's really apparent that most people have no idea what a Registry database is, what happens when one can't be mounted, how corruption occurs, and what the difference is between (logical) database junk and (physical) database corruption. These are basic principles of database administration that are equally applicable here. e.g. Do we say that Oracle has a "single point of failure" if someone accidentally deletes 100000 rows from a table? No, because no amount of redundancy will fix that particular problem. (Do I have to explain the inverse relationship between concepts "single point of failure" and "redundancy"?)

FWIW, I'm not arguing to remove criticism about the Registry - on the contrary, it has many issues, but we have an obligation to get the facts straight. Socrates2008 (Talk) 11:57, 19 September 2011 (UTC)

There are 2 features of Windows registry that are not mentioned and I consider them the most important. 1)API includes opportunity to register an event in a thread of process and triger the event on the access to the entry. Interesting that deleting the entry does not triger the event. 1)The registry of each computer is accesible thru network. Actually DCOM based on it. I used those features on XP and now on W7 x64 for doing very interesting things. Yakov "Jacob" Vizel ytv10000@aceweb.com — Preceding unsigned comment added by 72.89.210.51 (talk) 16:13, 25 December 2011 (UTC)

Accessability thru network, registering and triggering events

72.89.210.51 (talk) 16:38, 25 December 2011 (UTC)There are 2 features of WR that are not mentioned and which I consider the most important. 1)Registry of a computer can be accessed thru network of Windows computers. 2)An event in a thread of a process can be registered in the registry and set on access to the registry by another process. Interesting that the event is not triggered upon deleting of the entry. I have been using this features since XP and now on W7 x64 for easy implementing advanced things related to integration and security. Yakov "Jacob" Vizel (Redacted)

Links

This: http://www.beginningtoseethelight.org/ntsecurity/index.php is one of the only sources information about the binary format of registry hive files that I have ever found. I believe that it should be included. — Preceding unsigned comment added by 75.154.106.91 (talk) 15:42, 17 April 2012 (UTC)

Restoring data from registry backup

86.151.45.94 (talk) 08:44, 18 July 2012 (UTC) Pure self-interest but here goes... I recently bought a new laptop. I had performed a system and normal backup of my old laptop. I no longer have the old laptop. I realise I want some settings from an application on the old laptop that I have installed a fresh copy of on the new laptop. The settings are stored in the backup HKCU\Software\ (NTUSER.DAT). Obviously I don't want to restore the whole of NTUSER.DAT, just the sub-keys I need. How do I do it? On the surface it seems easy - restore NTUSER.DAT from the backup, fire up regedit.exe, open the NTUSER.DAT hive from the backup, export the keys I want to a .reg file, import the .reg file to the live registry. However, regedit just seems to open the live registry and the File->Load Hive option is greyed out / unavailable. Some explanation around how to do this sort of thing (short of reboot/F8/restore) would be useful. Thoughts?

Hello. This is not a support forum - it's a place to discuss improvements to a Wikipedia article. Suggest you take your question here. Socrates2008 (Talk) 10:14, 18 July 2012 (UTC)

I understand this is not a help forum. It is however a web site that people (including me) search to find useful background / pointers to relevant information. The topic I mentioned is not covered so including something on the area (even if it only an off-site link) would, IMHO, improve the article. 86.151.45.94 (talk) 13:21, 18 July 2012 (UTC)

This is one of several limitations of the Windows Registry. You cannot transfer registry settings between different computers running Windows. Also, you cannot copy apps over between different computers running Windows without re-installing them, unless the apps store all of their data in the same directory and not in the Windows Registry. This info was in the page, but the pro-Microsoft fanboys scrubbed it off. Does the Windows Easy Transfer copy portions of the registry from one Windows computer to another? If so, it would be worth mentioning that in the page. TurboForce (talk) 11:24, 18 July 2012 (UTC)

"You cannot transfer registry settings between different computers running Windows". Clearly this is possible by: (1) registry restore / repair (2) registry export / import (.reg files). My case is (3) backup of original registry intact and want to import part of it to new registry. Windows Easy Transfer seems to require access to the original system (not sure if it is possible to use it with a windows backup image - I doubt it). 86.151.45.94 (talk) 13:21, 18 July 2012 (UTC)

It is not possible to do this. The registry cannot be transferred between computers, because the registry data is different on both computers. I understand your frustration and it would be great if you could copy the settings over, instead of having to manually reconfigure everything and re-install apps, which takes hours (yes I've done this many times!). This limitation of transferring settings applies to most modern operating systems, because the configuration data is saved all over the place in zillions of different places. I know that in Linux you may be able to transfer every users' /home directory between computers in order to move their custom settings over, but it's not always guaranteed to work. The same may apply to other Unix and Unix-like operating systems? It would be quicker to manually reconfigure everything from scratch than try to transfer registry data. TurboForce (talk) 13:35, 18 July 2012 (UTC)

Yes it is. User profiles (and user-specific registry hives therein) are freely transferable, even when not using roaming profiles. There's the User State Migration Tool (now used by setup when upgrading the OS too) or Easy Transfer. Then there's application virtualization for legacy apps that were not designed to be portable. Oh, and most legacy COM apps can reregister machine-specific settings themselves using Regsvr32 or -regserver

PS: Regarding greyed out File | Load, you can't mount a hive without the required permissions (backup privilege or administrator), and you must also typically mount to the root of a hive. Socrates2008 (Talk) 11:54, 19 July 2012 (UTC)

Locked registry keys

Why are some registry keys "locked" and unable to be edited or deleted? The page could mention "locked" registry keys. TurboForce (talk) 13:29, 20 July 2012 (UTC)

For the same reason that locked files cannot be deleted - some process has opened the key, but failed to close it, causing a handle leak Socrates2008 (Talk) 12:23, 21 July 2012 (UTC)

Some registry keys and entries are undeletable i.e. when editing the registry, the key cannot be deleted, even in safe mode. Maybe this behaviour is caused by a rootkit? But I have seen cases where legitimate registry keys or entries cannot be deleted and seem to be "locked". Interesting and maybe worth mentioning in the page what causes this locking behaviour? TurboForce (talk) 19:54, 21 July 2012 (UTC)

It could also be that those keys cannot be edited (even by Administrators), precisely to prevent infection by rootkits. However, on a live system, it's probably indeed 'in use' and thus locked. In fact, I think that's the main way rootkits block editing too. I think with some sources detailing the possibilities, this could indeed form a short paragraph for the article? --DanielPharos (talk) 09:45, 30 July 2012 (UTC)

WP:OR. Rootkits typically hide keys - I've never heard of them locking keys to deny access to other processes, so happy hunting finding a ref for this. Socrates2008 (Talk) 10:51, 30 July 2012 (UTC)

Well, it appears to be the entire reason for this tool to exist: [1], and I've seen in happen in the wild. Also, if I were a malware-writer, I'd do it. But of course you're right: we should consider it OR unless some proper sources are added to it. I was merely pointing out that TurboForce is right in that rootkits *can* be responsible for undeletable Registry keys. --DanielPharos (talk) 14:47, 30 July 2012 (UTC)

Windows registry keys cannot be "locked" as such. One can set permissions on individual keys/values so that regular users are not allowed to delete/change the keys. Just like with regular files, you can even deny administrator access by transferring ownership to another account and explicitly/implicitly deny administrators access. However, you cannot prevent the administrator from taking advantage of the "take ownership" super privilege to take back ownership. A possible source of this "locking" myth is the fact that when an app requests deletion of a key/value, it is only marked for deletion. The actual deletion will occur automatically when the last handle to the key is closed. Running applications (could be malware) may certainly keep keys open - and thus delay the deletion. But they cannot prevent it. Some malware registers itself to run during logon/boot so that it may change back or re-add keys, thus it may appear as if the key cannot be deleted. Also, some hives are transient and are maintained by the kernel. You cannot change the values of those keys. Useerup (talk) 22:47, 30 July 2012 (UTC)

Huh, I never knew that... I stand corrected, and learned something new. :) --DanielPharos (talk) 06:40, 31 July 2012 (UTC)

I wonder if undeletable registry keys are being mistaken for "locked" registry keys? This tool can delete the undeletable keys. TurboForce (talk) 11:20, 31 July 2012 (UTC)

A malware app that leaked handles would attract unwanted attention to itself. One of the primary reasons for not being able to delete keys is when they contain NULLs that prevent tools like Regedit from deleting them - this is normally a limitation with the Regedit tool itself, not in the underlying APIs (see RegDelNull). Also, Registry info is not really "deleted" from the Registry - like many other databases, the records are simply marked for deletion in the internal database as this is more efficient on I/O. Socrates2008 (Talk) 11:26, 31 July 2012 (UTC)

When the user is unable to edit or delete anything in the registry (such as the leftovers from a failed un-install), this is what I'm referring to when I describe the "locking" behaviour here. I'm hoping someone can add this info to the page and explain why registry entries can become locked. TurboForce (talk) 15:41, 2 August 2012 (UTC)

I suspect that whenever a user is unable to edit or delete keys and/or values it is because of either 1) inadequate permissions or 2) attempt to edit a transient (and system-maintained) hive. Can you point us to any instance where it is documented that a user has been unable to edit keys and where these two causes can be ruled out? Useerup (talk) 16:00, 2 August 2012 (UTC)

Now we're getting somewhere. Can we try to find all the possible reasons why registry keys become locked and mention these reasons on the page? Looking for answers, I found this page on Microsoft's website, which says that the user will be unable to delete a key with "embedded null characters" and the page says "This usually occurs due to a corrupt application install or similar", which could explain why registry entries appear to be "locked" when the user tries to delete them after an app's un-installer pukes before the end - a situation I've witnessed a number of times! TurboForce (talk) 18:17, 2 August 2012 (UTC)

Did you read User:Socrates2008s reply above? user:Socrates2008 wrote: "One of the primary reasons for not being able to delete keys is when they contain NULLs that prevent tools like Regedit from deleting them - this is normally a limitation with the Regedit tool itself". It seems that the registry allows keys to be created with embedded NULL characters, but that some tools have problems handling those keys. However Windows itself does not create or look for keys with NULL characters. If you create such a key it will not have any effect on anything - since nobody is looking for it. Some tools (evidently regedit) cannot delete the key. Your point? Do you really think that a bug in regedit is worth mentioning in the article? Useerup (talk) 21:35, 2 August 2012 (UTC)

Yes I've read all the points in this section. Again, I think it would be good if the article can explain all the reasons WHY registry entries become locked. If the regedit supplied with Windows cannot do anything with keys containing NULL characters, but the Windows registry itself contains keys with NULL characters then I consider this a major problem. Why is the Windows registry allowing keys with null characters to be created and the supplied regedit from Microsoft can't do anything with those keys containing NULL characters? If the settings were saved in plaintext files instead, and something got "corrupted" in a plaintext file, the user could use any text editor and remove the corrupted data, provided the user had the privileges to edit that file. Does anyone have the time and expertise to explain in the article *all* of the reasons why registry entries become "locked" and does not allow the user to delete and/or edit them? TurboForce (talk) 12:20, 3 August 2012 (UTC)

After 4 days, has anyone decided on this? It would definitely be a good idea to mention in the page why registry keys can become "locked" - or whatever you want to call it when you can't edit something in the registry for whatever reason. No, I'm not just referring to NULL characters - which could also be mentioned as well. Not trying to go off topic: the use of "third party" registry editors could be mentioned if they are notable or have extras that the Windows registry editor lacks; I can remember a registry editor was included in Norton Utilities. The RegDelNull is a notable example, although not a full-featured registry editor. TurboForce (talk) 11:08, 7 August 2012 (UTC)

It is a non-problem and a fringe problem. There is no "locking" of registry keys. They can have security descriptors which may block users from editing (or even reading) keys they are not permitted to. The "embedded null" keys allows someone to create a key which cannot be deleted by the regedit editor. But that cannot be utilized to "lock" any keys that control anything in Windows or any application. There's is preciously little information about this problem *anywhere*. It is definitely not a notable issue. Useerup (talk) 19:32, 7 August 2012 (UTC)

Thank you for explaining it. To someone who is reading the page because they think a registry key is "locked", the page could at least explain better what measures are in place to prevent users from editing certain registry keys. Perhaps a new section like "Registry key protection", which discusses how the measures are implemented e.g. security descriptors, or even other causes such as a handle leak - mentioned earlier. Why would anyone want to create a registry key which cannot be deleted with the supplied regedit? My first thought is malware taking advantage of that! I have created a section in my userpage to show how something supposedly simple can quickly cause confusion and a *lot* of debating amongst readers. The Windows Registry page could do a better job of explaining, simply, why some registry keys are protected or blocked for whatever reason(s). TurboForce (talk) 21:02, 7 August 2012 (UTC)

Well, if you feel that some information about the ACLs of Registry keys is missing; be bold and add it! --DanielPharos (talk) 06:00, 8 August 2012 (UTC)

....but WP:V and WP:RS apply! The new "Security" section was laced with errors, which I've had a go at fixing, but references are required please otherwise the new section must go. Socrates2008 (Talk) 10:25, 8 August 2012 (UTC)

references added... Useerup (talk) 12:22, 8 August 2012 (UTC)

I've not yet come across a ref link to prove that a "handle leak" can prevent the user from editing a registry key; I have come across several Microsoft support pages which mention this problem, such as this one. I'm hoping to list all the possible reasons why a user may be blocked from either deleting, editing or even reading a registry key. It is not just security measures which blocks the user from doing something in the registry. TurboForce (talk) 17:24, 8 August 2012 (UTC)

I don't think you're going to find one - looks like handle leaks only prevent hives from unloading (hence UphClean) and depletion of system resources. PS: Sloppy coding is another reason that keys "can't" be deleted. Socrates2008 (Talk) 11:11, 9 August 2012 (UTC)

Thanks for the info. I always laugh at the fancy words "this behavior is by design" in them pages. xD At least on this page, we can mention all the other reasons why registry keys can't be deleted, even if these don't make it into the main page. TurboForce (talk) 11:55, 9 August 2012 (UTC)

I am curious: Why do you feel this is a notable topic? Remember, to be notable it is not just that you feel that it is important. This issue seems rather fringe (evidenced by the lack of sources) and it will run afoul of WP:UNDUE. Right now you have piggy-backed the security section with a fringe issue which has nothing to do with security. It has to go somewhere else. But before creating a section where you are going to "mention all the reasons why registry keys can't be deleted", please make a case for how this is WP:DUE. Useerup (talk) 12:13, 9 August 2012 (UTC)

Let's keep things simple. When the user is blocked from doing something with a registry key, there are other reasons outside of any security measures in place. Why would the user see "error deleting key"? The user should not be under the illusion that a security setting somewhere has blocked/locked that key (or whatever you want to call it) when in fact it's something else. TurboForce (talk) 12:39, 9 August 2012 (UTC)

Why do you think this is notable? Useerup (talk) 12:52, 9 August 2012 (UTC)

It's obvious: if registry keys are protected/locked/blocked for other reasons not mentioned, then the security section is misleading. It's missing the facts. Maybe those missing facts belong elsewhere on the page? There's more information about it on this page than the main page. TurboForce (talk) 13:13, 9 August 2012 (UTC)

Useerup is right - I think this just turned into a fishing expedition. Socrates2008 (Talk) 11:31, 10 August 2012 (UTC)

If you're happy with the main page misleading readers then fine. It's crystal clear that there's other causes, outside of security measures, which can block registry keys. Lucky Wikipedia is not a book publishing company, who wants all the correct information, not some of it omitted. TurboForce (talk) 20:07, 10 August 2012 (UTC)

If it's "crystal", then where are all the supporting refs? WP:OR applies. Socrates2008 (Talk) 10:36, 12 August 2012 (UTC)

It's been discussed here. I've already added info about the "NULL" character registry keys, which are un-deletable with regedit. If there are other notable reasons why anything in the registry is blocked in some way, not caused by the security settings, these reasons should be mentioned, along with good refs of course. Maybe malware or a poorly written app has blocked a key because it's "in use"? Sometimes refs are hard to find, just to prove what's already correct. TurboForce (talk) 18:33, 12 August 2012 (UTC)

As we (I) learned about two weeks ago, there is no "in use"-state when it comes to Registry keys, so I don't know what you're going on about. In fact, you *can* delete a key while it's still opened by other processes: [2] (Note, however, that this is only available to drivers.) --DanielPharos (talk) 20:06, 12 August 2012 (UTC)

Doesn't have to be a driver - PowerShell example below showing an open key successfully being deleted from another process. We're done here. Socrates2008 (Talk) 12:43, 13 August 2012 (UTC)

PowerShell example of deleting an open key

[string]$testKey = 'Software\MyTest\DeleteMe' Write-Host "Opening 'HKCU\$testkey' for write access" [Microsoft.Win32.RegistryKey]$key = [Microsoft.Win32.Registry]::CurrentUser.CreateSubKey("$testkey") Write-Host "Writing a value to 'HKCU\$testkey'" $key.SetValue('Hello', 'World1') Write-Host "Deleting 'HKCU\$testKey' from another process" Reg.exe Delete "HKCU\$testKey" /f Write-Host "Writing another value to 'HKCU\$testkey'" $key.SetValue('Hello2', 'World2') $key.Close() Opening 'HKCU\Software\MyTest\DeleteMe' for write access Writing a value to 'HKCU\Software\MyTest\DeleteMe' Deleting 'HKCU\Software\MyTest\DeleteMe' from another process The operation completed successfully. Writing another value to 'HKCU\Software\MyTest\DeleteMe' Exception calling "SetValue" with "2" argument(s): "Illegal operation attempted on a registry key that has been marked for deletion."

I was actually planning on trying that myself just now, so thanks for being quicker than me! ;) Yep, that's the end of this discussion then... --DanielPharos (talk) 17:57, 13 August 2012 (UTC)

Unreliable source

The link to http://www.docstoc.com/docs/2381418/Forensic-Analysis-of-the-Windows-Registry-Computer-Forensics appears to be an assignment. It is not clear how it has been reviewed/challenged and the sit on which it is published does not claim to have any such process in place. If anyone can find a link to a e.g. a trusted publisher or similar where the status of the paper can be verified please link to that instead. Otherwise it is a self-published paper. Useerup (talk) 15:57, 2 August 2012 (UTC)

Look at the references from page 32 onwards. If the paper is correct, then I don't see anything wrong with citing it. I've not had the time to thoroughly read it, but skipping through it quickly - I can see that the author has used many references and it does not appear to be any kind of self-published reference. What do other readers' think? TurboForce (talk) 18:02, 2 August 2012 (UTC)

The paper looks like an assignment which has been turned in as part of a university course. There is no reason to doubt that it is anything but an academic paper. But that's not the point. The point is that it contains opinions and we cannot see that it has been published in a way which would have invited opposition. There is no reference to how the paper was received, graded, defended or opposed. This falls under WP:QS. The paper was basically uploaded to a document store with no context. That is why I call for some reference (e.g. a reputable news site) which has published the paper. Absent that, it is basically a self-published source. Useerup (talk) 21:28, 2 August 2012 (UTC)

All source material is published by a person or persons, just like industrial robots in factories are created by humans in the first place. As long as the paper is correct and the author(s) have used valid references, I don't see there being *any* problem with using it as a ref. You could be checking Wikipedia articles for literally years to see if all the references are to your satisfaction, especially articles in which web references are almost non-existent, in which case book references can be used - but would you be able to locate that book and read it thoroughly? It appears that you're only checking the validity of ref links if there's any negativity about Microsoft products. Do you check ref links with the same thoroughness if there's statements in Wikipedia articles praising Microsoft? I don't want a full scale argument and I don't have much time to dedicate to editing Wikipedia at the moment. I'm glad you have explained some of the registry "locking" behaviour in the previous section, which I must emphasise is not a criticism, but a technical issue with the Windows registry, which would be great if it's mentioned in the main page. Anyway, enough typing now because I'm tired and the time here is actually 1 hour ahead of what's showing next to my username (BST). TurboForce (talk) 22:10, 2 August 2012 (UTC)

And who get to decide whether a paper is "correct"? I have read the paper and I certainly see some inaccuracies as well as outdated information and speculation. The paper cannot stand alone. Read the policies on reliable sources, please. Useerup (talk) 22:13, 2 August 2012 (UTC)

Does it meet WP:RS? Yes - primarily because it's published by a university. What score would it get out of 10 for "correctness" and completeness? 6.5 Socrates2008 (Talk) 11:08, 3 August 2012 (UTC)

The problem is that the paper is not published by an university. It appears to be an assignment which has been uploaded to a document sharing site. It does not reside on any university site. In fact there is no context, not even a year on the "due date". We have no idea of how it was received. Useerup (talk) 12:30, 3 August 2012 (UTC)

This document was indeed written by a student of the university: [3]. The 2006 finishing year is consistent with the references in the document; only 2006 and earlier. --DanielPharos (talk) 09:51, 4 August 2012 (UTC)

Nice find. The university actually has a searchable database with research papers. But I cannot find this paper in it. If the paper was publishes by the university it would certainly meet WP:RS. But it is not and it does not. Note, that I'm not opposing the assertions or conclusions made in the paper, I just don't think that it meets the requirement that a RS should have been subjected to peer review or meaningful editorial oversight. In this context the paper main purpose (forensics) is not even used, merely an outdated assertion from the paper is used. Useerup (talk) 20:56, 4 August 2012 (UTC)

I removed the references to the student assignment. The claims now lack proper citation/attribution and I have marked them as such. Useerup (talk) 05:32, 28 August 2012 (UTC)

Upgrading Windows versions

What happens to the Windows Registry when you upgrade Windows in place - example: upgrading Windows Vista to Windows 7? TurboForce (talk) 12:08, 25 August 2012 (UTC)

WP:NOTFORUM: Please bear in mind that talk pages exist for the purpose of discussing how to improve articles. Talk pages are not mere general discussion pages about the subject of the article, nor are they a helpdesk for obtaining instructions or technical assistance. Having said that: The system hive (the one containing system and driver settings) will be replaced. User hives with user settings for software/applications survives unaltered (possibly moved and symbolically linked or mounted from the new location). Useerup (talk) 16:46, 25 August 2012 (UTC)

Thanks. I know these are not forums. Anything I put in discussion pages should be used for improving the article; I should have reworded my sentence really. The Wikipedia feedback pages suffer from the same problem, amongst other problems!

I think it would be good to put your info into the article. The article only briefly mentions this: "Userdiff – Not associated with a hive. Used only when upgrading operating systems." TurboForce (talk) 19:05, 25 August 2012 (UTC)

Win7 and Win8 are no longer a true upgrade as per earlier versions of Windows, but rather a clean install with selected settings/apps migrated from the old OS into the new one using either USMT or Windows Easy Transfer. Socrates2008 (Talk) 09:22, 27 August 2012 (UTC)

Definition of "Hive"

Microsoft states “A hive is a logical group of keys, subkeys, and values in the registry that has a set of supporting files containing backups of its data”.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724877%28v=vs.85%29.aspx

This Wikipedia article states that hives are actually the supporting files containing the backup data.

"Even though the registry presents itself as an integrated hierarchical database, branches of the registry are actually stored in a number of disk files called hives."

So, what about the sections in the registry that have no corresponding file because it is a volatile key that is created (and built) by the kernel at system start? (Also described in the same msdn document.)

98.169.82.242 (talk) 22:58, 1 January 2013 (UTC)Mark Mabee

Could you make the changes to make the article more correct? Useerup (talk) 16:08, 2 January 2013 (UTC)

Hex keyword token in .REG file definition?

The token "hex" is apparently a keyword token in the .reg file format, and the value which follows in parentheses. I cannot find any documentation on this in the Microsoft documentation [sic]; specifically, there is no mention in citation [17]. Is the material in the .REG files section from a Microsoft site? Or is it derived from empirical induction? If the former, please add a reference; if the latter, please note this explicitly. — Preceding unsigned comment added by RobertREvans76 (talk • contribs) 16:07, 23 April 2013 (UTC)

Meaning of HKEY

Suggest that an explanation of the term HKEY be included in this Wikipedia page along the lines of this extract:

'HKEY stands for "Handle to Registry Key" and is a typedef supplied in the Windows headers files. The Window architects use the opaque handle scheme that most operating systems use. When requesting resources from the operating system, you are given a "handle" or cookie that represents the real object. In order to protect the internals from changes, the handle is not the actual data. The folks working on the registry system happened to want to differentiate a handle returned from the registry from one returned from CreateFile, for example. Therefore, they called it HKEY.'

From: http://searchwindowsserver.techtarget.com/answer/What-does-HKEY-mean-or-stand-for CPES (talk) 15:28, 4 October 2015 (UTC)

This article needs Windows 10 content

As it says, programs put their initialization information into the registry instead of .ini files. But now, under Windows 10 in User mode, old programs cannot even read the registry. Some info here on how the registry is used and interacts with UAC in Windows 10 would be most welcome.69.74.253.62 (talk) 13:50, 4 August 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on Windows Registry. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080509003336/http://docs.rinet.ru/Registratura/htm/apf.htm to http://docs.rinet.ru/Registratura/htm/apf.htm
• Corrected formatting/usage for http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/
• Added archive https://web.archive.org/web/20120527133205/http://roscidus.com/desktop/AppDirs to http://roscidus.com/desktop/AppDirs
• Added archive https://archive.is/20070219161339/http://productsdb.riscos.com/admin/riscos.htm to http://productsdb.riscos.com/admin/riscos.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:35, 13 January 2018 (UTC)

Window`s Server 2008

name a utility that can directly manipulate the Window`s Server 2008 Registry? SophiaRoboticsRobots (talk) 02:54, 23 April 2019 (UTC)

Registry has many more disadvantages

Registry has many more disadvantages. Furthermore, in the current disadvantages section there is one sentence of disadvantages and three sentences of advantages. It is ridiculous and obviously biased. — Preceding unsigned comment added by 93.92.193.34 (talk) 12:15, 29 January 2020 (UTC)