Welcome to the first of several posts that describe some of the inner workings of the Windows Console.

This post was written by Craig Loewen (our awesome 2017 summer intern), and Paul Campbell (SDE on Windows Console, Cmd, & Bash on Windows).

Settings in the Windows Console Host can be a bit tricky to understand. This is mostly because the settings system evolved over the course of decades. Settings are persisted to/from a variety of locations depending on how the Windows Console Host was invoked.

The hierarchy of loaded settings

Where a Console’s settings are loaded-from and/or persisted-to is decided upon based upon the following hierarchy:

1. Hardcoded settings in conhostv2.dll
2. User’s configured Console defaults, stored as values in ‘HKCU\Console’
3. Per-Console-application registry settings, stored as sub-keys of ‘HKCU\Console\‘ using one of two sub-key names:
   • Console application path (replacing ‘\’ with ‘_’)
   • Console title
4. Windows shortcut (.lnk) files

When Console applications are launched, the Windows Console Host determines which settings to use by loading the Console details, and overlaying settings from the hierarchy in order. Each setting will take on the value of whatever is loaded last, and so values in a Windows shortcut (#4) will override values set in the user’s configured defaults (#2).

This hierarchy explains why each Console window has a ‘Defaults’ option and a ‘Properties’ option inside of its title bar menu:

When modifying ‘Defaults’, changes are written to the User’s configured defaults, stored as values in ‘HKCU\Console’, (#2 in the hierarchy above).

When modifying ‘Properties’, changes will be persisted to either the per-Console-application settings in the registry, or to the Windows shortcut file:

• If the application was launched directly (e.g. via the Windows run dialog), changes will be persisted in the per-application storage location mentioned above (#3 in the hierarchy).
• If the application was launched via a Windows shortcut file, changes will be persisted directly into the .lnk file (the fourth item in the hierarchy). For Console applications with a shortcut, you can also right-click on the shortcut file itself and choose ‘Properties’ to access the settings dialog.

When Console applications are launched, the Windows Console Host determines which settings to use by overlaying settings from the hierarchy in order, starting with the hardcoded defaults. This means that a Windows Console shortcut with settings information inside of it will override the application storage and default settings.

Note that the registry settings are “sparse”, meaning that if a setting isn’t present, then whatever value that is already in use remains unchanged. This allows users to have some settings shared amongst all Console applications and other settings be specific.

Shortcut files, however, store each setting regardless of whether it was a default setting or not. Settings are stored in shortcuts as opaque blobs of data.

Here’s a full list of every setting for the Windows Console, including a quick description on what it does.

*Only applies to the improved version of the Windows Console Host

Known Issues

As with most complex things, there are a few gotcha’s to be aware of:

Settings get reset on OS upgrade

Whenever you upgrade to a new version of Windows, system-owned shortcuts and/or Start Menu items’ settings are reset to defaults. This means that if you customize default fonts, colors, etc., when you upgrade to a new OS build, your settings will be reset to Windows defaults.

While there are several ways in which you can set things back to your own defaults after each upgrade, most of them involve updating the registry (which should always be done with care), and most don’t handle updating shortcuts/links at all.

We’re working on a tool to make handling Console settings easier and more manageable. We’ll announce this tool here, so be sure to visit this blog regularly to be among the first to use this tool when it is released.