Issues with RegKey in Powershell

Question

I'm having trouble with a Registry Key in Powershell.

The key /T/E/S/T gets generated by an unknown process:

I then try to overwrite it using:

$Path = ".\setting\grouplocators"
$Name = "/T/E/S/T"
New-Item -Path $Path -Name $Name -Force

But it just creates a bunch of sub-folders

I have no issue when using cmd:

reg add ".\grouplocators\/T/E/S/T"

How can I get PowerShell to create the key with the name /T/E/S/T ?

Answer 1

Up to at least PowerShell 7.2.3, PowerShell's registry provider - unfortunately - treats \ and / interchangeably as path separators, despite the fact that / is a legitimate character in a registry key's name - see GitHub issue #5536.

As a result, it interprets a / as separating two keys instead of considering it a part of a single key's name.

Workarounds:

To create a registry key with / in its name:

Use the .CreateSubKey() .NET API, directly via the static properties of the [Microsoft.Win32.Registry] type that provide access to the various hives (.NET Framework 4+):

The following example creates a key in the HKCU: (HKEY_CURRENT_USER) hive, namely HKEY_CURRENT_USER\temp\sub\A/B:

[Microsoft.Win32.Registry]::CurrentUser.CreateSubKey(
  'temp\sub\A/B'
).Close()

• To target HKLM: / HKEY_LOCAL_MACHINE instead - which requires elevation (running as admin) - use [Microsoft.Win32.Registry]::LocalMachine.CreateSubKey()

• Intermediate keys are created automatically, as needed - if the target key already exists, the call is a quiet no-op.

• The path must not start with \

---

To query a registry key with / in its name:

While you could similarly use .NET APIs to query such keys, there are workarounds if you want to stick with PowerShell cmdlets:

The most robust approach is to target the parent key with Get-ChildItem and then filter by child key name with Where-Object:

Get-ChildItem HKCU:\temp\sub | Where-Object PSChildName -eq 'A/B'

• Caveats:
  • If key names start with / (as in your /T/E/S/T example):
    • The .PSChildName property value then unexpectedly contains the name without the initial / - so that you'd have to use the very same command as above to test for key HKEY_CURRENT_USER\temp\sub\/A/B.
    • Using wildcards with the parent path (HKCU:\temp\sub\*) then malfunctions altogether (reports a spurious error about a nonexistent key), both with Get-ChildItem and Get-Item.
  • Even with without an initial /, using wildcards with the parent path malfunctions with Get-ChildItem when combined with -Include (no output), but curiously not with Get-Item.

Curiously, however, Test-Path, does properly recognize / as part of the key name when testing the existence of a registry path:

Test-Path HKCU:\temp\sub\A/B    # OK: -> $true

• Caveat: If key names start with /, Test-Path does not find the key, and there is seemingly no way to make it work.