d3dx9_26.dll缺失：DirectX旧组件与运行库排查指南

周末从柜子里翻出一张十几年前的老游戏光盘，装完、双击图标，屏幕正中弹出一行小字：找不到 d3dx9_26.dll。这个提示我前后遇到过不下几十次，从 Windows XP 时代一直到现在的 Windows 11，它出现的姿势几乎没变过。很多人第一反应是去搜这个文件名，然后下载一个同名文件往系统目录里一丢，运气好的当场能进游戏，运气不好的开机就崩、其他程序跟着报错。问题的根子往往不在那一个文件上，而在DirectX 旧组件的版本链和安装介质本身。这篇文章就是把这几年我处理 d3dx9_26.dll 这类报错攒下来的经验完整拆一遍：先讲清楚这个文件为什么会存在、为什么会缺，再讲组件补齐的正确顺序和安装介质的核对方法，最后给一份可以直接对着查的问题速查表和避坑清单。不管你是刚上手折腾老游戏的新手，还是已经装过几轮运行库的老玩家，都能从里面找到能直接抄的步骤。

1. 先搞明白 d3dx9_26.dll 到底是什么东西

1.1 DirectX 运行时的分层结构

很多人把 DirectX 当成一个"软件"，装一次就完事，这个理解偏差是后面所有麻烦的源头。DirectX 更像是一套按年代叠加的积木：最底下是驱动层和硬件抽象，中间是各个版本的运行时核心（d3d9.dll、d3d11.dll、d3d12.dll 这些），最上面还有一层叫 D3DX 的工具库，专门给开发者提供数学运算、贴图加载、着色器编译之类的现成函数。d3dx9_26.dll 就属于最上面那层。

关键在于，D3DX 这层库是按构建号分文件的。微软在 DirectX 9 的漫长生命周期里，前后发布了几十个版本的 D3DX9 库，文件名从 d3dx9_24.dll 一直排到 d3dx9_43.dll，中间每一个数字对应一次 SDK 更新。游戏在编译时链接的是哪一个构建号，运行时就只认那一个文件名。它不会说"我找个新版的顶上"，链接关系是写死在导入表里的。这就是为什么你把最新的 DirectX 装了一遍，老游戏照样报"找不到 d3dx9_26.dll"——不是没装 DirectX，而是没装那一个特定构建号的库。

理解这一点之后，很多看起来玄学的现象就说得通了：为什么同一台机器上有的老游戏能跑、有的不能；为什么装了所谓"最新版 DirectX"之后报错反而更多；为什么网上随便下载的那个同名文件放进去之后游戏闪退。全都是同一个原因——版本对应关系被破坏了。

1.2 为什么偏偏是 26 这个数字

有人会问，26 是不是代表"DirectX 9.0 的第 26 版"？不是。这个数字是 D3DX 库的内部构建序号，跟 DirectX 的主版本号没有对应关系，也不是越大越新就一定向下兼容。实际经验里，d3dx9_24 到 d3dx9_43 这一整段文件是并存的，它们会同时躺在系统目录里，谁用到谁。一个 2005 年前后发行的游戏可能引用 24 或 25，2006 年上半年的一批游戏集中在 26 到 30 之间，往后逐年递增。

之所以 d3dx9_26.dll 这个报错特别高频，我个人的观察是它恰好处在 2006 年前后那一波游戏的高峰期，而那个时间段的游戏恰好是国内玩家留存最多、翻出来重玩比例最高的一批。所以与其说这个文件有什么特殊性，不如说它代表的是一个统计意义上的"高频样本"。

另外一个容易踩的坑是：32 位和 64 位是两套完全独立的文件。老游戏绝大多数是 32 位的，它只会去读 SysWOW64（64 位系统上）或者 System32（32 位系统上）里那一份 32 位版本。你手动放文件的时候如果放错了目录，或者放了个 64 位版本，游戏依然会报错，而且报错信息一模一样，看不出区别。这一点我在后面第三部分会详细展开。

1.3 报错背后的三种不同性质的问题

同样是"找不到 d3dx9_26.dll"，实际成因可以分成三类，处理方式完全不同：

区分这三类的意义在于：第一种是最常见的，处理最简单；第二种最麻烦，因为它往往还伴随其他程序异常；第三种最容易被误判成第一种，然后你去反复重装 DirectX，装十遍也没用。

我处理过一个特别典型的案例：一台机器上 d3dx9_26.dll 明明存在（用资源管理器能看到），但游戏就是报缺失。最后查出来是这个文件被杀软隔离过，虽然显示了图标，但实际是个 0 字节的占位文件。所以只看"文件在不在"是不够的，还要看文件大小和数字签名。右键属性里如果看不到微软的数字签名，那基本可以判定这份文件有问题。

2. 报错定位思路：先分清 DLL 缺失还是组件链断裂

2.1 三种典型报错文案的差异

报错文案的措辞其实藏着信息量，认真读能省下大量试错时间。

第一种是"无法启动此程序，因为计算机中丢失 d3dx9_26.dll。尝试重新安装该程序以解决此问题"。注意这里写的是"丢失"，且直接指向游戏 exe，这是最标准的真缺失场景，系统在解析导入表的时候就没找到这个文件。

第二种是"应用程序无法正常启动(0xc000007b)"，有时伴随 d3dx9 字样。这个错误码代表位数不匹配——32 位程序加载了 64 位 DLL，或者反过来。遇到 0xc000007b 就别再去补 d3dx9 了，方向应该转向"我到底往哪个目录放了什么位数的文件"。

第三种是弹窗只说"缺少 XXX 组件"，但没说具体文件名，或者游戏能进主菜单、一读地图就崩。这类情况通常是组件链的更深层出问题，比如显卡驱动版本太老导致 D3D9 设备创建失败，或者系统的某些运行库（VC++ 运行库）没装。这时候 d3dx9_26.dll 只是链条里最容易暴露出来的一环，不是真正的病根。

我的习惯是拿到报错先做一件事：把弹窗原文一字不差地记下来，尤其是错误码。很多人在搜索的时候会自己"概括"成"d3dx9 报错"，结果搜出来的方案全是针对第一种情况的，方向一开始就偏了。

2.2 依赖链排查：从游戏 exe 到系统目录

想真正定位，得学会顺着依赖链往下走。Windows 上有一类工具叫依赖查看器，能直接把一个 exe 的导入表展开成树。你可以用系统自带的命令行工具做一个轻量版排查，也可以借助第三方依赖分析工具。我一般用系统自带的 PowerShell 走一遍基础检查：

# 检查目标文件是否真实存在，并输出大小与版本信息 $paths = @( "$env:windir\SysWOW64\d3dx9_26.dll", "$env:windir\System32\d3dx9_26.dll" ) foreach ($p in $paths) { if (Test-Path $p) { Get-Item $p | Select-Object FullName, Length, LastWriteTime (Get-Item $p).VersionInfo | Select-Object FileVersion } else { Write-Output "缺失: $p" } }

跑完这段，你会得到四个关键信息：文件在不在、多大、什么时候写进去的、版本号是多少。正常的微软原始文件大小是固定的（量级在几百 KB），如果显示 0 字节或者几十字节，那就被人动过手脚。LastWriteTime也很有用，如果它跟其他系统文件的时间戳明显对不上，说明是后来手动塞进去的。

依赖链往下走的话，还要检查 d3d9.dll 是不是在。这个是 D3D9 的核心，如果它缺失或者版本异常，即使 d3dx9_26.dll 齐全，游戏照样进不去。再往下是显卡驱动暴露的用户态接口，这一层出问题的表现通常是"能进游戏但画面全黑"或者"进游戏直接回到桌面"，不会弹 DLL 缺失。

2.3 判断安装介质是否有问题的四个信号

这里说的"安装介质"，指的是你手上那份用来装游戏的原始来源：光盘、镜像文件、下载下来的安装包、整合版压缩包等等。当 d3dx9_26.dll 报错反复出现、补组件也补不进去的时候，就该怀疑介质本身了。

第一个信号是安装过程中出现过读取错误但被忽略。光盘有划痕、镜像下载不完整，都可能让安装程序跳过某些文件。这时候游戏主程序装进去了，但它自带的运行库目录没装全。表现就是主程序能双击，但一运行就报 DLL 缺失。

第二个信号是安装目录下找不到运行库文件夹。很多正规发行的游戏会在安装目录里带一个 Redist、DX、_CommonRedist 之类的子目录，里面放着它自己依赖的 DirectX 运行时和 VC++ 运行库。装完游戏之后如果你能在安装目录里看到这个东西，直接进去跑里面的安装程序，比去外面找第三方来源靠谱得多。反过来，如果目录里干干净净什么都没有，那这份介质很可能是被"精简"过的版本。

第三个信号是版本号和补丁链对不上。老游戏往往有一连串补丁，补丁之间有严格的顺序要求。跳着装、或者装了来源不明的"整合补丁"，有可能把原始文件覆盖成不匹配的版本。

第四个信号是校验值不匹配。如果你手上的是镜像文件，用哈希校验工具算一遍 SHA-256，跟官方公布的对比。这一步很多人嫌麻烦跳过，但它是判断介质完整性的唯一硬标准。我见过太多次"明明下载完了却装不上"的情况，最后都是哈希对不上，重新下载一遍就好了。

提示：判断顺序建议是"先软件后介质"。先确认系统里的 DirectX 组件齐不齐，再回头怀疑安装源。反过来做，很容易在重新下载上浪费几个小时，结果发现其实是系统缺文件。

3. 旧组件补齐的实操路径

3.1 DirectX 9.0c 终版运行时的正确安装姿势

补 D3DX 库的正规途径只有一个：安装 DirectX 9.0c 的最终版运行时。这个包的最后一个版本发布于 2010 年 6 月，里面包含了 d3dx9_24 到 d3dx9_43 的全部构建号，一次性把整段补齐。它跟系统自带的 DirectX 11/12 是并行共存关系，不会互相覆盖，装它不会把新系统搞坏，这一点可以放心。

安装的关键动作有三个。第一，解压到一个不含中文和空格的路径，比如D:\dx9redist。这个包是个自解压文件，双击之后它会先问解压到哪，很多人直接默认放到临时目录，路径里带一堆奇怪字符，后面安装程序读配置文件就会出错。

第二，进入解压目录后不要双击 setup.exe，而是用管理员权限从命令行运行：

# 在解压目录下以静默方式安装，日志留在当前目录 DXSETUP.exe /silent

静默模式的好处是它会跳过所有已经存在的更新版本文件，只补缺失的部分，不会强行覆盖系统里的新版本。这一点比图形界面的默认行为要安全得多，图形界面里有些选项如果选错，可能会把较新的文件降级。

第三，装完之后不要急着重启。这个安装包对重启不敏感，重启反而可能让某些后台的驱动更新流程打断写入过程。先直接去跑游戏，报错消失就说明成功了。如果还在报，那就该进入下一节的排查流程，而不是继续装第三遍。

在 Windows 10/11 上安装时，可能会弹一个"此程序可能不适用于当前系统"的兼容性提示，直接选"是，继续运行"就行。这类老安装包的清单文件里写的支持系统列表只到 Vista/Win7，系统只是照本宣科地提示一下，实际安装是没问题的。

3.2 系统自带组件的启用与检查

有些情况下问题不在 d3dx9，而在系统层的 DirectX 功能被关掉了。Windows 有个"旧版组件"的开关，位置在控制面板的程序功能里。默认情况下它一般是开着的，但某些"优化脚本"或者"精简系统"会把它关掉。

检查方式很快：

# 查看旧版 DirectX 组件（DirectPlay）的启用状态 Get-WindowsOptionalFeature -Online -FeatureName DirectPlay | Select-Object FeatureName, State Get-WindowsOptionalFeature -Online -FeatureName DirectX | Select-Object FeatureName, State

如果 State 显示 Disabled，用Enable-WindowsOptionalFeature -Online -FeatureName DirectPlay打开即可（需要管理员权限）。DirectPlay 主要影响的是更老的一批联机游戏，跟 d3dx9_26.dll 不一定直接相关，但既然排查了，顺手看一眼不亏。

真正跟 d3dx9 相关的系统层检查是显卡驱动的 D3D9 支持。现在的显卡驱动早就把重心放在 D3D11/12 上了，但主流厂商的驱动包里依然保留了 D3D9 的用户态组件。如果你用的是非常老或者非常新的驱动（尤其是某些精简版驱动），有可能这部分被裁掉了。判断方法很简单：随便找一个能跑的 D3D9 程序试试，如果所有 D3D9 程序都异常，那就是驱动层的问题，去显卡官网下完整版驱动。

3.3 32 位与 64 位目录的双份拷贝问题

这是老游戏折腾里最高频的一个坑，值得单独讲。

在 64 位 Windows 上，系统有两个目录：C:\Windows\System32和C:\Windows\SysWOW64。名字很容易误导人——System32 里放的是 64 位文件，SysWOW64 里放的才是 32 位文件。这个命名是历史遗留，WOW64 的意思是"Windows 32-bit on Windows 64-bit"。很多人凭直觉认为 32 位的文件应该放 System32，结果放反了。

老游戏基本都是 32 位程序（Win32 编译），它们在 64 位系统上运行时会被 WOW64 层重定向，去读SysWOW64里的 DLL。所以：

看到 0xc000007b 错误码的时候，百分之八十是这张表没对上。正确的做法是：装官方运行包，它会自动往两个目录各写一份，不用你操心。只有在你被迫手动补文件的时候，才需要严格按这张表来。

还有一个更隐蔽的变体：游戏安装目录下自己带了一份 d3dx9_26.dll。Windows 加载 DLL 的顺序是"先看程序所在目录，再看系统目录"。所以如果游戏目录里那份是坏的或者位数不对，系统目录里明明有好的也没用，它优先读坏的。排查的时候记得把游戏安装目录也扫一遍，尤其注意那些体积异常小的 DLL。

注意：手动往系统目录复制 DLL 属于"应急手段"，不是常规方案。这么做会绕过版本校验，一旦后续系统更新或者安装其他软件，很容易出现版本冲突，而且出问题之后很难追溯是哪一份文件被替换了。

4. 安装介质核对：镜像、补丁与版本号

4.1 安装介质完整性校验

前面提到哈希校验，这里展开讲具体怎么做。

如果你手上的是 ISO 镜像，步骤是这样的：先用哈希工具算出文件的 SHA-256，然后跟官方公布的对比。命令行方式最快：

Get-FileHash -Algorithm SHA256 "D:\game_setup.iso" | Format-List

Get-FileHash是 Windows 自带的，不用装任何东西。拿到结果之后逐字符对比，任何一个字符不一样都说明文件有问题。这时候的处理方式是重新下载，而不是"先试试能不能装上再说"——装上去之后出问题，你要花更多时间回头怀疑是系统问题还是介质问题。

如果手上是实体光盘，没法算哈希，那就靠肉眼观察：把盘拿起来对着光看，有划痕、有霉点、有变色的地方都要留意。装机的时候如果安装程序在某一步卡很久然后跳过，基本就实锤了。这种情况可以用专门的镜像制作工具把光盘的内容尽量读出来做成镜像，读的时候开启错误重试，能救回一部分数据。

如果是数字下载的安装包，除了哈希，还要看一眼文件体积。有些下载工具会因为网络中断生成一个体积偏小的文件，扩展名看起来正常，双击也能打开安装向导，但装到一半报错。体积明显小于预期的时候，直接重新下载，别浪费时间。

4.2 老游戏的补丁链顺序

2000 年代中期的游戏，补丁文化跟现在完全不一样。那时候没有自动更新，补丁是一堆独立的 exe，而且经常有严格的先后顺序。常见的坑有三种。

第一种是官方补丁之间必须按版本递增安装。1.0 → 1.1 → 1.2 这样一步步来，直接从 1.0 跳到 1.2 是有可能失败的，因为 1.2 的补丁程序内部假设当前已经是 1.1 状态。判断依据是补丁说明里有没有写"适用于 XX 版本"。

第二种是官方补丁和第三方补丁冲突。第三方补丁通常会替换主程序文件，而官方补丁修改的是同一批文件。先装第三方再装官方，官方补丁会检测到文件被改过而拒绝安装；先装官方再装第三方，第三方可能因为版本不匹配而出错。顺序应该是官方全部装完并确认能进游戏，再考虑第三方内容。

第三种是补丁自带的运行库没装。这一点直接关联到我们的主题——有些补丁包里会附带更新版的运行库，如果你跳过它、只复制主程序文件，就可能出现主程序引用了新构建号的 D3DX 库，而系统里没有的情况。所以装补丁的时候，包里带的安装程序一律跑完整流程，不要手工复制文件。

我在处理这类问题时养成了一个习惯：新建一个文本文件，把装过的每一个补丁的名称、版本、安装结果记下来。看起来有点小题大做，但一旦出问题，这份记录能让你在几分钟内定位到是哪一步引入的异常，而不是从头再来一遍。老游戏的安装过程动辄半小时，重来一次的代价很高。

4.3 打包版与整合版的坑

网上流传的老游戏版本里，有一类是把游戏本体、补丁、运行库全部打包在一起的"整合版"或者"绿色版"。这类版本省事，但也埋了不少雷。

第一个雷是运行库被精简。打包者为了让体积小一点，会把安装目录里的 Redist 文件夹删掉，反正"系统里应该有"。结果就是你在自己机器上装完，缺 d3dx9_26.dll。

第二个雷是主程序被改动过。有些绿色版为了让游戏在新系统上直接跑，会修改主程序的兼容性标志或者内置配置。改动本身可能是善意的，但如果改得不彻底或者引入了新依赖，就会出现"别人能跑我不能跑"的情况。

第三个雷是文件被重新压缩过。多次压缩解压会带来极小的概率性损坏，尤其是老式压缩格式在大文件上的表现。这个概率很低，但一旦碰上，表现就是随机某个文件读不出来，非常难查。

我的建议是：如果游戏有正规发行渠道能获取，优先用正规来源，安装完之后自己去补运行库，这个过程可控。整合版适合当作"实在找不到原版时的备选"，用的时候记得自己检查一遍安装目录，看看 Redist 在不在，缺什么补什么。

5. 修复工具怎么用才不出问题

5.1 修复工具的工作原理

市面上流传的 DirectX 修复工具，核心逻辑其实不复杂：扫描系统目录里关键的 DirectX 相关 DLL，跟内置的一份文件清单做比对，发现缺失或者版本异常的就从自带的资源里释放一份出来补上。这件事本身是有价值的，尤其是对于那些手动补文件会补错目录、补错位数的用户来说，工具能自动判断位数并写到正确位置。

问题出在"内置文件清单"这个环节。不同工具带的清单版本不一样，有的工具为了兼容更多老游戏，会往里塞一大批历史版本的 DLL；有的工具则只带最常见的几个。清单覆盖范围决定了它能修好哪些问题。d3dx9_26.dll 属于比较冷门的构建号，如果工具的清单里刚好没有这一项，你跑十遍它也修不好。

另一个关键点是修复的判定标准。好的工具会检查文件的数字签名和版本号，只替换明确异常的；粗糙的工具只看文件存不存在，存在就跳过、不存在就写入。后一种在处理"文件在但是坏的"这种情况时会失效。

5.2 使用顺序与注意事项

如果决定用工具，我建议的顺序是这样：

先用官方手段走一遍。装 DirectX 9.0c 终版运行时，装游戏自带的 Redist，把 VC++ 各年份运行库补齐。这一轮走完之后大概率就好了。真正需要工具介入的，是那些官方手段覆盖不到的边角情况。

用工具的时候有三个注意事项。第一，关闭杀毒软件的实时防护，或者至少把工具加入白名单。工具的行为是往系统目录写文件，这在杀软看来跟恶意行为高度相似，被拦截的话工具会显示"修复成功"但实际没写进去。第二，先备份再修复。至少把SysWOW64目录下所有 d3dx9_*.dll 复制一份出来，出问题能回滚。第三，不要连续跑多轮。有的工具修完一轮之后会提示"还有 N 个问题"，诱导你继续修，这时候要停下来看看到底是什么问题，而不是一路点下去。

关于"免费版"和"增强版"的区别，主要在于内置文件的覆盖范围和处理逻辑的细致程度。增强版一般覆盖更全，对冷门构建号的支持更好。但这不意味着增强版一定适合你——如果问题根本不在文件缺失，用哪个版本都没用。

5.3 什么时候不该用修复工具

有三种情况我建议不要用工具。

第一种是系统本身运行正常，只有某一个老游戏报错。这种情况问题极大概率在游戏本身或者它的安装介质上，去动系统目录反而会引入新问题。正确的做法是从游戏自带的 Redist 入手。

第二种是已经确认系统目录里的文件齐全且签名正常。这时候报错的原因在更上层，工具修不了。

第三种是你在做系统盘的精简或者定制。修复工具写入的文件位置和版本是不可控的，会打乱你的定制计划。

提示：判断到底该不该用工具，有一个很快的标准——如果"只有这一个游戏有问题，其他程序都好"，那问题基本不在系统层，别去动系统；如果"所有老游戏都有问题"，那才轮到系统层的修复手段上场。

6. 常见问题速查与排查技巧

6.1 一份可以直接对着查的问题速查表

表格里的最后两行对应的是热搜里另外两个高频问题，虽然跟 d3dx9_26.dll 不是同一个病，但经常在同一批老游戏上一起出现，顺手列进来省得你另外搜。

关于 "DirectX 12 is not supported on your system" 这条：它的真实含义是游戏默认以 D3D12 渲染模式启动，而你的显卡或者系统不满足 D3D12 的最低要求。处理方式不是去"补 DirectX 12"，而是让游戏改用低版本渲染。具体做法因游戏而异，常见的是在启动参数里加-dx11或者-d3d11之类的开关，或者在游戏的配置文件里找渲染器选项。这类开关的命名各家不太一样，得去看该游戏的社区文档。硬要去升 DirectX 12 是走不通的，因为它不是一个可以独立安装的软件包，而是跟系统和显卡驱动绑定的。

关于音频那条报错：它通常出现在老的多媒体程序上，提示"当前音频无法播放。DirectX 驱动程序未正确安装或音频设备被禁用"。这个跟 DLL 缺失是两回事，处理方向是检查系统的播放设备有没有被禁用、默认设备的采样率和位深是不是程序不支持的格式（老程序常常只支持 16 位 44100Hz），必要时在声音设置的高级选项里把默认格式调低一档。

6.2 几条用血换来的避坑经验

第一条，别用单文件下载站的文件。搜 d3dx9_26.dll 出来的结果里，大量是提供单个 DLL 下载的页面。这些文件来源不明，有的被捆绑了东西，有的干脆版本不对，有的虽然是原版但被重新打包压缩过。就算你运气好拿到的是好文件，手动放目录这件事本身还是有位数搞错的风险。正规运行包的体积也就一百来兆，下载一次就能覆盖所有构建号，比一个个找文件划算得多。

第二条，新建一个"老游戏环境"的记录文档。我自己的做法是维护一个文本文件，记录这台机器上装过哪些运行库、什么时间装的、什么版本。折腾老游戏的过程中，系统状态会慢慢变得复杂，有这份记录，回溯问题的效率能提高一倍以上。

第三条，优先用游戏自带的东西。安装目录里的 Redist、DX、_CommonRedist 这些文件夹，是发行方针对这个游戏测试过的版本组合，兼容性最有保证。很多人习惯性地跳过安装程序里的"安装运行库"步骤，觉得浪费时间，结果省下的两分钟要用两小时来找补。

第四条，装完立刻测试，不要攒着一起测。装完运行库马上跑游戏，出问题能立刻定位到刚做的这一步。如果连续装五个补丁再测试，一旦报错，你得花时间去二分排查是哪一步引入的。

第五条，光盘和镜像要留档。老游戏的光盘会老化，镜像文件放在硬盘里也可能因为各种原因损坏。我现在的习惯是拿到一份完整的安装介质之后，算一遍哈希存进记录文档，然后把镜像再复制一份到另一块盘上。这事做起来只要几分钟，但当你五年后想再玩一次的时候，会发现这个习惯救了大命。

6.3 装完还是报错时的后续动作

如果前面的步骤都走完了还报错，按这个顺序再走一遍，基本能覆盖绝大多数情况。

第一步，确认报错文案有没有变化。有时候补完组件之后，报错从 d3dx9_26.dll 变成了另一个文件名。这说明你补的那一步生效了，只是还有下一层缺失。这时候按新报错的文件名继续处理，思路是一样的。

第二步，用依赖分析工具看完整的依赖树。重点看有没有哪一层是"找到了但加载失败"，这种比"完全找不到"更隐蔽。加载失败的常见原因是位数不对或者依赖的下级库缺失。

第三步，检查事件查看器。系统日志里会记录应用程序崩溃的详细信息，包括失败模块的名称和偏移地址。这个信息在官方论坛提问的时候非常有用，能省下大量来回确认的时间。

第四步，考虑兼容性设置。老游戏在新系统上有时候需要右键属性里设置兼容模式，或者勾上"以 640×480 分辨率运行"之类的选项。这类设置本身不解决 DLL 缺失，但能解决一部分进游戏之后立刻退出的问题。

第五步，如果实在找不到原因，把游戏装到一台干净的系统或者虚拟机里试试。这是一个很好的"对照组"：如果干净系统上正常，说明问题出在你当前系统的某个历史改动上；如果干净系统上也不行，那问题就在介质或者游戏本身。这个二分法能一下子把排查范围砍掉一半。

注意：装到虚拟机里测试时，虚拟机的显卡是模拟出来的，D3D9 支持是有限的。它能帮你验证"文件层面"的问题，但不能用来验证画面和性能相关的问题，别把结论搞混。

最后再分享一个小技巧。处理这类老游戏的运行环境问题，"快"往往是陷阱，"可回溯"才是效率。我现在每次动手之前会先建一个还原点，或者干脆在动手前把关键目录打个压缩包存起来。听起来很笨，但当你发现某次操作引入了新问题、需要回退的时候，这个笨办法能让你三十秒恢复现场，而不是花一下午重装系统。