Troubleshooting a Corrupted Registry
From our short exploration of Process Monitor, you can appreciate that for every piece of software that is installed or run on and even removed from a PC, the system will write, query, or delete entries in the Windows Registry. It is therefore vital that you maintain the Registry carefully and ensure that it is kept in good working order.
It is not only that Windows depends on the Registry; applications also store settings and query Registry keys on a regular basis to guide their operational behavior. When corruption occurs, both system and application failures can often be traced to a rogue or incorrect Registry item that can result in error messages and sometimes cause a system to crash.
The main causes of Registry corruption on PCs are:
- Windows Registry corruption
- Software installation or application failure
- Hardware or device driver failure
Windows Registry Corruption
The Registry is a complex database that on occasion can become corrupted. This is, however, quite rare, due to the approach that Microsoft has adopted and refined over the last 30 years of developing Windows. Let us explain.
The Registry is implemented and managed by an executive subsystem called the Configuration Manager (CM). The Registry is made up of several independent Hives, which are then brought together for viewing by the Registry Editor. The CM organizes the Hives on disk and ensures that whenever an application or operating system component reads or changes Registry values or keys, the Registry is always in a recoverable state-even if the PC suffers a crash during Registry modification.
This is achieved by caching parts of the Registry, which allows for very fast search, write, and commit operations. The Registry has evolved from being stored in a simple, flat file structure to benefitting from advances in database technology, so that each in-memory operation is now treated as a transaction and recorded in a special dual-logging scheme. This approach ensures that the transaction will be rolled back if the task could not be completed due to a system failure. Only completed transactions are committed to the Registry.
In addition to the micro-level transactional processing, modern versions of Windows offer self-healing capabilities with features and services such as improvements to New Technology File System (NTFS) and automatic disk check and repair tools, so the underlying file system on which the Registry files are stored remains safe from corruption, thus maintaining Registry integrity.
When a PC is booted, at the beginning of the system boot process, prior to the kernel being loaded (and before the user is presented with the login screen) the Windows Boot Loader also runs some code to ensure the Registry is in a reliable state. If there are inconsistencies, the Boot Loader can perform automatic repairs to fix them before proceeding to load the kernel.
If the system encounters an issue where it needs to invoke a self-heal process, the user will see a pop-up dialog box stating that there was a system error and that the error is being repaired. Once this is completed the PC will continue to load normally.
Software Installation or Application Failure
We have already discussed that during its installation and subsequent configuration, application software writes new Registry keys and updates others with the necessary data to allow the software to work and for Windows to interoperate with the application.
When you use a tool such as Process Monitor, you can witness many hundreds of thousands of key entries and configuration changes to the Registry during a typical installation. Even if you deduct from this number an estimate of the Registry changes that occur normally, you will still see many thousands of Registry interactions. Despite advances in how Registry keys are created, modified, and deleted so that no transaction can be left "orphaned" (i.e., partially complete), this is not the case on older operating systems, on which the "blue screen of death" was often caused by the system not being able to read the expected Registry key due to a write error or power outage corrupting part of the Registry.
On all versions of Windows, the Registry is very susceptible to rogue keys being written during software installations; very often numerous keys are simply left in place even after the software has been uninstalled. Much of the time this is due to an element of laziness by the software author and that during processing, the Registry does not check the robustness of the transactions the software installer has provided.
Software vendors often use the Registry to store and maintain licensing information for the software, which is often locked to the specific user account. In some cases the practice of leaving behind licensing status information in the Registry can be a valid strategy-for example, most trial versions of software will not allow the user to uninstall and reinstall the same software on the same PC in order to gain an additional trial period.
The prevalence of malware infecting a PC during software installations is entirely preventable, though this is very much dependent upon the usage of the PC, the user account credentials, and whether UAC is in operation.
In summary, over any period of time, whether this is one year or several years, the Registry on your PC will often accumulate a great deal of unwanted, often obsolete information. Unless malware causes other, more serious problems first, the combined effect of this excess clutter will be a bloated Registry, which can lead to degradation of system performance, increased frequency of application errors, and more system freezes and crashes.
Hardware or Device Driver Failure
Hardware and drivers are typically supplied by the hardware vendor and issued as a CD, DVD, or download for the user to install when configuring the device.
For most of the lifetime of Windows, Microsoft has implemented a program that allowed Original Equipment Manufacturers (OEMs), upon payment of a fee, to supply their drivers to the Microsoft Windows Hardware Quality Lab (WHQL) team. The WHQL would extensively test and verify the compatibility of the driver against the selected operating system, and if the driver was functional then Microsoft would digitally sign the driver, include it in its Upgrade Advisor tool (which replaced the Hardware Compatibility List [HCL] used in the XP timeframe), and make it available as part of Windows Update.
Hardware vendors could also enroll in Microsoft's "Compatible with Windows XP" or "Certified for Windows 7" programs, or later, the Windows Hardware Certification Program-all of which boosted sales through the reassurance that the device/software would be compatible.
Over the last five years, especially since Windows 7, hardware drivers have become much more robust than those found in Windows XP and especially the troublesome Vista. Windows XP suffered mainly due to the patchwork nature of its own evolution- remember that XP was launched in 2001, years before innovations such as Bluetooth and USB 2.0 had taken hold, and XP did not even Release to Manufacturing (RTM) with a firewall in place. Over its lifespan Windows XP had three major service packs (SPs) as well as thousands of smaller updates during the period that Microsoft still supported it. While this may or may not have created an unstable platform on which OEMs had to write drivers, it did create a headache for the HCL, and OEMs decided not to keep subscribing over and over again to get drivers validated for each SP.
Over time as XP became widely adopted, OEMs cut back on the driver approval process to save money. Without the habit or requirement to produce drivers that would be verified against Microsoft's strict compatibly testing, this resulted in some drivers being released that were incompatible and in several cases very suspect in terms of performance and reliability.
Windows Vista suffered from a number of driver-related issues at the time of release. After a long period of Windows stagnation (remember, Windows XP was very successful and users were reluctant to change), Vista arrived without much OEM support.
The lack of adequate driver support was primarily due to Microsoft having changed the way in which Windows worked-Vista was a complete rework as far as the kernel, driver support, and security model. Nearly every legacy driver thus would no longer work with Vista. These legacy drivers would require a complete rewrite-something for which the OEMs did not have the capacity (or, for a period of time, the skilled developers with the up-to-date .NET skills to write them). Writing drivers for the new Windows therefore took some time, both to learn the new skills needed and also to achieve the required driver availability for the installed device population.
Note:
Just as with software installation, it is best practice to reboot the PC after each installation of hardware. This effectively creates a point that is either stable or unstable. Some issues may not present themselves to the user until after a reboot. Both are valuable checkpoints if troubleshooting needs to take place subsequent to the installation.
