一个未正式卸载却从内存中消失的DLL案例，第二部分

<p>上次，<a title="一个未正式卸载却从内存中消失的DLL案例" href="https://devblogs.microsoft.com/oldnewthing/20260625-00/?p=112467">我们看了由于DLL在背后被从内存中移除而导致的崩溃</a>，当有人试图调用那个大家都以为还在但其实已不存在的DLL时就会崩溃。</p> <p>我的一个同事正在调查来自同一进程的其他崩溃，发现大部分其他崩溃也是同样的形式：“数据结构因有人向其中写入了单个字节<tt>01</tt>而损坏。”这个消息让我的调查豁然开朗。</p> <p>我们之前看到，<a title="我的HMODULE的最低位被设置是什么意思？" href="https://devblogs.microsoft.com/oldnewthing/20260619-00/?p=112447">数据文件模块句柄的<code>HMODULE</code>的最低位被设置</a>。因此，如果这些散乱的<tt>01</tt>字节恰好覆盖了现有<code>HMODULE</code>句柄的最低位字节，就会将其变成一个（假的）数据文件模块句柄。然后，在进程销毁期间，某个组件尽职尽责地清理它们加载的DLL（例如，因为它们存储在RAII类型如<code>wil::<wbr />unique_<wbr />hmodule</code>中），代码会将这个假的数据文件模块句柄传递给<code>Free­Library</code>。<code>Free­Library</code>函数看到最低位被设置，就会说：“哦，这一定是一个通过<code>LOAD_<wbr />LIBRARY_<wbr />AS_<wbr />DATAFILE</code>加载的模块的句柄”，因此它将作为数据文件释放。</p> <p>释放数据文件模块意味着撤销加载该模块作为数据文件时所采取的步骤：从内存中取消映射DLL。特别地，以数据文件方式加载模块并不会将DLL添加到作为代码加载的DLL列表中；因此，卸载数据文件模块并不会将其从该列表中移除。就DLL列表而言，该DLL仍在内存中。</p> <p>一位比特错误导致代码说谎，并试图释放一个不对应于<code>Load­Library</code>调用的模块句柄，从而引发了大规模的混乱。</p> <p>“DLL从内存中取消映射”的崩溃只是“有人在不应写入的地方写入<tt>01</tt>字节”bug的另一种表现。这个原始bug的<a title="Microspeak: 桶bug、桶喷溅、bug喷溅和故障转移" href="https://devblogs.microsoft.com/oldnewthing/20200121-00/?p=103351">桶喷溅</a>范围比我们最初想象的要大。</p> <p>好消息是，所有崩溃都归结为一个单一的bug。坏消息是，你现在必须调试这一个内存损坏bug。</p> <p>不幸的是，在撰写本文时，第三方程序中的根本内存损坏bug尚未确定。我们不知道它是来自操作系统组件还是程序本身。不过，它似乎只发生在一个进程中，并且在该进程中跨多个模块喷溅，这表明是该程序本身的问题，或者该特定进程使用系统的方式有些特殊。</p> <p>如果你看原始堆栈跟踪，会发现问题发生在进程终止时。这可能是问题潜伏了这么久的原因：退出时的崩溃通常会被忽略，因为不会导致最终用户功能损失。用户本来就已经用完程序了。无论是干净退出还是崩溃退出，对用户来说影响不大。</p> <p>抱歉。并非所有故事都有美满结局。</p> <p>本文<a href="https://devblogs.microsoft.com/oldnewthing/20260626-00/?p=112472">一个未正式卸载却从内存中消失的DLL案例，第二部分</a>首发于<a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>。</p>