In the early days of Windows, applications would often store their configuration data in text documents called initialization files. Typically, these files would use an extension like .ini, .txt, .cfg, etc. One of the major problems with this particular system was that with the sheer number of applications installed, the .ini files would become scattered across the file system, making them difficult to track. After the release of Windows 95, in an effort to further standardize and manage configuration for applications and Windows, Microsoft encouraged software developers to use the Windows Registry as an alternative to INI files for storing configuration data. In the years that followed, the Windows Registry became the standard repository for application settings.

Today, XML files are gaining popularity with developers as a new medium for storing application configuration data for a variety of reasons. However, the registry remains a very important component of Windows; for software developers and windows power users, the ability to manipulate it is an essential skill.

The Windows Registry is essentially a large hierarchical database. Its structure is not unlike that of the Windows file system. Data is stored in entries called values, which are stored in collections called keys. A key in regards to the registry is in essence, a folder of sorts. Keys usually contain a collection of values and sometimes subkeys, not unlike a folder filled with files and subfolders. This makes keys a little confusing, because typically the word ‘key’ in computing refers to the name part of a value in an associative array. Value in terms of the registry refers to both the name and the value of the entry. This is because in the earliest versions of Windows (3.1 and prior), keys in the registry could not contain multiple name/value pairs; it only contained a single value which was tied to the key itself. In this scenario, the structure of the registry much more resembles an associative array and the term ‘key’ makes perfect sense. The elements of the registry have not been given more appropriate names since.

Keys in the registry are arranged into logical groups called hives. The hives that make up the registry are stored in multiple files in various directories on the system (mainly %SystemRoot%\System32\config). Below is a list of the standard hives and their supporting files, according to Microsoft:

At the root of the registry there are typically five main keys visible in the registry editor, they are as follows:

HKEY_CLASSES_ROOT (HKCR)
HKCR contains data concerning the relationships between applications and other items, such as file type associations. It is essentially a compilation of the classes stored in HKCU and HKLM.

HKEY_CURRENT_USER (HKCU)
HKCU contains configuration data specific to the currently logged in user. The contents of HKCU are just a reflection of the data in HKU relating to the current user profile. As shown in the table above, all of the data in the HKCU hive is stored in a .dat file located in the user’s root folder (typically %SystemDrive%\Documents and Settings\<Username> or %SystemDrive%\Users\<Username> depending on the operating system).

HKEY_LOCAL_MACHINE (HKLM)
HKLM contains settings for all users on the machine, rather than any specific user. As in HKCU, HKLM sorts driver and services information in the SYSTEM key, and configuration for windows and applications in the SOFTWARE key.

HKEY_USERS (HKU)
HKU contains everything in HKCU as well as the same data for every other user on the machine. It also describes the default configuration for new users.

KEY_CURRENT_CONFIG (HKCC)
HKCC contains data relating to the current hardware profile of the machine. Technically, it only contains information describing the difference between the current configuration and the standard configuration, which is stored in the SOFTWARE and SYSTEM keys of HKLM. HKCC is actually just a mirror of the contents in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current.

The Windows Registry cannot be more than 512 levels in depth, and no more than 32 levels can be created at once with a single API call.

Because virtually every Windows setting is stored in the registry, it is the ultimate tool when it comes to system configuration. For more or less the same reason, the registry can also be very dangerous if misused. Incorrect configuration of certain parts of the registry can cause a variety of problems, including rendering the operating system unusable. Centralizing system configuration makes settings more accessible to the operating system. Registry settings can be applied to users en masse via group policy, and the entire registry is relatively simple to back up. Due to the way the registry is stored on the system, storing strongly typed data is possible and parsing data is not necessary as it is with INI files, which results in faster reads. On the other hand, the registry’s binary structure also makes damage much harder to repair.

The easiest way to manipulate the registry is via the Registry Editor, which is a component of Windows. By default, there are no shortcuts to the Registry Editor, so we’re going to have to start it a little differently than most applications.

Open the start menu and click Run. Type regedit and hit enter. We could type the full address to the Registry Editor, but it just so happens that it is stored in the system32 folder, which is where Run looks if an absolute path is not specified. If you’re using Windows Vista or Windows 7, just type regedit in the search box at the bottom of the start menu and hit enter.

At first glance, the Registry Editor looks similar to Explorer. You can navigate through keys using the tree on the left side of the window. Unlike explorer, subkeys won’t be displayed in the list view on the right, so you’ll have to use the tree to move around the registry. The list view shows each value of the current key. As discussed earlier, a value has its own name, type, and data. For the purposes of demonstration, we’re going to edit a value. The change we’re going to make is stopping an application from appearing in the “frequently used programs” list in the start menu (present in Windows XP onwards).

Windows keeps a small list of executables that shouldn’t be included on this list; it keeps this list in the registry of course. The value exists to stop certain system programs and applications that are unlikely to be run more than once from appearing on this list (things like installers and rundll32). Let’s say I want to prevent Windows Media Player from appearing on this list (because I already have it on my Quick Launch bar). This value is located in the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\FileAssociation

The parent keys in the above address basically break down like this:

Settings for the machine (not just this account) >
Settings for software on this machine >
Settings for software manufactured by Microsoft >
Settings for Microsoft Windows >
Settings for the current version of Microsoft Windows >
Settings for explorer (explorer handles the user interface, among other things) >

So use the tree view on the left to navigate to this key. You should see roughly three or four values listed. The one we’re interested in is called AddRemoveApps; it’s a REG_SZ which is essentially a string value (a value that contains data composed of a sequence of characters, usually text of some description).

Double click on AddRemoveApps or you can right click on it and select Modify… from the context menu that appears. You should see a small dialog appear captioned “Edit String”. This is pretty self explanatory; to edit the value data, change the contents of the second text box and click OK. The contents of mine looks like this:

SETUP.EXE;INSTALL.EXE;ISUNINST.EXE;UNWISE.EXE;UNWISE32.EXE;ST5UNST.EXE;RUNDLL32.EXE;MSOOBE.EXE;LNKSTUB.EXE;MSASCUI.EXE

So what we have here is a list of executables separated by semicolons. To add Windows Media Player, jump to the end of the string, add a semicolon, then type the executable name:

SETUP.EXE;INSTALL.EXE;ISUNINST.EXE;UNWISE.EXE;UNWISE32.EXE;ST5UNST.EXE;RUNDLL32.EXE;MSOOBE.EXE;LNKSTUB.EXE;MSASCUI.EXE;WMPLAYER.EXE

You’ll notice I’ve typed wmplayer.exe in upper case; this is just for consistency, it isn’t actually case sensitive. Windows only checks this value when it attempts to add a program to the list, so if Media Player is already on your frequently used programs list, you will have to remove it yourself first (either by clearing the list, or right clicking on it and selecting Remove from This List.).

You can also export entire keys (or the registry itself) into .reg files, which are basically text files with a special syntax which Windows can read. When you open a .reg file, Windows attempts to modify the registry based on the contents of the file. Since this is a potentially dangerous thing to do (especially if you don’t know where the file came from or what its purpose is), Windows will always ask for confirmation before executing a .reg file. If you want to read or edit a .reg file, you can do so with a text editor such as notepad.

Exporting allows you to back up the registry before making changes. In most cases, this isn’t strictly necessary if you’re careful, but it is a good practice to establish. To export a key, simply right click on it and select Export.

Originally published in 2008

On Windows XP and up, it is possible to hide user accounts from both the Welcome Screen and the User Accounts control panel. In this tutorial, I’ll show you how. I’m sure people have various reasons for wanting to do this, so here we go.

The first thing you want to do is head to the Control Panel and create the user you want to hide, if you haven’t done so already. I’m calling mine Secret Account. It’s important to take not of the exact name of the account, including character case, because we’ll need to use it later.

Notice that the account is shown in the User Accounts control panel. This is normal, of course.

If you log out, you’ll notice that the account is also shown on the Welcome Screen. Once again, standard windows behaviour.

In order to tell Windows to hide the account in both the Control Panel and the Welcome Screen, we need to make an edit to the Windows Registry.

To open the registry editor, select Run from the start menu, type regedit and click OK.

Once the Registry Editor opens, browse to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

In this key, you need to create a new DWORD value. Give it the exact name of the user account (case sensitive). In my case, I’m calling it Secret Account. The default value for a new DWORD should be 0×00000000 (0), which is the value we want, as it hides the account. If this is not what your DWORD is set to, change it accordingly.

Once you’re done, close the Registry Editor and the effects should be instantaneous. Head back over to the Control Panel and the affected account should not be visable.

Log out to see the Welcome Screen. You’ll notice the account is no longer visible here either.

In order to log on using the hidden account, you’ll need to press Ctr+Alt+Del twice. You will be prompted with the classic NT log on window.

Input your username (case insensitive) and password (case sensitive), and click OK.

You can also use this method to show the Administrator account on XP, which is hidden by default.

Originally published in 2008

In this tutorial, I’ll discuss disabling and configuring User Account Control (UAC) on Windows Vista, along with the pros and cons of doing so.

User Account Control, or UAC as it’s often called, is arguably the most controversial feature of Windows Vista. It’s also probably fair to say that it’s Vista’s most misunderstood feature.

UAC prompts you with a ‘click-ok-to-continue’-like dialog whenever you do certain actions. This is often interpreted as “Are you sure you want to run this program?” or “Are you an administrator?”, which isn’t quite the case. This prompting behaviour can be jarring for users, as it deviates from the behaviour of previous versions of Windows. Being constantly asked to confirm your actions can be frustrating for users new to the Vista platform. Because of this, many users choose to disable the UAC system all together, and it has become a main point of criticism for Vista.

Before I explain how to configure and disable UAC, let’s discuss briefly what it actually does.

In previous versions of Windows (as late as Windows XP), we had two main types of user accounts: Limited Users and Administrators. Limited Users were restricted in what they could do with windows. Most installations, for instance, required authorization from an Administrator. The same was true for various other tasks, such as installing hardware and making system wide changes to the operating system. Administrator accounts, on the other hand, had virtually full access to Windows.

According to Microsoft, most people prefer to use Administrator accounts. This is primarily due to the default account that is created during Windows Setup being an administrator, and also to the fact that users prefer to have full control over their PC. The main security issue with this approach to user policy is that applications are run with the same privileges that the user has. That is, if the user is an administrator, the application runs with administrative privileges. This makes Windows more vulnerable to malicious software than it should be.

Windows Vista takes a different approach to user security policy by implementing the UAC system.

By default in Vista, all programs run with minimal privileges regardless of the account type the user is set to. Without administrative privileges, it is much more difficult for applications to perform potentially harmful operations. However, some applications do have legitimate use for administrative privileges. The prime example would be setup applications, as they require access to areas such as Program Files and the Windows Registry. When an application attempts to do something that requires administrative privileges, it is detected by UAC.

What UAC actually does is tells the user that the application is requesting admin privileges (and thus, higher access to the operating system). The user can then allow or deny administrative access to the application that made the request by answering the UAC prompt. If administrative privileges are granted by the user, the application retains them until it closes.

This system gives users complete control over what applications the operating system exposes itself to, which makes malware a lot less effective.

When Windows Vista was first released in January of 2007, the amount of UAC prompting for regular programs was higher than what would have been tolerable for many people. This is because a lot of Windows software at the time required administrative privileges unecessarily, due primarily to poor programming by the developers. UAC has, perhaps unintentionally, encouraged developers to rewrite their software to work without triggering UAC prompts, which Microsoft argues results in an “improved software ecosystem”. The amount of programs that trigger UAC

prompts on Windows Vista has dropped approximately 78% between August of 2007 and August of 2008, which is compelling evidence to support Microsoft’s claims.

Regardless of UAC’s beneficial features, many people still find the prompting too intrusive, and turn UAC off as a result. This can be done in the User Accounts section of the control panel, but it’s not a very good idea.

Disabling UAC causes other Windows components to behave differently, which can cause problems here and there. Since it’s only the prompting that’s the issue, it would make more sense to leave UAC on, but turn the prompting off. This can be done.

Windows Vista Ultimate and Windows Vista Business users have access to the Local Security Policy editor, also known as secpol. To run secpol, type secpol.msc in the start menu search box and hit enter (you will be prompted by UAC, go figure).

Under Local Policies > Security Options, there are a whole bunch of settings related to UAC. The two we are interested in are…

UAC elevation prompt settings in the windows Security Policy editor (secpol)

• User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode; and
• User Account Control: Behaviour of the elevation prompt for standard users

To turn UAC prompting off, change these (or the one that suits you) to Elevate without prompting.

Instead of actually turning off UAC, this elevates programs to administrative privileges as soon as they are requested, removing the prompting from the process. This will remove the prompts, but remember, it will not protect you from malware – UAC does not differentiate between good and bad software heuristically or otherwise.

If you’re a Windows Vista Home Basic or Windows Vista Home Premium user, you do not have secpol. However, most of the settings in secpol just correspond to entries in the Windows Registry, including the two UAC settings above.

To change them, open the registry editor (type regedit in the start menu search box and hit enter).

Browse to the following key:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

The prompt settings are stored here as DWORD values. They are ConsentPromptBehaviorAdmin and ConsentPromptBehaviorUser.

The possible values for both settings are as follows:

0×00000000 (0) – Elevate without prompting
0×00000001 (1) – Prompt for credentials
0×00000002 (2) – Prompt for consent