这确实是个相当罕见且有意思的异常场景——正常情况下，64位Windows上的32位程序访问C:\Program Files必然会被WoW64重定向到C:\Program Files (x86)，但你遇到的环境里唯独这条规则失效，System32和注册表的重定向却正常生效，完全符合你描述的细节。结合Windows WoW64的工作机制，我整理了几个最可能的实现方向，你可以逐一排查验证：

• 给32位程序添加LARGE_ADDRESS_AWARE标记
  这是最符合你场景的可能性：WoW64有个特殊逻辑——如果32位程序被标记为LARGE_ADDRESS_AWARE（原本是为了让32位程序能访问超过2GB的内存空间），在64位系统上，这个标记会让程序自动绕过Program Files的文件系统重定向，但System32和注册表的WoW64重定向依然保持生效。
  你可以用dumpbin /headers <目标32位程序路径>命令查看程序头部信息，在Characteristics字段下如果能看到Large address aware字样，就说明程序被打了这个标记。很可能客户的服务器管理员通过脚本或工具批量给32位程序添加了这个标记，自己却没意识到会影响路径重定向。

• 通过注册表给特定程序禁用文件系统重定向
  Windows允许针对单个程序单独禁用WoW64文件系统重定向，而不影响其他重定向规则。对应的注册表项是：

  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<程序文件名>\DisableFileSystemRedirection
  

  将这个DWORD值设为1后，目标32位程序访问C:\Program Files时就不会被重定向。你可以检查这个路径下是否存在对应你的应用、Office组件等32位程序的条目，确认是否开启了这个设置。如果是域环境，也可能是通过组策略推送的配置，需要查看组策略编辑器中「计算机配置→管理模板→Windows组件→应用程序兼容性」下的相关规则。

• 利用Windows兼容性修补（Shims）实现绕过
  管理员可能通过Application Compatibility Toolkit（ACT）给特定32位程序添加了DisableFileSystemRedirection的兼容性修补项，也就是常说的Shim。这种修补会让程序在运行时自动绕过Program Files的重定向。
  你可以通过以下方式验证：运行schtasks /run /tn "\Microsoft\Windows\Application Experience\ProgramDataUpdater"更新系统兼容性数据，然后用sigverif工具检查是否有针对目标程序的兼容性修补；或者在「程序和功能→查看已安装的更新」中查找相关的兼容性更新包。

• 系统级重定向配置修改（极端情况）
  虽然非常少见，但可以通过修改系统内核相关的注册表项来调整WoW64行为：在HKLM\SYSTEM\CurrentControlSet\Control\FileSystem下创建DisableRedirectionFor32BitApps DWORD值并设为1，会全局禁用32位程序的文件系统重定向。不过按你描述的System32重定向仍正常的情况，这个可能性较低，但也可以排查一下该注册表项是否存在。

如果你想在测试环境复现这个行为，可以尝试：

1. 用editbin /largeaddressaware <你的32位安装程序路径>给程序添加大地址感知标记，然后运行安装，看是否会直接安装到C:\Program Files而不被重定向；
2. 手动创建上述注册表项，设置DisableFileSystemRedirection为1，运行32位程序验证路径访问行为。

最后要提醒的是：这种绕过WoW64重定向的做法存在潜在风险——比如32位程序误加载C:\Program Files下的64位DLL会直接触发架构不兼容错误。客户那边32位Office能正常加载Common Files中的DLL，可能是他们的Common Files目录下同时存在32位和64位DLL，或者Common Files的重定向也被特殊处理了，这部分建议后续排查清楚，避免后续出现莫名其妙的崩溃问题。

备注：内容来源于stack exchange，提问作者joshudson