Finding the local computer's machine account SID

The Get-ADComputer cmdlet, I hear, can get the SID of a computer's Active Directory machine account. But because it contacts Active Directory to look up the account, it won't work if not connected to the domain. If you have administrative privileges on the computer, you can elevate to SYSTEM (e.g. with PsExec) and get the computer's machine account SID from the default value in this Registry key:

HKLM\SECURITY\Policy\PolMachineAccountS

It's in binary SID format and so may be tricky to read by eye. If you just need the RID, that's the last four bytes, or you can get it as the only contents of the sister key PolMachineAccountR.

Setting an arbitrarily precise mouse sensitivity

The Mouse Properties dialog has a slider with discrete tick marks for setting the mouse sensitivity. The MouseSensitivity value in HKCU\Control Panel\Mouse has twice the resolution but is still an integer, with a range from 1 to 20. The mapping of that number to sensitivity multiplier is tabulated here.

It is possible to set an arbitrarily precise sensitivity scale by taking advantage of the SmoothMouseXCurve and SmoothMouseYCurve values, which are consulted when "enhance pointer precision" is on. These are explained in great depth in this article, but in summary they are a set of points that describe a piecewise linear function of physical mouse speed to pointer speed. If the curve is changed to a straight line, the fancy pointer-precision-enhancing effect is disabled: a mouse movement's distance alone, not speed, determines the pointer movement distance. Since the curve points are 16.16 fixed-point values, there are far more than 20 options for the slope. Starting from a curve equivalent to the default sixth tick (provided by this site)...

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Control Panel\Mouse]
"SmoothMouseXCurve"=hex:\
    00,00,00,00,00,00,00,00,\
    C0,CC,0C,00,00,00,00,00,\
    80,99,19,00,00,00,00,00,\
    40,66,26,00,00,00,00,00,\
    00,33,33,00,00,00,00,00
"SmoothMouseYCurve"=hex:\
    00,00,00,00,00,00,00,00,\
    00,00,38,00,00,00,00,00,\
    00,00,70,00,00,00,00,00,\
    00,00,A8,00,00,00,00,00,\
    00,00,E0,00,00,00,00,00

...all Y values can be multiplied or all X values can be divided by the sensitivity multiplier of choice. Only the first 4 bytes of each line matter, and they're in little-endian. A logoff/logon cycle may be necessary for the change to take effect.

Based on my Super User answer.

The Classes branch is in another hive

HKEY_CURRENT_USER contains several subkeys, but not all of them are stored in same Registry hive file. As expected, most are from ntuser.dat in the root of the user profile, but the Classes subtree gets a hive to itself. It's stored in AppData\Local\Microsoft\Windows\UsrClass.dat. Interestingly, that file doesn't exist under the default user profile. It appears that the classes hive is initialized empty when profiles are created.

Putting items in the New context menu above the separator line

One user wanted to put a custom New submenu entry above the separator line (right under Folder and Shortcut) instead of among the normal entries. At first I assumed this was impossible and that the above-separator entries were hardcoded, but then I did some disassembling.

shell32.dll has a CNewMenu::_BeforeSeparator function that determines whether a given entry will be placed above the separator. It first checks the file type against a hardcoded list, but if that check fails, it also checks a flag in the NEWOBJECTINFO structure. It looks like those structures are set up by the _GetNewObjectInfoForKey structure, which calls _GetConfigFlags on the Config subkey of ShellNew to populate the field containing that flag. _GetConfigFlags checks for the existence of a bunch of entries, setting flags as it goes along. The Registry entry for the flag of interest is named BeforeSeparator.

So, placing a value named BeforeSeparator in the Config subkey under ShellNew for a New menu item will move that menu entry above the separator:

Setting the hotkey for context menu items created with the Registry

One user was experimenting with creating file context menu entries with the Registry and encountered some interesting behavior about the hotkeys for activating them with the keyboard. If multiple entries have the same hotkey (shown with the underline under a letter), pressing that letter cycles the focus through them; if the hotkey is unique, pressing it immediately activates the corresponding entry.

The hotkey for a custom entry can be set by putting an ampersand before an instance of the desired hotkey letter. Interestingly, for that to work properly, the entry's name has to be set in the default value of the entry's Registry key, not just with the key name. If an ampersand is included in the key name, the hotkey letter will be underlined, but pressing the key will do nothing.

Adding the Backup Operators group to a Home edition

Home editions of Windows have fewer built-in groups than Pro editions. Some of those missing groups, however, still have their SID appear in various default ACLs and privilege lists. One such group is Backup Operators.

Creating a new group with the same name as a missing built-in group won't have any effect because the SID will be different. There is also no way to specify the SID of a new security principal... without editing the SAM database in the Registry. To access the SAM of a live system, we need to open the Registry Editor as the SYSTEM account. That can be accomplished with PsExec:

psexec -s -i regedit

Information on built-in groups is stored under this key:

HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Builtin\Aliases

It has one subkey for each group. The subkey names are the zero-padded eight-digit hexadecimal representation of the last fragment of the group's SID. The Backup Operators SID is S-1-5-32-551, so its subkey is 00000227. The Aliases subkey also has a Names subkey, which likewise has a subkey for each built-in group. This time, the subkey names are the group names. The default value of each name subkey is an empty binary value - what matters is the type code of the default value, which stores the last SID fragment.

Both keys are necessary for the group to work properly. They can be exported from a Windows installation that has a desired group and imported into one that doesn't. The group will appear after a reboot.

DCOM configuration permissions are Registry key permissions

The DCOM Configuration section of the Component Services snap-in allows modifying the permissions of COM applications. The ability to change the permissions on the Security tab is governed by the ACL in the Configuration Permissions section. Even going into the Advanced dialog on the ACL editor, though, doesn't allow administrative ownership-taking, so even administrators can't always adjust the permissions.

The Configuration Permissions are actually the permissions on the Registry key describing the COM application:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{GUID}

The GUID is the application ID from the General tab of the application's properties window. The Advanced ACL editor in the Registry Editor can be used to take ownership and adjust configuration permissions. After a reboot, the DCOM Configuration snap-in can be used to graphically adjust Launch and Activation or Access permissions.

Guessing the type of an absent Registry value from Process Monitor logs

One user was trying to use Process Monitor to figure out what a program is looking for in the Registry. The relevant value was not present, so the RegQueryValue operation's result was NAME NOT FOUND. When the query is successful, Process Monitor reports the data type, but it does not when the value is not found. This is because the API call used to query the Registry does not take the desired data type - the Registry just stores chunks of data for the application to interpret. When a value is found, the Registry returns its kind, but if the value isn't there, there's no kind to report.

There is one piece of information that can allow a guess to be made about the value type (in some cases). Applications need to pass in a buffer for the returned data and the buffer's length. Process Monitor reports a "length" even for unsuccessful Registry queries, but (at least on 64-bit systems), its number is 12 bytes more than the application supplied. So subtracting 12 from the "length" gives the size the application is expecting for the results. A DWord occupies 4 bytes and a QWord occupies 8 bytes. All the other kinds (mostly strings) are variable-length.

Not all context menu items are directly in the Registry

One user wanted to find the command line equivalent of context menu items. This is straightforward for items that are configured in the Registry to launch a process with arguments (in the command subkey under a subkey of shell, which is a subkey of a file type key in HKEY_CLASSES_ROOT). However, some context menu items are actually created at runtime by shell extensions or the shell itself. Context-menu-affecting shell extensions are listed in the ContextMenuHandlers subkey under shellex. Of course, those are COM objects that can do anything they want in response to the menu item being clicked, so there's no simple way to invoke their functionality from the command line. One strategy is to use Process Explorer to see the command line of any new processes that result from clicking the item.

Modern Windows apps can be launched by protocol

Today I stumbled upon the fact that even simple, non-Internetty modern/Metro Windows apps can be associated with URI protocols. For example, the Calculator will come up if you run calculator:// from the Run dialog - or even from Chrome's address bar.

You can explore protocol registrations in the Registry under this key:

HKEY_CLASSES_ROOT\Extensions\ContractId\Windows.Protocol\PackageId

Each application's subkey has an ActivatableClassId, which contains one subkey for each protocol. The protocol name is stored in the Name value of the CustomProperties subkey.

Adding custom Visual Effects performance options to the Performance Options dialog

The Performance Options dialog (accessible from the Advanced tab of the System Properties dialog) loads the list of visual effects from the Registry, specifically from here:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects

Each subkey is one option in the dialog. It's possible and fairly simple to add new entries. Most of the default ones use the SPIActionGet and SPIActionSet values to specify the uiAction parameter to SystemParametersInfo. A couple, however, are backed by Registry values, so new checkboxes can be added to control Registry values elsewhere.

These values are necessary to define a Registry-backed checkbox:

• HKeyRoot, a DWord that specifies the common Registry handle to use as a root. This should probably be 0x80000001 (for HKCU).
• RegPath, a string specifying the key path under the root hive.
• ValueName, a string specifying the name of the value in the specified key to control with the setting.
• CheckedValue, a DWord containing the data to set into the specified value when the box is checked.
• UncheckedValue, likewise if the box is unchecked.
• DefaultValue, a DWord with the default data for the backing Registry value if it does not exist.
• Type, a string set to checkbox.
• Text, a string holding the display name of the setting. This can be the literal setting title or, if it starts with @, a resource from a DLL.

Configuration for a new setting

The resulting setting

Checking and unchecking that box does indeed set the corresponding Registry value.

What does the SuperHidden Registry value control?

There is a value called SuperHidden under this Registry key on some versions of Windows:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

It's reminiscent of Hidden (which controls whether the user sees hidden files in Explorer listings) and ShowSuperHidden (which controls whether the user sees system files in those listings). One might wonder what SuperHidden controls.

And the answer is... nothing! Using Process Monitor, I observed I/O to it and found that it only gets written when the View tab of Folder Options is shown. It's never read, even when Explorer is starting, so it can't control anything. So why is it there?

Investigating the stack provided by Process Monitor led me to shell32.dll, which issues a write to that value in CachedShellState::SaveAdvancedSettings. The corresponding function CachedShellState::_GetAdvancedSettings, however, issues a read from ShowSuperHidden, the value that actually does something. I also noticed that on Windows 10, the inert SuperHidden doesn't exist, and sure enough the Windows 10 version of shell32.dll writes to ShowSuperHidden.

Therefore, I strongly suspect that the existence of SuperHidden was a typo that was later corrected.

Based on my Super User answer.

Access control lists for power configuration

Changes to power settings are written through the cooperation of the Power service. That service, like most, runs as SYSTEM, so there has to be some other means of access control than just normal Registry key ACLs. And sure enough, there is in this key:

HKLM\SYSTEM\CurrentControlSet\Control\Power\SecurityDescriptors

Each value appears to be the GUID of a setting type. "Default" likely applies to all the other operations The data is the ACL in SDDL format. The specific permissions available are Registry permissions (KR for read, KW for write, KA for all). Changes to these ACLs require a reboot to take effect.

Registry data types are just labels

If you poke around the Registry Editor enough, you might find some values of the Data column that say something like "invalid DWORD (32-bit) value." This happens when the data held in that value is not the right length for the supposed data type. DWORDs should be 4 bytes long, but there's nothing stopping them from being anything else. The function responsible for setting values, RegSetValueEx, takes a data length and pointer to the data. To view and edit these entries of unusual length, double-click them in the Registry Editor to open the binary data editing window.

The Windows CloudStore

Windows stores some desktop/shell-related settings in this Registry section:

HKCU\Software\Microsoft\Windows\CurrentVersion\CloudStore\Store\Cache\DefaultAccount

Each subkey is one setting. After the first dollar sign in the subkey name is a GUID for the object, or nothing if there can be only one of that type. After the second dollar sign is the object's type. For example, there are tons of windows.data.curatedtilecollection.tile but only one windows.data.bluelightreduction.settings. Inside that key is a Current subkey, which has a single value: Data, of the binary type.

It appers that the first four bytes of that data are always 02 00 00 00, perhaps a version signature. Then the next eight bytes are the last-modified time as a FILETIME. Then there are four more zero bytes. After that, it gets into type-specific data, which I have not yet managed to figure out.

Configuring blue light reduction settings with PowerShell

Windows 10 1703 introduces the "night light" feature, also known as blue light reduction. Its settings are stored in the Registry, but it's a binary blob under CloudStore, rather difficult to manipulate. One user was interested in automating the setting in some way. They already found this GitHub script that sets some values, but it only supports a handful of predefined configurations. So I took a look.

Wild speculation brought me to the SettingsHandlers_Display.dll file, which I suspect is responsible for the relevant part of the Settings app. I got a hold of a 32-bit version so IDA could disassemble it, but it appears to be written in C++ and so is a huge mess to reverse engineer. There seems to be COM involved as well, and though IDA mentions some class names and even some structs' members' names, I couldn't figure out where the saving/loading took place. Looking for struct definitions to get some ideas on the blob's layout, I acquired the PDB file for the DLL, but couldn't accomplish anything with it.

So I was back to plain old pattern recognition. One run of bytes changed every time I edited the blue light settings, no matter what control I altered, and I deduced that to be a FILETIME indicating the store entry's last-modified time. Flipping some switches caused the blob to grow in size, which was puzzling, but most changes just replaced one or two bytes - at least those were easy to track down. It was in that way that I figured out where the color temperature slider's state was kept. The actual numeric value that it changed, though, did not make sense. Changing the Registry value in certain slight ways inexplicably jammed the slider against one end of the other. It didn't help that I didn't know what value the bytes were serializing from the slider.

Use of the Inspect tool revealed the numeric value of the slider. Like f.lux, it remembers color temperature in Kelvin. Some seriously bizarre binary math goes on in the serialization. Nevertheless, I figured out the formula. And though I don't quite have a handle on why the blob expands and contracts, my script works consistently. Interestingly, some of the UI elements in the Settings app immediately update when the script is run.

The script itself is in my Super User answer.

Improvements to regedit in Windows 10 1703

The Creators Update (1703) to Windows 10 includes a little-publicized but very welcome improvement. The Registry Editor now has two extra Explorer-like features, and one new advanced feature.

An address bar (replacing the status bar) shows the current full path, and allows copying. A path can be typed or pasted to navigate quickly, which will be excellent for people following Internet guides.

Second, there's now a Favorites feature. A key can be added to the favorites list, where it shows up under the Favorites menu. These locations can be managed with Favorites | Remove Favorite.

It also introduces the View | Display Binary Data option. Clicking that menu item opens the current value's data as the raw bytes. Relatedly, there's a new Modify Binary Data entry on the value context menu that allows editing that data, like the binary data editor from the past, but with more convenient selection ability.

services.msc might not show the effective state if Registry tweaking is in play

A user had written a script to tweak the Registry in a way that changes a service's start type to Manual. When they tried to start it, though, net gave the spiel about it being disabled (or one of its required devices being disabled). The Services MMC snap-in reported the new start type, so it looked like the Registry change did the job.

I did some investigation and found that a once-disabled now-enabled service won't actually start unless it's reconfigured the supported way. services.msc somehow knows about the Registry-tweaked state, but the Service Control Manager isn't fully in on the joke. Since the question author was writing a batch script, sc does the job.

Some file associations are not controlled by the usual place

Yesterday, I mentioned that file associations are managed by data accessible under HKEY_CLASSES_ROOT. A few extensions, though, get special treatment because programs really liked to mess with them instead of letting the user choose. Those can be found here:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts

Protected types have a UserChoice subkey with the file type ID and a hash. The hash is likely there to throw another roadblock up against developers of would-be poorly behaved applications.

On my main machine, the usual file association Registry entries associate .html with htmlfile (Internet Explorer), but the UserChoice subkey provides the real value: ChromeHTML.

Device installation restrictions only work on not-yet-installed devices

I was helping someone tweak the Registry to configure device installation restrictions and we hit a snag. Even though the Registry settings were exactly as they should have been, the restricted devices were not disallowed, even on Pro editions where the Group Policy infrastructure is definitely there.

Eventually I found this Microsoft guide that mentions that devices should be uninstalled for these restrictions to work reliably. As the question author discovered, the devices' drivers don't have to be removed, but the devices themselves definitely should. The restrictions only take effect at install time, not plug-in time.