32位VB6程序在64位Windows系统中读取HKLM注册表项的差异原因咨询

这问题确实挺让人挠头的——明明都是HKLM\SOFTWARE下面的项，为啥IE的能直接读，自己建的就不行？我来给你拆解这里面的核心门道：

首先得说清楚64位Windows里的**注册表重定向（Registry Redirector）**机制：默认情况下，32位程序访问HKLM\SOFTWARE时，系统会自动把请求重定向到HKLM\SOFTWARE\WOW6432Node，这是为了隔离32位和64位程序的注册表数据，避免版本冲突。

但这里有个关键例外：微软为了兼容大量依赖系统组件的老程序，给一部分系统自带的注册表项设置了重定向豁免，HKLM\SOFTWARE\Microsoft\Internet Explorer就是其中之一。也就是说，当你的32位VB6程序访问这个IE项时，系统不会把你导向WOW6432Node，而是直接让你读取64位系统里的原生注册表项内容——这就是为啥你能直接拿到IE的Version值。

而你自己创建的HKLM\SOFTWARE\Our Software属于自定义注册表项，不在微软的豁免列表里，所以完全遵循默认的重定向规则：你的32位程序访问这个路径时，实际被偷偷导向了HKLM\SOFTWARE\WOW6432Node\Our Software，而你是把“Last Serviced”项建在了64位的原生HKLM\SOFTWARE下面，自然就读不到了——哪怕权限和IE项完全一样也没用，核心问题是系统自动改了你访问的实际路径。

如果想让32位程序能直接读取64位原生HKLM\SOFTWARE下的自定义项，你得在程序里调用Windows API（比如RegOpenKeyEx）时，指定KEY_WOW64_64KEY这个访问标志，这样就能绕过重定向，直接访问64位的注册表分支。不过VB6原生的注册表操作函数不支持这个标志，你得自己声明API来实现。

另外，要是担心有人不小心把项建到了64位的HKLM里，程序可以做个兼容处理：先尝试用KEY_WOW64_64KEY标志读取64位分支，读不到再去WOW6432Node里找，这样不管数据存在哪都能拿到。

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