Customizing the WinX menu, and making it user-specific

So here’s (hopefully!) a full, comprehensive guide to tinkering with the right-click Windows WinX menu.

What is the WinX menu?

The WinX, or Win+X (because that’s the keystroke that reveals it), menu arrived in Windows 8.1. It’s a kind of “Power User” menu with shortcuts to various locations for the more administratively-inclined amongst us.

The WinX menu that a user gets depends on what is set in the default or template profile that their user profile is created from. The items on the WinX menu within the standard default user profile have changed from Windows version to Windows version (most notably, the Command Prompt has been replaced by PowerShell, and Control Panel by Settings)

How the WinX menu works

The WinX menu is primarily driven by filesystem entries. The entries that control the WinX menu are found at %LOCALAPPDATA%\Microsoft\Windows\WinX, and are subdivided into folders with names of GroupX (see below).

The colour coding on the next image indicates which group refers to which section of the menu.

With the WinX menu, the numbering of the Group folders runs from bottom to top – so Group1 folder goes at the bottom of the menu, Group3 at the top.

Now, you will notice in that image that there are a few shortcuts in the Group3 folder that don’t actually appear on the WinX menu – namely the two Command Prompt shortcuts, and the Windows Mobility Centre one. This is because you can control which shortcuts appear from these folders by a hash value, and the hashes on these shortcuts have been made invalid. We will talk more about this in a little while.

Another thing to notice is – how do the shortcuts order themselves on the WinX menu? Apps and Features is at the top on the WinX menu but does not appear first in the filesystem entries. Also, note that the shortcut called Apps and Features on the WinX menu appears to actually be called Programs and Features in the filesystem folder? How is this done?

The control of the display names and the ordering on the WinX menu is to do with the hidden desktop.ini files in each of the GroupX subfolders. Rather than write about this, here’s a very quick video showing (hopefully) how the desktop.ini files manipulate this.

So, we can now see how this hangs together – to some degree, anyway 🙂

Customizing the WinX menu

Now, customizing the WinX menu is a little tricky. You’re probably thinking, I can just utilize the filesystem and customize the folders according to what you want on the WinX menu by removing and adding shortcuts to programs, yeah?

Wrong.

To be fair, Microsoft don’t really want to make it that easy – imagine if every application you installed plonked itself into the WinX menu. It could get nasty.

But you can’t even edit the existing shortcuts. I tried to subvert this by changing the properties of one of the pre-populated shortcuts and pointing it somewhere else. Now initially it worked – but as soon as the user logged off or Explorer was restarted, the changed shortcut disappeared. Here’s another quick video showing this part.

Digging into the issue, it is clear that these shortcuts, as I alluded to earlier, aren’t just populated there by being in the folders. The reason that the Command Prompt shortcuts from the Group3 folder stay hidden is because of this process. I can’t claim the credit for uncovering all of this – that belongs to Rafael Rivera. Here’s an excerpt from Rafael’s excellent blog on the subject:-

An approved shortcut…is a .lnk file that has the appropriate markings to indicate to Windows “Hey, I’m special.” The marking is a simple 4-byte hash of several pieces of information. From the .lnk itself, two points are collected:

The link’s target application path/file (e.g. C:\Games\Minecraft.exe)
The link’s target application arguments (e.g. –windowed)

The third ingredient is simply a hard-coded chunk of text, or a salt if you will, to keep things interesting. That string is, literally, “Do not prehash links. This should only be done by the user.”

With these three strings in hand, Windows then glues them together, lowercases everything, and runs them through the HashData function. But you’re probably wondering at this point, what does it compare to?

Let’s shift our focus to .lnk files. We know them as shortcuts to things. But they’re officially called Shell Links and can store a lot of information on other data objects in Windows. More specifically, they support storing a structure of data called a PropertyStoreDataBlock that acts as a container for arbitrary string or numeric key/value pairs. Yep, the “WinX hash” is stored in here. If you’re curious, the key can be defined as such:

DEFINE_PROPERTYKEY(PKEY_WINX_HASH, 0xFB8D2D7B, 0x90D1, 0x4E34, 0xBF, 0×60, 0x6E, 0xAC, 0×09, 0×92, 0x2B, 0xBF, 0×02);

So to tie it all together, Windows – the Shell specifically – iterates through the .lnk files in each GroupN folder; opens them up; pulls out and concatenates the target path, args, and an arbitrary string; then finally hashes the result. This hash is then compared with the one stored in the .lnk to determine if it’s approved. Rinse and repeat.

If you find that a bit TL:DR, Windows basically hashes the shortcut file and stores the hash inside the shortcut file itself as metadata. So if we want shortcuts within those WinX folders to appear on the WinX menu, they have to match the hash stored in the shortcut file. If we edit an existing shortcut or create a new one, the hash doesn’t match and the shortcut disappears next time the user logs in or the shell restarts.

So how do we get the files correctly hashed so we can load them into our WinX folders and have them appear?

Rafael’s blog also mentions a tool he has created that can perform this hashing for you so you can create your own “approved” shortcuts. It’s available on GitHub, or you can download it from my DropBox here.

Creating approved shortcuts

Firstly, get the tool and unpack it so you have hashlnk.exe somewhere you can use it from the command line.

Next, create the shortcut you want to add to the WinX menu and save it somewhere.

Next, hash the shortcut with the following (very simple) command syntax

hashlnk sourceshortcut

The next short video here shows how to do this part:-

One interesting thing to note is that if I try and create the hashed file from a Windows 10 machine I get a dll error. However you can run it on downstream Windows versions (I did it on 8.1) and then use them on Windows 10 without issue. If you don’t have any choice but to use Windows 10, then you may want to look into installing or reinstalling the various Visual C++ redistributable packages.

So now we’ve created a shortcut we can use, how do we then insert it into our WinX menu? This next video shows how we can put shortcuts into different areas:-

If you do want to order things in particular ways but don’t want to have numbers and prefixes displayed on the WinX menu, a quick and easy way to get around this is actually to use the “Comment” field on the shortcut properties. Rename the shortcut to fit its ordering (so change it to 01d – My Shortcut.lnk or whatever you need to do to place it correctly), and then put in the Comment field what you want to use as the display name on the WinX menu – nice and easy and no messing with the desktop.ini file 🙂

So now you have a way to create and order customized WinX menus! That’s all great. At this point, a lot of people simply copy this into their default profile area (so every new user gets it) and simply leave it at that. However, that can get slightly frustrating because each user (including admins) will have the same WinX menu. How can we split it out for multiple user groups on the same image?

Multiple user functionality

Firstly, obviously you need to create all your hashed shortcuts. Once this step is done, you can then deploy them out to your users.

Group Policy Preferences

You can easily use GPP to achieve this by copying the hashed files into the user’s folders in their profile as they log on. As long as it is done before the shell starts (and user GPO processing is done before the shell launch), it will work fine. Here’s a quick video showing the setup:-

FSLogix Redirection?

I did think that we might be able to do this with an FSLogix Redirection rule, by redirecting %SystemDrive%\Users\*\AppData\Local\Microsoft\Windows\WinX to another location with a new set of hashed shortcuts in. However, while this does what we are asking it to (as in the redirection is performed correctly), the WinX menu is unable to function in this configuration – it simply does not respond when clicked. I’d be interested as to what Microsoft might say about this – it’s the first time I’ve seen FSLogix fail in something I’ve thrown at it.

If you did want to use FSLogix to achieve this, you would have to set up multiple default profiles and add the required WinX hashed shortcuts into those, then direct specific users and groups via the redirection rules to these default profiles. Here’s a previous article of mine discussing this.

So, in my eyes it’s probably easiest to simply do this using GPP – although you could use many bits of tech to do this, all you have to do is make sure those files are properly hashed and in the right folders when the shell starts, and they will be processed. But just one more thing – could we potentially allow users to customize the WinX menu themselves?

Allowing user customizations

The only way I can currently see to do this is by using third-party software. There was a guide that suggested making some hex edits to the twinui.dll file, but I can confirm this no longer works on the latest version of Windows 10.

You can download WinX Menu Editor from WinAero. Once you’ve installed it and provided a shortcut, the user can then use the interface to add shortcuts and groups to the menu, and then re-order them as required.

Summary

So that’s a (slightly updated) guide to messing about with your WinX menu, and hopefully a “final word” for the questions and comments I often get about this.