《Windows Internals》10.1.11 应用程序 Hive（Application hives）：为什么 Windows 要允许应用拥有“只对自己可见”的私有注册表？

个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化《Windows Internals》10.1.11 应用程序 HiveApplication hives为什么 Windows 要允许应用拥有“只对自己可见”的私有注册表《Windows Internals》10.1.11 应用程序 HiveApplication hives为什么 Windows 要允许应用拥有“只对自己可见”的私有注册表1. 先说结论应用程序 Hive是 Windows 给应用准备的“私有注册表房间”2. 为什么普通注册表访问还不够问题恰恰出在“太公共”2.1 这句话怎么通俗理解2.2 为什么这对现代应用特别重要3. Windows 7 为什么要引入 Application hives因为“私有仓库”是刚需3.1 旧问题的核心不是“不会存”而是“存得不私有”3.2 它本质上是什么4. Application hive 到底怎么创建和加载核心 API 有两个4.1 这条链路怎么理解第一步先准备一份标准 hive 文件第二步再以“应用私有”的方式挂载它4.2 REG_PROCESS_APPKEY 为什么特别值得记5. Application hive 在内核里是怎么被挂进去的这一段特别有 Windows Internals 味道5.1 为什么这个私有命名空间很关键5.2 书里为什么强调 NtLoadKeyEx 和 CmLoadAppKey6. 为什么说它“只对自己可见”关键在这两个特性6.1 “无法枚举”意味着什么6.2 “绑定进程生命周期”意味着什么7. 既然是私有的应用还怎么用答案是照常用标准注册表 API7.1 这意味着什么7.2 为什么这个设计很聪明8. Application hive 在 Windows 里真的有人用吗不仅有人用而且用得很实际8.1 UWP 为什么会用 application hives8.2 Background Infrastructure 为什么也依赖它9. Application Data containers 又是什么为什么它也和 application hive 有关9.1 这句话怎么通俗理解9.2 settings.dat 和 ActivationStore.dat 为什么要一起记10. 为什么 Windows 不直接让应用各自用文件存配置为什么还要走 hive 这套机制10.1 因为 Windows 想给应用“私有性”但又不想丢掉注册表生态10.2 因为很多现代应用元数据本来就适合“注册表式组织”10.3 因为“私有注册表”比“公共注册表”更适合现代应用模型11. 从桌面支持和系统学习视角这一节到底有什么现实价值11.1 它帮你理解“现代应用不一定把所有设置都丢在普通 HKCU/HKLM 里”11.2 它帮你理解 UWP / 现代应用模型为什么和传统 Win32 不一样11.3 它帮你真正理解“注册表”在 Windows 里已经不只是全局数据库12. 这一节最容易被误解的 6 个点我帮你一次理顺12.1 误解一Application hive 是一种全新文件格式12.2 误解二应用私有设置就是“存在全局注册表里但权限更严”12.3 误解三只有管理员才能用 application hives12.4 误解四应用私有 hive 加载后会一直留在系统里12.5 误解五这只是个冷门 APIWindows 自己并不用12.6 误解六Application Data containers 和 application hive 没关系13. 用一张图把 Application hive 的本质彻底讲透14. 我的学习理解这一节真正厉害的地方在于它把“注册表”从全局配置扩展成了“应用私有运行时基础设施”15. 总结提升下一篇预告《Windows Internals》10.1.11 应用程序 HiveApplication hives为什么 Windows 要允许应用拥有“只对自己可见”的私有注册表学到注册表这一章时很多人已经接受了一个事实应用程序平时可以直接读写全局注册表。但继续往下看《Windows Internals》会马上抛出一个更有意思的问题既然应用已经能访问全局注册表Windows 为什么还要专门设计“Application hives应用程序 Hive”这种机制书里的答案很明确传统做法下应用虽然可以用RegSaveKeyEx和RegLoadKeyEx去加载或保存 hive但它操作的数据仍可能被同权限或更高权限的其他进程干扰而且这类加载/保存操作还需要启用Backup / Restore privileges通常只有管理员进程才具备。正因为这对很多只想拥有“自己私有配置仓库”的应用来说限制太大Windows 7 才引入了 application hives。应用程序 hive 本质上仍是标准 hive 文件但它可以被私有挂载并且只对发起请求的那个应用可见。所以这篇文章我就专门把10.1.11 应用程序 HiveApplication hives讲透。看完之后你会真正理解一句话Application hive 的核心价值不是“又多了一种注册表文件”而是“让应用拥有一份只属于自己、别人看不见也干扰不到的私有注册表命名空间”。1. 先说结论应用程序 Hive是 Windows 给应用准备的“私有注册表房间”如果只用一句话总结这一节我会这样说Application hive 就像 Windows 专门给某个应用单独开出来的一间“私有注册表房间”应用可以继续用标准注册表 API 读写但房间门牌只属于它自己。它和我们前面学过的几类注册表视图不一样HKCU更像当前用户视图HKLM更像整机级配置总入口HKCR更像用户级与系统级 Classes 的合并视图Application hive则更像**“进程私有配置空间”**。这也是它最值得学的地方它不是在扩展“全局注册表”而是在补足“应用私有配置隔离”这件事。2. 为什么普通注册表访问还不够问题恰恰出在“太公共”书里在这一节一开头就先把旧方案的问题点出来了应用通常能读写全局注册表打开某个注册表键时Windows 会根据进程或线程的访问令牌以及键上的 ACL 做访问检查应用也可以通过RegSaveKeyEx/RegLoadKeyEx去保存或加载 hive但这样做时应用操作的数据仍可能被同权限或更高权限的其他进程干扰而且加载/保存 hive 需要Backup / Restore privileges这两个权限通常只给管理员进程。2.1 这句话怎么通俗理解你可以这样理解传统方式虽然“能存”但很难做到“只给我自己存而且别人别碰”。也就是说问题不在“有没有地方存设置”而在于这个地方是不是足够私有是不是足够隔离普通应用是不是也能合法用上它2.2 为什么这对现代应用特别重要因为很多应用并不想把自己的内部状态直接扔到所有进程都可能看到的全局注册表区域或者必须依赖管理员特权才能管理的 hive 机制里它们更想要的是一份对自己透明、对外隔离、又不必要求管理员权限才能正常使用的私有配置仓库。3. Windows 7 为什么要引入 Application hives因为“私有仓库”是刚需《Windows Internals》这里说得很直接对于大多数想访问私有设置仓库的应用来说旧做法是个限制因此 Windows 7 引入了 application hives。这句话其实已经把设计动机讲透了。3.1 旧问题的核心不是“不会存”而是“存得不私有”传统注册表方案当然能存数据问题在于数据容易暴露在全局命名空间里同级/高权限进程可能干扰显式加载/保存 hive 又对权限要求太高。所以 Windows 7 引入 application hives不是为了再造一个“新注册表”而是为了补上这个空白让应用有能力拥有“只对自己可见”的注册表式配置仓库。3.2 它本质上是什么书里定义得很清楚Application hive 是标准 hive 文件也会关联正确的日志文件但它可以被私有挂载并且只对请求它的应用可见。所以Application hive 不是“特殊格式文件”而是“特殊可见性和特殊挂载方式”的标准 hive。4. Application hive 到底怎么创建和加载核心 API 有两个这一节很适合把 API 思路顺一下。书里给出的关键链路是开发者可以先用RegSaveKeyEx从普通注册表键导出内容创建一个基础 hive 文件然后再用RegLoadAppKey把这个 hive私有挂载如果指定REG_PROCESS_APPKEY标志就能阻止其他应用访问同一个 hive。4.1 这条链路怎么理解你可以把它拆成两步第一步先准备一份标准 hive 文件这一层依然是普通 hive 的概念并不是发明了新格式。第二步再以“应用私有”的方式挂载它这一步才是 application hive 真正和普通 hive 拉开差距的地方。4.2 REG_PROCESS_APPKEY 为什么特别值得记因为它直接体现了这个机制的目标不是单纯把 hive 加进系统而是要让它只属于当前进程上下文也就是说REG_PROCESS_APPKEY 体现的是“进程级私有可见性”而不是传统“全局注册表挂载”。5. Application hive 在内核里是怎么被挂进去的这一段特别有 Windows Internals 味道这部分是我觉得整节最有“内功感”的地方。书里说RegLoadAppKey内部大致会做两件关键事创建一个随机 GUID并把它分配到一个私有命名空间里路径形式是\Registry\A\Random Guid把指定 hive 文件的 DOS 路径转换成 NT 格式路径然后调用NtLoadKeyEx。5.1 为什么这个私有命名空间很关键因为它直接说明了Application hive 不是挂到公开注册表树上而是挂进了一个应用私有的注册表命名空间。这就像给每个应用单独开了一条不公开的小巷里面照样可以放注册表树照样可以有 key / value但别人不会像浏览 HKLM / HKCU 那样自然枚举到它。5.2 书里为什么强调NtLoadKeyEx和CmLoadAppKey因为这说明它虽然“私有”但底层并不是在用户态自己玩一套假的注册表。书里明确说NtLoadKeyEx会走正常的注册表回调逻辑但一旦检测到这是 application hive它就会通过CmLoadAppKey把 hive 以及其日志文件加载到这个私有命名空间里。也就是说它不是绕开注册表系统而是借配置管理器的正式能力在“私有命名空间”里加载一份标准 hive。6. 为什么说它“只对自己可见”关键在这两个特性书里把这件事讲得很明白这个私有命名空间not enumerable by any other application也就是其他应用无法枚举同时它又tied to the lifetime of the calling process也就是和调用进程的生命周期绑定。6.1 “无法枚举”意味着什么意味着别的应用不能像扫描普通注册表树那样去遍历它。这就极大增强了“私有仓库”的语义。6.2 “绑定进程生命周期”意味着什么意味着这不是那种“挂上去就长期暴露在系统里”的全局挂载。它更像只要你这个进程活着我就给你保留这间私有房间你退出了房间就自动收走。书里后面也明确说应用退出时或者最后一个 key 句柄被关闭时这个 hive 会自动卸载。所以Application hive 真正私有的原因不只是“路径特殊”还包括“别人枚举不到 生命周期只跟你这个进程走”。7. 既然是私有的应用还怎么用答案是照常用标准注册表 API这一点特别漂亮。书里明确说应用仍然可以使用标准 registry APIs去读写自己的私有设置这些设置会被存到 application hive 里。7.1 这意味着什么意味着从开发者视角看并不需要重新学一套完全不同的数据访问模型不需要把自己当数据库开发不需要手搓文件格式因为 Windows 给出的思路是你继续像用注册表一样用但底层我帮你换成了“只对你可见的私有 hive”。7.2 为什么这个设计很聪明因为它同时满足了三件事兼容性开发者还能用熟悉的注册表 API隔离性数据不暴露给其他应用自动清理进程结束或句柄关闭就自动卸载。这就是非常典型的 Windows 工程风格尽量不逼开发者换思维模型而是在底层帮你完成隔离和抽象。8. Application hive 在 Windows 里真的有人用吗不仅有人用而且用得很实际这一点书里说得非常明确不是“理论机制”。它直接举了几个使用者Application Compatibility telemetry agentCompatTelRunner.exeModern Application ModelUWP 应用Background Infrastructure 组件。8.1 UWP 为什么会用 application hives书里指出UWP 应用会用 application hive 存储那些只能被该应用私有实例化的 WinRT classes 信息这份 hive 存在一个叫ActivationStore.dat的文件里它主要被Activation Manager在应用启动更准确说是“激活”时消费。这句话特别重要因为它说明 application hive 不只是“存用户偏好”还可以承载更底层的激活元数据WinRT 类可实例化信息应用私有运行时能力。8.2 Background Infrastructure 为什么也依赖它书里接着说Modern Application Model 的Background Infrastructure会用 hive 里的数据保存后台任务信息这样当后台任务定时器触发时系统就能知道任务代码在哪个应用库里它的 activation type 是什么threading model 是什么。这说明 application hive 的价值不只是“给设置找个地方放”而是把应用私有运行时元数据组织成一份只属于这个应用的注册表式仓库。9. Application Data containers 又是什么为什么它也和 application hive 有关这一段特别值得单独拿出来理解。书里说现代应用栈还给 UWP 开发者提供了Application Data containers这些容器可以存只在本机有效的 local 数据或者能在用户多台设备间自动共享的数据这些容器由Windows.Storage.ApplicationData.dll这个 WinRT 库实现而它在本地存设置时底层仍然会用一个local to the application 的 application hive对应的 backing file 叫settings.dat。9.1 这句话怎么通俗理解你可以把它理解成UWP 提供给开发者的“应用设置容器”底层其实不是随便写个 ini/json而是仍然建立在 application hive 这套机制上。这说明 application hive 在现代 Windows 里并不是边缘能力而是和应用激活应用数据容器后台任务元数据WinRT 类私有存储都深度耦合。9.2settings.dat和ActivationStore.dat为什么要一起记因为书里正好把它们都点名了ActivationStore.dat更偏应用激活、WinRT 类实例化和私有激活元数据settings.dat更偏 UWP 应用创建出来的设置数据存储。所以你以后看到这两个文件名时就能立刻把它们和 application hive 这条线串起来。10. 为什么 Windows 不直接让应用各自用文件存配置为什么还要走 hive 这套机制这个问题书里没有直接用一句话回答但从它给出的实现方式和应用场景其实已经能推出来。10.1 因为 Windows 想给应用“私有性”但又不想丢掉注册表生态用 application hive 的好处是仍然保留 key/value 结构仍然能用标准注册表 API仍然能配合日志文件、配置管理器和现有注册表基础设施同时还实现了进程级私有可见性。10.2 因为很多现代应用元数据本来就适合“注册表式组织”比如类注册激活信息后台任务元数据多层次设置容器这些东西如果全塞进普通平面文本文件里反而未必自然。而注册表型层次结构在这方面很顺手。10.3 因为“私有注册表”比“公共注册表”更适合现代应用模型尤其是 UWP / Modern Application Model 这类更强调沙箱应用边界私有激活信息生命周期与隔离性的模型application hive 明显更贴合它们的要求。11. 从桌面支持和系统学习视角这一节到底有什么现实价值你可能会问这听起来更像开发者机制跟桌面支持有什么关系其实关系不小。11.1 它帮你理解“现代应用不一定把所有设置都丢在普通 HKCU/HKLM 里”如果你还停留在设置一定在 HKCU\Software或者 HKLM\Software这种思路那面对现代应用模型时就会经常“找不到东西”。这一节至少告诉你有些应用的关键私有设置和激活元数据根本不在传统公共注册表路径里而是放在 application hives 里。11.2 它帮你理解 UWP / 现代应用模型为什么和传统 Win32 不一样这一节把几个关键部件串到了一起Activation ManagerBackground InfrastructureApplication Data containersWinRT classesActivationStore.datsettings.dat。这会让你更容易理解为什么现代应用的配置路径和传统软件不一样为什么某些 UWP 设置看起来“没写进普通注册表”为什么后台任务、激活机制更像系统托管而不是应用自己随便运行11.3 它帮你真正理解“注册表”在 Windows 里已经不只是全局数据库这一节再次证明了注册表可以是全局配置数据库也可以是逻辑命名空间还可以是私有应用配置容器甚至可以嵌进现代应用运行时模型里。这会让你对 Windows Internals 的理解一下子更立体。12. 这一节最容易被误解的 6 个点我帮你一次理顺12.1 误解一Application hive 是一种全新文件格式不对。书里明确说它是standard hive file只是挂载方式和可见性变了。12.2 误解二应用私有设置就是“存在全局注册表里但权限更严”也不准确。它的关键点不是单纯 ACL 更严而是私有命名空间 非枚举可见性 生命周期绑定。12.3 误解三只有管理员才能用 application hives恰恰相反。旧的显式加载/保存 hive 方案才更依赖管理员权限application hive 的引入正是为了缓解这个限制。12.4 误解四应用私有 hive 加载后会一直留在系统里不对。书里明确说应用退出或最后一个句柄关闭时它会自动卸载。12.5 误解五这只是个冷门 APIWindows 自己并不用也不对。书里明确举了 CompatTelRunner、Modern Application Model、UWP、Background Infrastructure 等真实使用者。12.6 误解六Application Data containers 和 application hive 没关系不对。Windows.Storage.ApplicationData.dll底层就会用本地 application hive把设置写进settings.dat。13. 用一张图把 Application hive 的本质彻底讲透应用程序RegSaveKeyEx 创建基础 HiveRegLoadAppKey 私有挂载REG_PROCESS_APPKEY私有命名空间 \\Registry\\A\\NtLoadKeyExCmLoadAppKey只对当前应用可见的私有 Hive标准注册表 API 继续读写进程结束或句柄关闭时自动卸载UWP ActivationStore.datApplication Data settings.datBackground tasks 元数据这张图想表达的核心只有一句Application hive 的关键不是“新文件”而是“新可见性、新命名空间、新生命周期”。14. 我的学习理解这一节真正厉害的地方在于它把“注册表”从全局配置扩展成了“应用私有运行时基础设施”我觉得 10.1.11 这一节特别惊艳的一点是它让“注册表”这个概念一下子扩展开了。以前如果只学传统注册表很容易把它理解成HKLM系统配置HKCU用户配置HKCR类注册就这些了但 application hives 告诉我们Windows 甚至愿意把“应用自己的私有元数据空间”也建立在 hive / 注册表 API / 配置管理器这套体系之上。这说明 Windows 对注册表的使用早就不是“单纯存系统设置”那么简单而是把它当成层次化命名空间私有存储模型运行时元数据容器现代应用基础设施的一部分所以我觉得这一节最值得记住的不是 API 名字本身而是它背后的设计思想Windows 不只是允许应用“使用注册表”而是允许应用“拥有一份只属于自己的注册表”。15. 总结提升如果让我用一句话总结10.1.11 应用程序 HiveApplication hives我会这样说Application hive 的本质是 Windows 在保留标准 hive 文件和标准注册表 API 的前提下为应用创建出来的一套私有注册表命名空间它解决的不是“能不能存数据”而是“能不能拥有只对自己可见、不会被别的进程轻易干扰的配置仓库”。这篇最值得记住的 8 个结论是传统RegSaveKeyEx/RegLoadKeyEx方案会面临同级或高权限进程干扰而且需要 Backup / Restore privileges。Windows 7 为了解决大多数应用缺少私有配置仓库的问题引入了 application hives。Application hive 仍是标准 hive 文件只是可被私有挂载。RegLoadAppKey配合REG_PROCESS_APPKEY可以把 hive 挂进只属于当前应用的私有命名空间。其内部会创建\Registry\A\Random Guid形式的私有命名空间并通过NtLoadKeyEx/CmLoadAppKey完成加载。私有 hive 不会被其他应用枚举到并且与调用进程生命周期绑定。应用仍然可以通过标准注册表 API 读写自己的私有设置。UWP、Modern Application Model、Activation Manager、Background Infrastructure、Application Data containers 都会使用 application hives例如ActivationStore.dat和settings.dat。学完这一节之后后面你继续看10.1.12 Transactional RegistryTxR注册表命名空间Startup and registry processVReg / differencing hivesModern Application ModelUWP 配置存储都会顺很多因为你已经把一个关键主线抓住了Windows 注册表不只服务于“系统”和“用户”它还可以服务于“应用自己的私有世界”。下一篇预告《Windows Internals》10.1.12 事务型注册表Transactional Registry, TxR为什么注册表操作也能像数据库一样“提交”与“回滚”》这一篇会把RegCreateKeyTransactedRegOpenKeyTransactedRegDeleteKeyTransactedKTMCLFS.regtrans-ms事务隔离与提交/回滚全部串起来特别适合继续往下学。返回顶部