Fix Open Registry actions on non-English Windows (#11)

[Mike-Crowley]

Fixes #11.

Root cause

regedit.exe resolves the LastKey value it reads at startup against the localized name of its tree root node. That name is a string resource in regedit.exe.mui, not a constant in regedit.exe:

> strings C:\Windows\en-US\regedit.exe.mui | findstr Computer
Computer
My Computer

Every Helper.OpenRegistry() call site hard coded the English Computer\ prefix. On a Windows whose display language is not English the first path segment does not match (the reporter's fr-FR machine shows Ordinateur), so regedit discards the whole path and opens at the root node instead of the requested key. That is exactly the reported symptom: "it only opens the registry but not the selected location".

Verified repro

Tested on Windows 11 Enterprise 26200, en-US, by writing candidate values to HKCU\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit\LastKey, starting regedit and reading back its address bar text:

LastKey written	regedit address bar
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	navigates
Ordinateur\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	Computer	falls back to root
Zzzz\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	Computer	falls back to root (control)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	navigates
HKLM\SOFTWARE\Microsoft\Provisioning	Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning	navigates

Row 2 is the mirror image of what a French user sees today, and it reproduces the bug on an English machine. Row 3 confirms the root segment really is validated. Rows 4 and 5 show the fix.

Fix

Rather than trying to detect the localized root name (it would have to be pulled out of regedit.exe.mui by an undocumented resource id), the prefix is simply dropped. regedit accepts a LastKey with no root node prefix and prepends the correct localized name itself, so the resulting path is language independent by construction.

• New Helper.NormalizeRegistryPath() strips a leading root node segment unless the path already starts at a hive (HKEY_*, HKLM, HKCU, ...). Keeping it in Helper means a path pasted with any root name, localized or not, still resolves.
• Dropped the hard coded Computer\ from all 8 Helper.OpenRegistry() call sites in MainWindow.xaml.cs, including the interpolated NodeCache path.

Also switched the Applets\Regedit key from OpenSubKey to CreateSubKey. That key does not exist yet on a profile where regedit has never been started, and registryKey?.SetValue(...) silently did nothing in that case, which is the same user visible failure.

Second part of the issue

Added -> Device Inventory Agent folder to the Open Folder menu. It uses %ProgramW6432% with a fallback to SpecialFolder.ProgramFiles, so it resolves to the native Program Files even if the app ever runs 32-bit, and it inherits the existing "folder does not exist" message box from Helper.OpenFolder().

Testing

• Unit tested NormalizeRegistryPath against 21 cases: English and localized prefixes, My Computer, already-normalized paths, lowercase hive names, short HKLM form, a subkey literally named HKEY_LOCAL_MACHINE, the NodeCache path with the space in MS DM Server, plus null, empty, whitespace, leading and trailing backslashes. All pass.
• End to end: fed the post-fix path of each of the 7 static call sites through NormalizeRegistryPath into LastKey, launched regedit, and confirmed via the address bar that it landed on the exact key. 7/7 pass. The NodeCache call site was verified the same way against an equivalent key shape created under HKCU, since ...\NodeCache\CSP\Device\MS DM Server\Nodes\1 does not exist on the test device.
• No full solution build: the test machine has no .NET SDK, no Visual Studio and no MSBuild able to build a .NET Framework 4.7.2 WPF project with packages.config, so the changed code was compiled and exercised in isolation with Roslyn instead. Worth a normal build before merging. The XAML was checked for well-formedness and every Click handler was confirmed to have a matching code-behind method.

Only behaviour change for English users: none, the resulting regedit navigation is identical.

🤖 Generated with Claude Code