个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化《Windows Internals》10.1.10 HKEY_PERFORMANCE_DATA 与 HKEY_PERFORMANCE_TEXT为什么它们明明叫注册表键却根本不是普通注册表存储《Windows Internals》10.1.10 HKEY_PERFORMANCE_DATA 与 HKEY_PERFORMANCE_TEXT为什么它们明明叫注册表键却根本不是普通注册表存储》1. 先说结论这几个键的关键不是“存了什么”而是“怎么被访问”2. 为什么 Windows 要用“注册表机制”来访问性能计数器2.1 这句话怎么通俗理解2.2 这意味着什么3. HKEY_PERFORMANCE_DATA 到底是什么它最重要的特点有 3 个3.1 第一它是一个“特殊键”3.2 第二它只能通过程序方式访问3.3 第三它返回的是“实时性能信息”不是普通静态注册表值4. 为什么说它“明明叫注册表键却根本不是普通注册表存储”4.1 因为它不在 Regedit 里4.2 因为它不存静态数据4.3 因为它的角色更像“接口层”5. HKEY_PERFORMANCE_TEXT 和 HKEY_PERFORMANCE_NLSTEXT 又是干什么的5.1 这句话怎么通俗理解5.2 为什么会设计出 TEXT 和 NLSTEXT 两套6. 为什么 Regedit 看不到它们答案其实很硬核6.1 这句话特别值得记住6.2 这意味着什么7. 这套架构背后都有哪些角色Perflib、PDH、提供者谁负责什么7.1 Perflib更像“注册表性能入口的抽象层”7.2 PDH更适合应用程序直接用的性能访问接口路线 A直接走注册表函数路线 B走 PDH7.3 为什么大多数人实际更容易接触到 PDH 封装后的世界8. 从桌面支持和运维视角看这一节到底有什么现实价值8.1 它帮你理解“性能监控看到的数字从哪来”8.2 它帮你理解“为什么远程性能监控能工作”8.3 它帮你分清“配置型注册表”和“接口型注册表”8.4 它帮你避免一个误区别再想着用 Regedit 去“看性能数据”9. 这一节最容易被误解的 6 个点我帮你一次理顺9.1 误解一HKEY_PERFORMANCE_DATA 是普通注册表数据仓库9.2 误解二既然叫“键”那 Regedit 里一定能看到9.3 误解三HKEY_PERFORMANCE_TEXT 也是普通文本配置区9.4 误解四TEXT 和 NLSTEXT 没区别9.5 误解五这是内核原生支持的普通根键9.6 误解六既然用了注册表 API就说明性能数据一定存在注册表 hive 里10. 用一张图把这套机制一次讲透11. 我的学习理解这一节真正打碎的是“注册表静态配置仓库”的刻板印象12. 总结提升下一篇预告《Windows Internals》10.1.10 HKEY_PERFORMANCE_DATA 与 HKEY_PERFORMANCE_TEXT为什么它们明明叫注册表键却根本不是普通注册表存储》学到注册表这一章时很多人看到HKEY_PERFORMANCE_DATA、HKEY_PERFORMANCE_TEXT、HKEY_PERFORMANCE_NLSTEXT这几个名字第一反应往往是既然都叫注册表键那应该能在 Regedit 里直接展开吧既然是“键”那里面的数据应该也像 HKLM、HKCU 一样真正存放在注册表里吧既然叫 Performance那它是不是就是性能监视器的“配置表”但《Windows Internals》这一小节给出的答案非常明确Windows 确实通过“注册表机制”来访问性能计数器数据这样做的一个直接好处是远程性能监控几乎“免费获得”因为普通注册表 API 本身就支持远程访问不过HKEY_PERFORMANCE_DATA 并不是普通注册表存储它只能通过编程方式访问Regedit 里根本看不到而且性能信息实际上并不存储在注册表里而是由注册表函数转发到实时性能数据提供者那里去取。HKEY_PERFORMANCE_TEXT则主要返回性能计数器的名称和说明文本其中Counter返回名称Help返回描述HKEY_PERFORMANCE_TEXT默认是美式英语而HKEY_PERFORMANCE_NLSTEXT返回的是当前操作系统语言环境下的名称和描述。书里还进一步说明这套访问模型在实现上由PerflibPerformance Library抽象Perflib 静态链接在Advapi32.dll中而Windows 内核本身甚至不知道有 HKEY_PERFORMANCE_DATA 这个键存在这也正是它不会出现在注册表编辑器里的原因。所以这篇文章我就专门把10.1.10 HKEY_PERFORMANCE_DATA 与 HKEY_PERFORMANCE_TEXT讲透。看完之后你会真正明白一句话它们“长得像注册表键”但本质上更像“借注册表 API 暴露出来的实时性能访问入口”。1. 先说结论这几个键的关键不是“存了什么”而是“怎么被访问”我先把最核心的结论放在前面HKEY_PERFORMANCE_DATA / HKEY_PERFORMANCE_TEXT / HKEY_PERFORMANCE_NLSTEXT 的重点不在“注册表里存了什么内容”而在“Windows 允许你通过注册表接口去拿实时性能信息和性能计数器文本”。这和我们前面学的根键很不一样HKCU偏当前用户配置HKLM偏整机级配置HKCR偏 Classes 合并视图HKCC偏硬件配置链接HKPD / HKPT / HKPNT则更像一种特殊接口入口不是普通静态配置仓库。也就是说它们被命名成注册表根键不代表它们就等于“普通注册表数据树”。2. 为什么 Windows 要用“注册表机制”来访问性能计数器这一点书里讲得很漂亮。它明确说The registry is the mechanism used to access performance counter values on Windows不管这些计数器来自操作系统组件还是来自服务器应用。同时这种设计的一个副作用好处是远程性能监控几乎“免费”获得因为普通注册表 API 天生就支持远程访问。2.1 这句话怎么通俗理解你可以这样理解Windows 没有专门再发明一套全新的“远程性能计数器通信协议”而是直接复用了已经成熟的注册表访问通道。所以从系统设计角度看这个思路很聪明本地能用注册表 API 取性能数据远程也能沿用这套机制工具和代码实现层面都更统一。2.2 这意味着什么这意味着这里的“注册表”更像传输通道和访问门面不一定是最终数据落地位置。也正因为如此你后面看到HKEY_PERFORMANCE_DATA时不应该先问“这个键里文件式地存了什么”而应该先问“我通过这个入口能拿到什么实时信息”3. HKEY_PERFORMANCE_DATA 到底是什么它最重要的特点有 3 个《Windows Internals》这里其实已经把 HKPD 的本质说得非常清楚了。3.1 第一它是一个“特殊键”书里说得很直接你可以通过打开一个特殊键HKEY_PERFORMANCE_DATA然后查询它下面的值但这不是普通注册表编辑流程。这说明它一开始就不是按普通“浏览配置树”的思路设计的。3.2 第二它只能通过程序方式访问书中明确指出你在 Registry Editor 里找不到这个键它只能通过 Windows 注册表函数以编程方式访问例如RegQueryValueEx。这句话非常关键因为它直接打破了很多初学者的直觉不是所有叫“注册表键”的东西都能在 Regedit 里点开。3.3 第三它返回的是“实时性能信息”不是普通静态注册表值这是最核心的一点。书里写得非常清楚Performance information isn’t actually stored in the registry注册表函数在访问这个键时会把请求redirect到性能数据提供者最终拿到的是live performance information。也就是说HKEY_PERFORMANCE_DATA 更像“实时取数入口”而不是“性能数据仓库”。4. 为什么说它“明明叫注册表键却根本不是普通注册表存储”这一节其实就是标题的核心答案。4.1 因为它不在 Regedit 里普通注册表键最起码有一个非常朴素的特征你能在 Regedit 里看到它能展开它能直观看到静态键和值而HKEY_PERFORMANCE_DATA不是这样。书里明确说你在注册表编辑器里找不到它。4.2 因为它不存静态数据普通注册表键还有另一个典型特征数据提前放在那里你打开时只是“读取已经存在的东西”而 HKPD 不是这样。它返回的是实时性能信息由注册表函数转发到实际性能数据提供者那里获取。4.3 因为它的角色更像“接口层”如果把普通注册表键类比成“配置文件夹”那 HKEY_PERFORMANCE_DATA 更像一个 API 门面一个桥接层一个动态代理入口所以我更喜欢用下面这张图理解它应用程序注册表函数/RegQueryValueExHKEY_PERFORMANCE_DATA 特殊入口重定向到性能数据提供者返回实时性能计数器值这张图背后的核心意思就是HKPD 是“拿数据的入口”不是“存数据的仓库”。5. HKEY_PERFORMANCE_TEXT 和 HKEY_PERFORMANCE_NLSTEXT 又是干什么的如果说 HKEY_PERFORMANCE_DATA 负责“值”那 HKEY_PERFORMANCE_TEXT / HKEY_PERFORMANCE_NLSTEXT 更偏“字典”和“说明书”。书里明确说HKEY_PERFORMANCE_TEXT是另一个特殊键它通常用于获取性能计数器信息里的name 和 description查询特殊的Counter值可以拿到性能计数器名称查询特殊的Help值可以拿到性能计数器描述HKEY_PERFORMANCE_TEXT返回的是US EnglishHKEY_PERFORMANCE_NLSTEXT返回的是操作系统当前语言环境下的名称和描述。5.1 这句话怎么通俗理解你可以把这三个键理解成一个组合HKPD拿“性能数值”HKPT拿“计数器英文名称和英文说明”HKPNT拿“本地语言名称和本地语言说明”5.2 为什么会设计出 TEXT 和 NLSTEXT 两套因为性能计数器不仅要让机器读还要让人看。如果只有数值没有名称和说明那很多监控工具显示出来就会很难用。所以 Windows 把“数值”和“文本资源”拆开让工具既能拿到实时数据也能拿到对应的人类可读描述。也就是说性能计数器体系不仅有“数据面”还有“解释面”。6. 为什么 Regedit 看不到它们答案其实很硬核书里给出的答案非常漂亮这套特殊键是由Performance LibraryPerflib抽象出来的Perflib 静态链接在Advapi32.dllWindows 内核根本不知道有 HKEY_PERFORMANCE_DATA 这个键这就是它为什么不会显示在 Registry Editor 里。6.1 这句话特别值得记住因为它一下子把层次理顺了不是内核里真有一棵普通“HKPD 树”而是用户态这套性能库在注册表 API 语义层面把这个特殊入口“做了出来”Regedit 不能显示它恰恰说明它不属于普通配置管理器那套静态枚举逻辑。6.2 这意味着什么意味着你以后再看到“注册表根键”这个词时要更有层次感有的是真实配置树有的是链接有的是合并视图还有的像 HKPD 这种本质上是抽象出来的特殊访问入口。所以“是不是注册表键”这个问题不能只按名字判断还得看它背后到底是静态数据、逻辑映射、还是动态接口。7. 这套架构背后都有哪些角色Perflib、PDH、提供者谁负责什么书里提到两个非常关键的角色PerflibPDHPerformance Data Helper。7.1 Perflib更像“注册表性能入口的抽象层”书里说HKEY_PERFORMANCE_DATA 这套特殊键是由Performance LibraryPerflib抽象的Perflib 静态链接在Advapi32.dll。你可以把它理解成注册表性能访问入口的中间层和解释层。7.2 PDH更适合应用程序直接用的性能访问接口书里同时指出你也可以不直接走注册表函数而是用Performance Data Helper APIPdh.dll来访问性能计数器信息。这说明从应用开发和工具开发角度看Windows 其实给了两种路线路线 A直接走注册表函数例如RegQueryValueEx访问 HKEY_PERFORMANCE_DATA路线 B走 PDH通过 Pdh.dll 封装后的 API 去拿性能计数器7.3 为什么大多数人实际更容易接触到 PDH 封装后的世界因为很多常见工具底层未必让你直面 HKPD而是已经替你走好了这条链。书中图 10-2 也在强调这套组件关系应用程序、PDH、Advapi32/Perflib、WMI、高性能数据提供者、性能扩展 DLL 等共同参与了性能计数器访问链路。8. 从桌面支持和运维视角看这一节到底有什么现实价值这个问题非常关键。因为如果只停留在“知道有这个键”学习价值其实不够高。8.1 它帮你理解“性能监控看到的数字从哪来”很多人会用性能监视器资源监视器各类监控平台PowerShell 的性能计数器命令但未必真的理解这些数字背后的通路。这一节至少告诉你Windows 性能计数器体系和注册表 API 是打通的但这不代表性能数据真躺在普通注册表里。8.2 它帮你理解“为什么远程性能监控能工作”书里专门点出走注册表机制的一个额外好处是远程性能监控 works “for free”因为正常注册表 API 本来就支持远程访问。这对企业环境非常有价值。也就是说某些远程性能采集之所以能自然成立不是因为另有一套完全独立的远程协议而是因为 Windows 把它嫁接进了已有的注册表访问框架。8.3 它帮你分清“配置型注册表”和“接口型注册表”这一点特别重要。前面几篇我们一直在讲用户配置机器配置Classes 配置硬件配置链接这些都偏“配置型”。而这一节告诉你注册表世界里还存在另一类东西名字上是注册表键实际上却更接近“动态接口层”这会让你对 Windows 的整体设计更有感觉。8.4 它帮你避免一个误区别再想着用 Regedit 去“看性能数据”因为书已经明确说了Regedit 里看不到 HKPD它只能通过编程接口访问而且取到的是实时数据不是普通静态值。所以以后看到这几个根键时正确思路不是“我去 Regedit 展开看看里面有什么。”而应该是“这是给工具和 API 走的不是给我手工点树看的。”9. 这一节最容易被误解的 6 个点我帮你一次理顺9.1 误解一HKEY_PERFORMANCE_DATA 是普通注册表数据仓库不对。它返回的是通过注册表函数转发拿到的实时性能信息并不是普通静态注册表存储。9.2 误解二既然叫“键”那 Regedit 里一定能看到也不对。书里明确说了你在 Registry Editor 里找不到它。9.3 误解三HKEY_PERFORMANCE_TEXT 也是普通文本配置区不对。它是一个特殊键用来获取性能计数器的名称和描述不是让你像普通注册表配置那样去保存文本选项。9.4 误解四TEXT 和 NLSTEXT 没区别也不对。HKEY_PERFORMANCE_TEXT提供US English文本HKEY_PERFORMANCE_NLSTEXT提供当前操作系统语言环境下的文本。9.5 误解五这是内核原生支持的普通根键不对。书里明确说Windows kernel has no knowledge about the HKEY_PERFORMANCE_DATA registry key。9.6 误解六既然用了注册表 API就说明性能数据一定存在注册表 hive 里这恰恰是最容易掉进去的坑。书里直接否定了这一点Performance information isn’t actually stored in the registry。10. 用一张图把这套机制一次讲透监控工具/应用程序注册表函数 或 PDH APIPerflib / Advapi32.dllHKEY_PERFORMANCE_DATA 特殊入口HKEY_PERFORMANCE_TEXTHKEY_PERFORMANCE_NLSTEXT实时性能计数器值英文计数器名称与说明本地语言计数器名称与说明性能数据提供者Counter / Help 文本本地化文本资源这张图最重要的意思就是名字上它们属于注册表世界但工作方式更接近“统一入口 动态分发 实时取数”。11. 我的学习理解这一节真正打碎的是“注册表静态配置仓库”的刻板印象我觉得 10.1.10 这一节特别妙的一点在于它再次证明Windows 里的“注册表”并不只是静态配置数据库。前面我们已经看到过有的是链接有的是合并视图有的是逻辑根而这一节又告诉我们有些甚至是通过注册表 API 暴露出来的实时数据接口。这让我对注册表的理解从“配置文件树”升级成了配置数据库逻辑命名空间兼容性入口运行时接口门面而 HKEY_PERFORMANCE_DATA 这一组键就是“接口门面”这个角色最典型的例子。所以它们最值得学的地方不是路径记忆而是系统分层思维。12. 总结提升如果让我用一句话总结10.1.10 HKEY_PERFORMANCE_DATA 与 HKEY_PERFORMANCE_TEXT我会这样说它们虽然被命名成注册表根键但本质上并不是普通注册表存储而是 Windows 借助注册表 API、Perflib 与性能数据提供者共同实现的一套实时性能访问入口HKEY_PERFORMANCE_DATA 负责计数器值HKEY_PERFORMANCE_TEXT / HKEY_PERFORMANCE_NLSTEXT 负责名称和说明文本。这篇最值得记住的 8 个结论是Windows 用注册表机制来访问性能计数器值这既适用于系统组件也适用于服务器应用。这种设计的一个额外好处是远程性能监控几乎可以“免费获得”。HKEY_PERFORMANCE_DATA 只能通过编程方式访问例如RegQueryValueExRegedit 里看不到。性能信息并不真正存储在注册表里而是由注册表函数转发到实时性能数据提供者。HKEY_PERFORMANCE_TEXT 返回计数器名称和说明文本其中Counter是名称Help是描述。HKEY_PERFORMANCE_TEXT 默认是美式英语HKEY_PERFORMANCE_NLSTEXT 则返回操作系统本地语言版本。这套特殊键由 Perflib 抽象Perflib 静态链接在Advapi32.dll。Windows 内核并不知道 HKEY_PERFORMANCE_DATA 这个键存在这就是它不出现在 Registry Editor 中的根本原因。学完这一节后后面你再继续看PerflibPDH性能计数器提供者WMI Performance Counter provider性能监视器/监控链路ETW 与性能诊断都会顺很多因为你已经抓住了这一层主线它们不是“普通注册表存储”而是“借注册表语义暴露出来的性能访问接口”。下一篇预告《Windows Internals》10.1.11 应用程序 HiveApplication hives为什么 Windows 要允许应用拥有“只对自己可见”的私有注册表》这一篇会把RegLoadAppKeyREG_PROCESS_APPKEY私有命名空间应用私有 hiveUWP / Modern Application Model全部串起来非常适合继续往下学。返回顶部