I was going into my registry to add a command prompt shortcut to folders when I found there was already one there, looking like the following:


@="cmd.exe /s /k pushd \"%V\""

However, the entry was not showing on my context menu when I right clicked. The only thing that makes sense to me is the HideBasedOnVelocityId key as keeping it from being displayed. Anyone know why? Is there a dword value I should put in to allow it to work?

  • 1
    I wish it was know how to set the "VelocityID" to toggle this. I assume they originally meant to add a setting like for the Win+X menu where you can choose to have Cmd or PowerShell show up but never added it.
    – thaimin
    Jun 5, 2017 at 14:36

2 Answers 2


Change the HideBasedOnVelocityId to ShowBasedOnVelocityId to enable the command prompt entry again.

enter image description here

Microsoft is doing this to replace cmd.exe with Powershell

  • 8
    If Regedit tells you that you have no permissions to perform the changes then right click on the cmd / powershell key (folder icon), select permissions..., select advanced, in the "owner" section the owner should be the "TrustedInstaller", click "change..." there and set the administrators group as owner. Click OK, OK. Finally back in the permissions window select the administrators group and give them "full" permissions. Now you should be able to change those keys.
    – omni
    Apr 14, 2017 at 14:35
  • 2
    As for changing the ownership of the key, that is indeed needed to make this change. But we should wonder what implications there may be, long-term, when the "trustedinstaller" is now no longer the owner. I suspect at some point a Windows update may try to tweak this key and be unable. While some would call that good news ("Windows can keep their damn hands off it"), they should then just keep in mind that if something later acts odd due to this that it may be more their own fault rather than a "windows bug". Oct 22, 2018 at 16:58
  • 2
    I was able to just create my own CommandPromptHere key, and leave the original alone
    – Michael
    Apr 17, 2019 at 0:33
  • 2
    To @charliearehart's point about the long term effects of changing the owner away from TrustedInstaller, a better process is to do as masi suggests, but then change it back. Remove the Full permissions from the Administrators group, then change the owner back to "NT SERVICE\TrustedInstaller" (be sure to set "From this location" to the local PC if you're joined to a domain). Then you have left it as you found it. Oct 20, 2020 at 14:39
  • @charliearehart There will be no problems with this, as OS actually does not care at all who is the owner of file/folder/key. The only thing that matters is that the TrustedInstaller still have full read/write premissions to the key. I once did one very silly thing, to remove all the access to 1 key from SYSTEM and everything else except my account. Well, guess what, the key was lost permanently. I couldn't open the key vie RegEdit, I couldn't restore the permissions. Even regIni script didn't help. I got lucky that it was not super important key, and it had backup in WOW64... Aug 15, 2022 at 16:47

I'm not sure if you fine folks have quashed this. There isn't an update on this question in the last year. However, it's not the "Name" of the key that is wielding the power (in this case).

Did anyone notice the Key's value?

I'm currently running build 17025 and it's 639bc8 (hexadecimal) or 6527944 (decimal). Unless you have a bit of background in hexadecimal editing or debugging code, I won't be able to speak at ANY level where the values become clear. That said, Robert Clemenzi has a page that gives examples of other flags, their values they are usually found to be set to, and what it means. While he didn't directly speak about HideBasedOnVelocityId, his page does address this question. Once you think you have gained understanding, please continue to read on, where he then explains that values can be combined and the final result is no longer 01 00 00 1, but expressed in HEX to "Disable file type editing" or "Disable the Details tab". Such as my value above for HideBasedOnVelocityId, which I expressed both ways it can be read. The Key Name itself, many times is a place holder that covers a "group" of attributes, and it's the value that essentially has all the attributes. HEX simplifies all the 4 bit entries into 1 lump sum (for us), instead of 8 characters per attribute. These are 32-bit DWORDS. I've not seen a 64-bit DWORD for Flags yet (I can't imagine needing that much memory space to hold a setting value); maybe next build! From our stand point, we want to achieve on or off. However, from your machine's standpoint, it means a bit more to do. At least with this question, if you aren't familiar with HEX, when you encounter flags with simple 4 bit values of 1's and 0's and others in HEX, you will know now, that a key's values may have many attributes than simply a binary value of on or off. But in some cases, just a Key with no value or adding a key with no value is enough to have an effect, as we know.

This is his page for reference.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .