为何程序无法识别已存在的Word版本注册表项？

Let's break down the most common reasons your code is returning false for those registry paths—even when you can see the keys in Registry Editor—along with actionable fixes you can try right away.

1. You're Missing Administrator Privileges #

Accessing keys under HKEY_LOCAL_MACHINE (HKLM) often requires admin rights, even just to read them. Windows locks down parts of HKLM to prevent accidental or unauthorized changes, so your regular user account might not have permission to open that InstallRoot subkey.

How to test:
Right-click your application executable and select "Run as administrator." If the logs start showing true for the 16.0 path, that's your issue.

Permanent fix:
Add an application manifest to your project to force admin rights on launch:

• Right-click your project in Visual Studio > Add > New Item > Search for "Application Manifest File."
• Open the manifest and find the <requestedExecutionLevel> line. Change it to:

  <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
  

  This will prompt users for admin permission every time the app runs, which is necessary for reliable HKLM access.

2. Your Office is a Click-to-Run Installation #

Most modern Office 2016+ installs use Click-to-Run instead of the old MSI installer. Click-to-Run doesn't create the traditional InstallRoot registry keys in HKLM\Software\Microsoft\Office\<version>\Word. Instead, it stores configuration in a separate path.

How to check:
Open Registry Editor and look for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration. If this path exists, you're dealing with a Click-to-Run installation.

Fix for Click-to-Run:
Adjust your code to check the Click-to-Run configuration instead:

• Read the ProductReleaseIds value in that ClickToRun key (it lists installed versions like "O365ProPlusRetail").
• Alternatively, check for the Word executable directly in C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE (for 32-bit Office 2016/365).

3. Registry Redirection Is Tricking You #

Even though your app is compiled as x86 and Word is x86, registry redirection on 64-bit Windows might be causing confusion:

• x86 apps automatically get redirected when accessing HKLM\Software—they actually end up looking in HKLM\Software\Wow6432Node.
• So when your code checks path32, it's not looking at the same HKLM\Software\Microsoft\Office\16.0 you see in Registry Editor (unless that key is mirrored in Wow6432Node).

Double-check your Office architecture to confirm:

• Open Word > File > Account > About Word. Look for "32-bit" or "64-bit" at the top of the dialog. If it says 64-bit, that's why your x86 app can't see the key (it lives in the 64-bit registry hive).

4. The Registry Key Has Restricted Permissions #

Even with admin rights, it's possible the InstallRoot key has tight permissions that block your app from reading it.

How to verify:

1. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Word\InstallRoot.
2. Right-click the key > Permissions.
3. Check if your user account (or the Administrators group) has "Read" permission enabled. If not, add it.

Quick Test to Narrow It Down #

To rule out code bugs, try this simplified snippet (run as admin):

using Microsoft.Win32;
using System;

class RegistryTest
{
    static void Main()
    {
        var targetPath = @"SOFTWARE\Microsoft\Office\16.0\Word\InstallRoot";
        using (var key = Registry.LocalMachine.OpenSubKey(targetPath, RegistryKeyPermissionCheck.ReadSubTree))
        {
            Console.WriteLine(key != null ? "Key found!" : "Key not found.");
        }
    }
}

If this finds the key, the issue is likely in your original code's logic (like the WordVersionKeyToValue method returning an incorrect version string). If it still fails, revisit the earlier fixes.

内容的提问来源于stack exchange，提问作者aurel