MDAC 2.8完整安装包：解决没有注册类别与OLE DB提供程序缺失

简介：MDAC2.8（微软数据库访问组件）完整安装包，面向在老旧 Windows 环境中使用 Access 等数据库、遭遇“没有注册类别”或“未找到提供程序。该程序可能未正确安装”报错的开发与运维人员，是一份用于修复数据访问组件注册与依赖缺失问题的离线文件合集。压缩包共 82 个文件，约 4.29MB，以 dll 动态链接库为主，另有 rll 资源库、tlb 类型库、inc 声明文件及 reg 注册表脚本等，覆盖 ADO、OLE DB、MSADC 等组件所需的核心文件。已有 2675 人学习下载，说明其在旧系统兼容与报错排查场景中具有一定参考价值。包内保留 mdac.inf 安装信息文件、所需文件目录及“请阅读安装方法”说明，目录按组件来源分门别类，便于按缺失项查找和补齐文件，适合需要恢复 XP 类系统数据库访问能力、对照组件清单排查依赖的人使用。

1. 一个「没有注册类别」把我拽回旧机房：MDAC 2.8 到底给谁装

接手一套老系统的迁移，最先出问题的往往不是业务代码。客户端双击刚出来就弹「没有注册类别」，点掉之后再弹「未找到提供程序。该程序可能未正确安装」，日志里只有一行 80040154，连堆栈都没有。我第一次遇到时，第一反应是客户端装错了版本，于是卸载、重装、换目录、换账号，折腾一下午没用。后来把进程位数、系统架构、组件注册表一起对了一遍，才确认问题根本不在程序本身，而在系统那层数据库访问组件上。

MDAC 2.8 完整安装包就是给这种场面用的：它不是给新机器装新功能的，而是给还在跑 ADO / OLE DB 的老客户端把底层组件补齐、补正、补回注册。适合的人群很明确：维护 2000/XP/2003 时代遗留系统的人，跑 32 位 ERP、报表工具、老式上位机的人，以及被「未找到提供程序」反复折磨、已经不相信「重装客户端」这条路的人。

装不好会怎样？不是慢一点、卡一下，是连接串写得再对也连不上，是换 DSN 换账号都没用，是只能眼睁睁看着一台机器废掉。所以这篇按「先对版本、再解包安装、然后配注册和连接串、最后验证能跑通」的顺序写，中间那段排错是重点，都是我踩过的。

2. 版本对表：MDAC 2.8 完整安装包在哪些系统上才真正生效

装 MDAC 最容易犯的错，是先下载、再找机器，装完发现没变化，还以为包是坏的。正确顺序反过来：先确认这台机器的系统版本和进程位数，再决定是「装」还是「修」。这两个动作看着像一回事，其实完全不同——装是覆盖，修是把系统自带的那份重新注册一遍。

2.1 先看位数和系统自带版本，再决定动手

位数这件事在 MDAC 上不是细节，是分水岭。MDAC 2.8 这一代组件天生是 32 位的，64 位系统上能跑，但只在 32 位进程里跑。也就是说，一个编译成 x64 的程序，哪怕机器上 MDAC 装得再完整，它照样报「没有注册类别」——因为它在 64 位的注册表视图里找组件，那里根本没有。

所以第一步永远是两条命令：

:: 看系统架构和版本，决定后面走哪条路 systeminfo | findstr /C:"OS 名称" /C:"系统类型" /C:"OS 版本" :: 看当前系统里登记的组件版本，注意这里读的是 64 位视图 reg query "HKLM\SOFTWARE\Microsoft\DataAccess" /v FullInstallVer :: 32 位组件在 64 位系统上要读 WOW6432Node 这一支 reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\DataAccess" /v FullInstallVer

第一条命令里的「系统类型」直接告诉你 x86 还是 x64。第二条和第三条是重点：FullInstallVer是完整安装版本，同一个系统上两个视图的值可能不一样，甚至只有一支存在。如果 WOW6432Node 那支查不到，说明这台机器上压根没装过 32 位组件，后面所有 32 位程序都会报未找到提供程序。

常见对照关系我整理成一张表，装之前先对一遍，能省掉一半返工：

这张表里最容易翻车的是第四、第五行。很多人拿着 MDAC 2.8 的包往新系统上怼，安装进度条走到一半回滚，退出码 1603，然后就开始怀疑包被改过。不是的，是系统版本比它新，安装器做了版本比较，主动拒绝。

2.2 MDAC 2.8 与 2.8 SP1 的取舍

同一代组件通常有两个包：RTM 和 SP1。文件名看起来差不多，装上去行为不一样。判断依据不要看文件名，也不要看下载页的说明，就看装完之后FullInstallVer读出来的那一串数字，末段不同就是不同的包。

我一般的取舍是：老系统、干净环境、没有历史包袱，装 RTM 就够，装完把该注册的注册一遍；如果这台机器之前装过别的版本、注册表里已经有一堆残留，那就直接上 SP1，它对已存在组件的替换逻辑更稳一些，回滚也更干净。

注意：不要在同一个系统上反复交替装 RTM 和 SP1。组件文件被两个包来回覆盖，Version和FullInstallVer会出现对不上的情况，之后再用组件检查器扫描，报出来的差异项能列一屏，谁也说不清哪个才是当前真实状态。

还有一种情况要知道：MDAC 2.8 装上之后，在控制面板的「添加或删除程序」里是看不到卸载入口的。这是设计如此，不是装坏了。所以装之前必须留后悔药，别指望事后卸载。

2.3 安装前必须做的三件备份

这三件事花不到五分钟，能在后面省掉几个小时。

:: 1. 把当前组件相关注册表整个导出一份，出问题直接对比 reg export "HKLM\SOFTWARE\Microsoft\DataAccess" D:\backup\dataaccess64.reg /y reg export "HKLM\SOFTWARE\WOW6432Node\Microsoft\DataAccess" D:\backup\dataaccess32.reg /y :: 2. 记下当前的版本号，装完用来判断到底有没有变化 reg query "HKLM\SOFTWARE\Microsoft\DataAccess" /v FullInstallVer > D:\backup\ver_before.txt :: 3. 手动建一个系统还原点（命令行方式，适合批处理里跑） wmic shadowcopy call create Volume='C:\'

第一条命令导出的两个 reg 文件，最大的用处不是恢复，是对比。装完发现不对劲，直接把新旧两份 reg 摆在一起看，哪几个键被删了、哪几个值被改了，一目了然，比猜快得多。第三条的还原点命令只在部分系统上有效，如果没有生效，就老老实实去系统属性里手动点一下，别嫌麻烦。

3. 落地安装：mdac_typ.exe 的解包、静默参数与回滚

MDAC 2.8 的安装包是一个自解压外壳套着真正的安装器，外壳叫mdac_typ.exe，里面干活的叫dasetup.exe。搞清楚这层套娃关系，很多「双击没反应」「一闪而过」的问题就有解释了——外壳解压完之后把参数传给了内层，参数传错，内层直接退出，界面上什么都不留。

3.1 解包：把 mdac_typ.exe 拆成看得见的文件

我现在的习惯是不直接双击，先解包。理由很简单：解包之后可以单独拿出某个 dll 手工注册，也可以在安装器拒绝覆盖的系统上手动拷贝文件，这条路在救急时特别有用。

:: 方式一：用自解压包自带的参数把文件放出来，只解压不安装 :: /c 表示执行后面的命令，/t: 指定解压目标目录 mdac_typ.exe /c /t:D:\mdac28 :: 方式二：上面的参数不生效时，直接用压缩工具打开 mdac_typ.exe 解压到同一目录 :: 解压完看一眼目录结构，确认关键文件都在 dir D:\mdac28 /b

解压出来之后，目录里通常能看到这几类文件，认一遍心里有底：

这张表里最值得记的是mdac.inf。很多人装完报错就想着再装一遍，其实正确做法是用这个 inf 让系统自己把组件重新铺一遍，效果比重复跑安装包好得多，后面 3.3 会写具体命令。

3.2 静默安装参数与退出码

批量部署或者远程操作时，图形界面是累赘。静默安装的参数组合是固定的：

:: 全静默安装，装完不自动重启 :: /q:a 是外壳静默，不弹解压进度窗 :: /c: 把后面的字符串交给解压出来的安装器执行 :: dasetup.exe /q 静默 /n 不重启 mdac_typ.exe /q:a /c:"dasetup.exe /q /n" :: 装完立刻取退出码，这一步不能省 echo %ERRORLEVEL%

参数逐个说清楚：/q:a控制的是外层自解压壳，让它别弹窗口；/c:是转交，冒号后面整串原样传给内层；dasetup.exe的两个开关，/q是静默，/n是抑制重启。少写/n的后果是机器装完直接重启，远程会话当场断掉，如果这台机器上还跑着别的服务，就是一次小型事故。

退出码怎么读：0是成功，3010是成功但需要重启，1603是致命错误，1602是用户取消。看到1603别急着重装，先去%TEMP%下找日志。安装器会往临时目录写一个以dasetup开头的日志文件，翻最后两百行，通常能看到具体是哪个文件写不进去、哪个键没权限。

提示：装之前把TEMP和TMP指到一个固定目录，比如set TEMP=D:\temp再执行安装。默认临时目录里文件太杂，日志找起来费劲，而且有些机器上临时目录所在盘空间不够，解压到一半失败，报出来的错误跟磁盘空间一点关系都没有。

3.3 装崩了怎么退回去：mdac.inf 与系统还原

MDAC 2.8 没有卸载入口，所以「退回去」这个动作要换思路：不是卸载新装的，而是让系统把自带的那份重新铺一遍，把被覆盖的文件和注册项顶回来。

:: 用系统自带的组件安装脚本重装一遍，等价于右键 mdac.inf 选「安装」 :: 132 表示不弹提示、不重启 rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 %windir%\inf\mdac.inf :: 顺手校一遍系统文件，被第三方安装包替换掉的系统 dll 会被换回来 sfc /scannow

第一条命令是我最常用的救命命令。它的作用是让系统按 inf 里记录的清单，把组件文件从系统缓存里重新释放一遍，并把注册项重写一遍。注意它用的是%windir%\inf下系统自带的那份 mdac.inf，不是你解包目录里那份——这两份内容可能不同，系统那份才对应这台机器原始的组件状态。

第二条命令是兜底。有些安装包会把系统目录下的 dll 直接覆盖成自己的版本，文件版本号变了但注册信息没跟着更新，表现出来就是「文件在、类没注册」。sfc /scannow跑完，这类问题能解决一大半，代价是耗时比较长，适合放在下班前跑。

如果两条都跑了还是不行，就上还原点。这也是为什么第 2 章要求装之前先建一个——真到这一步，回滚是唯一省时间的选项，继续在注册表里抠只会越抠越乱。

4. 注册与连接：把「未找到提供程序」按回组件层

到这一步，包已经装上了，注册表里也能查到版本号，但程序还是连不上。这时候问题基本落在两个地方：组件没注册到正确的视图里，或者连接串里的提供程序名跟实际注册的对不上。这两件事必须一起看，分开查一定绕圈。

4.1 两套注册表视图：32 位与 64 位的分岔口

64 位系统上，注册表有两套视图。32 位进程读的是HKLM\SOFTWARE\WOW6432Node\...这一支，64 位进程读的是HKLM\SOFTWARE\...。同一台机器，同一个组件，两个进程看到的世界完全不同。

这就是「在我机器上好好的，到客户那台就报没有注册类别」的经典成因——开发机是 32 位系统，只有一套视图，怎么都对；客户的 64 位系统上，程序被编译成了 x64，去 64 位视图里找 32 位组件，找不到。

:: 明确指定读 32 位视图，比手写 WOW6432Node 路径更稳 reg query "HKLM\SOFTWARE\Microsoft\DataAccess" /v FullInstallVer /reg:32 :: 读 64 位视图 reg query "HKLM\SOFTWARE\Microsoft\DataAccess" /v FullInstallVer /reg:64

/reg:32和/reg:64这两个开关很实用，它能让你在命令行里直接模拟某个位数的进程会看到什么，不用真的去编译两个版本的程序试。两条命令输出不一致，问题就定位了：不是组件没装，是装错了视图。

解决方向只有两个，选一个就行：要么把程序的目标平台改成 x86，让它去读 32 位视图；要么给 64 位进程找 64 位的提供程序。前者改动小，后者要看有没有对应版本的组件。老系统上我一般选前者，因为配套的第三方库多半也只有 32 位版本，改成 x64 会连带出一串新问题。

4.2 手工注册的顺序：先 ADO 后提供程序

有些场景下安装器跑完了，文件也确实在，但类就是没注册。原因通常是安装过程中某个 dll 被占用，注册那一步跳过了，安装器不报错，静默失败。这种情况手工补注册最快。

:: 必须用 32 位的 regsvr32 注册 32 位组件，路径在 SysWOW64 下 :: 顺序很重要：先注册 ADO 核心，再注册各提供程序 C:\Windows\SysWOW64\regsvr32.exe /s "C:\Program Files (x86)\Common Files\System\ado\msado15.dll" C:\Windows\SysWOW64\regsvr32.exe /s "C:\Program Files (x86)\Common Files\System\ado\msdasql.dll" C:\Windows\SysWOW64\regsvr32.exe /s "C:\Program Files (x86)\Common Files\System\ado\sqloledb.dll" :: 注册完立刻验证，别等程序跑起来再发现 C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files (x86)\Common Files\System\ado\msado15.dll"

路径这块有个坑要说清楚：32 位系统上组件在C:\Windows\System32，64 位系统上 32 位组件在C:\Windows\SysWOW64，而regsvr32.exe本身也有两份。用 64 位的 regsvr32 去注册 32 位的 dll，会报模块加载失败，错误码看着像文件损坏，其实是位数不匹配。这个坑我踩过不止一次，血泪经验就一句：看到模块加载失败，先怀疑 regsvr32 用错了版本，再怀疑文件。

顺序为什么重要？因为提供程序 dll 在注册时会依赖 ADO 核心的类型信息，核心没注册上，提供程序那一步会静默跳过。/s参数是静默模式，成功失败都不弹框，所以第一次跑建议不加/s，看弹框确认每个都成功，确认完再写进脚本加/s。

4.3 连接串与提供程序名的对齐

组件注册好了，最后一步是连接串里的提供程序名必须跟实际注册的名字一模一样，差一个空格都不行。

; 走 ODBC 的 OLE DB 提供程序，依赖已经配好的数据源名 Provider=MSDASQL;DSN=erp_test;UID=sa;PWD=***; ; 直连 SQL Server，不依赖 DSN，部署时最省事 Provider=SQLOLEDB;Data Source=10.0.0.21,1433;Initial Catalog=erp_test;User ID=sa;Password=***; ; Access 单机库，这条只能在 32 位进程里用 Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\data\demo.mdb;

三条分别对应三种典型场景。第一条适合已经配好 DSN 的老系统，好处是改连接只改 DSN，不用动程序；坏处是多一层依赖，DSN 配错了报的错还是「未找到提供程序」，很容易误导。所以排查阶段我一般先用第二条直连，把组件层的问题和 DSN 层的问题分开，确认组件没问题，再回头查 DSN。

第三条要单独提醒：Microsoft.Jet.OLEDB.4.0只有 32 位版本，64 位进程调用必定报未找到提供程序。这不是装没装 MDAC 的问题，是永远不会有 64 位版本的问题。遇到这种，只能在编译目标上改 x86，或者换成支持双位数的其他提供程序。

还有一类报错要能区分开：「未找到提供程序」是组件层的问题，「SQL Server 不存在或访问被拒绝」是网络层或认证层的问题。后者说明提供程序已经加载成功了，卡在连接阶段，去查端口、协议、账号，别再去折腾注册表。

5. 避坑与排查：五条「没有注册类别」的现场记录

这一章是这篇里最该反复看的部分。下面五条都是真实遇到过的，按「现象 → 原因 → 解决」记，遇到类似情况直接对号入座。

第一条：装完版本号没变，安装器一闪而过。

现象是双击安装包，进度条刚出来就消失，回头查FullInstallVer，跟装之前一模一样，退出码 1603。原因是系统自带的组件版本比安装包里的高，安装器做了版本比较之后主动拒绝并回滚，日志里会有一行版本不满足的记录。解决办法不是反复重试，而是换路线：不要覆盖安装，改用rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 %windir%\inf\mdac.inf走修复，让系统把自带的那份重新铺一遍。修复完再查版本号，通常就正常了。

第二条：只在某一个程序里报错，别的程序都正常。

现象是同一台机器，老客户端连不上报「没有注册类别」，另一个小工具连同一个库一点问题没有。原因是两个程序的位数不同，一个 32 位一个 64 位，去的是两套注册表视图。解决方法是先用reg query ... /reg:32和/reg:64分别查一遍，确认哪套视图缺组件，然后要么补注册，要么把缺的那个程序改成 x86 目标重新编译。这种情况千万别整机重装组件，纯属浪费。

第三条：regsvr32 报模块加载失败，错误码看着像文件损坏。

现象是手工注册 dll 时弹「模块已加载，但找不到入口点」或者「无法加载模块」。原因有两个常见可能：一是用了 64 位的 regsvr32 去注册 32 位 dll，二是这个 dll 依赖的其他 dll 不在路径里，加载器在解析依赖时就失败了。先换C:\Windows\SysWOW64\regsvr32.exe重试，还不行就用依赖查看工具把这个 dll 的依赖树拉出来，看缺哪个。解决完通常还要顺手把缺的依赖一起注册。

第四条：Access 单机库连不上，报未找到提供程序。

现象是 SQL Server 那边一切正常，只要连.mdb文件就报错。原因是 Jet 引擎只有 32 位版本，程序是 64 位进程，或者这台机器上压根没装 Jet。解决方法是先把程序目标平台改成 x86，改完之后还是不行，再从解包目录里把msjet40.dll相关的文件补上并注册。这一步要注意，Jet 的注册不是靠 regsvr32 完成的，它是通过 inf 里的安装节铺进去的，所以正确做法还是走 3.3 那条 mdac.inf 修复命令。

第五条：安装到一半停住，日志显示文件被占用。

现象是进度条卡在某个百分比不动，最后报 1603，日志里能看到某个 dll 写入失败。原因是这台机器上还有进程加载着旧版本的组件，文件锁没释放，或者安全软件在实时扫描时锁了文件。解决办法是先停掉相关服务、关掉所有已经打开的客户端程序，临时关闭安全软件的实时防护，重启一次再装。装完记得把防护开回来。这条听着像废话，但确实是发生频率最高的一条，我现在远程操作前第一件事就是问一句「这台机器上还有谁在用」。

这五条覆盖了大部分现场，剩下的少数情况多半是权限问题——普通用户没有注册组件的权限，regsvr32报0x80070005。这种就别在用户会话里折腾了，用管理员身份开一个命令行，重新跑一遍 4.2 那组命令。

6. 装完怎么验证跑通：一个 .udl 文件胜过十次重装

组件装完、注册完，最怕的是「看着好了，一上线又崩」。所以验证这一步不能省，而且要验证到端到端——从提供程序枚举、到连接建立、到实际取到一行数据，全走一遍才算数。

我最常用的办法是.udl文件，这东西不用写代码，两分钟能出结论。在桌面新建一个文本文档，把扩展名改成.udl，双击打开，第一页「提供程序」标签里会列出这台机器上所有已注册的 OLE DB 提供程序。这一页本身就是个体检报告：如果列表里连Microsoft OLE DB Provider for SQL Server都没有，那说明注册这一步没成，后面不用试了。选中提供程序，切到「连接」页，填服务器、账号、库名，点「测试连接」，成功会明确提示。

这里有个隐藏的坑：在 64 位系统上双击.udl，打开它的是 64 位宿主，看到的是 64 位视图。而你的程序可能是 32 位的，两者看到的提供程序列表不一样。要验证 32 位那一侧，得显式用 32 位的宿主去打开：

:: 用 32 位的 OLE DB 核心打开 udl，验证 32 位视图下的提供程序注册情况 C:\Windows\SysWOW64\rundll32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile D:\test.udl

这一步做完，视图问题就彻底排除了。很多人到这一步才发现，自己前面折腾半天的 64 位组件根本用不上，程序要的是 32 位那份。

.udl之外，我还会用脚本再压一遍，因为.udl验证的是提供程序能连上，不验证 ADO 对象能不能创建。这两个是不同的层，前者是 OLE DB，后者是 ADO，报错信息也不一样。

' 保存为 test.vbs，用 32 位 cscript 执行 Dim conn, rs Set conn = CreateObject("ADODB.Connection") ' 这一步失败就是 ADO 核心没注册 conn.Open "Provider=SQLOLEDB;Data Source=10.0.0.21,1433;Initial Catalog=erp_test;User ID=sa;Password=***;" Set rs = conn.Execute("SELECT 1 AS ok") ' 能取到行，说明端到端通了 WScript.Echo rs.Fields("ok").Value rs.Close conn.Close

执行的时候注意位数，别用默认的cscript：

:: 32 位脚本宿主，路径在 SysWOW64 下 C:\Windows\SysWOW64\cscript.exe //nologo D:\test.vbs

这套验证跑完，我心里就有底了。三条线各自的结论要分开记：.udl通了说明提供程序注册没问题，脚本通了说明 ADO 核心没问题，取到数据说明认证和网络也没问题。哪一条断在前面，问题就定位在哪一层，不用再猜。

从那以后我每次交付老系统环境，都强制走一遍这套流程：先在目标机上建还原点、导出注册表、记下版本号，再解包、静默装、取退出码，然后两个视图各查一次版本，最后.udl加脚本双验证。哪怕时间再紧，这三步也不跳——跳过省下的二十分钟，往往要用一整个下午来还。希望帮到你。

本文还有配套的精品资源，点击获取