簡介msado15.dll 32位與64位全版本ADO組件集合面向需要在Windows下進行數(shù)據(jù)庫應(yīng)用程序開發(fā)的工程師解決因系統(tǒng)架構(gòu)不匹配或DLL版本缺失導(dǎo)致的ADO調(diào)用失敗問題。壓縮包共194個文件約33.7MB包含96個dll文件、96個txt說明、1個DLL工具exe及1個htm參考文檔dll覆蓋ADO 2.0至6.x核心組件txt多為對應(yīng)版本的環(huán)境配置說明exe工具可用于DLL注冊、修復(fù)與卸載htm文檔提供常見問題指引。已有2471人學(xué)習(xí)下載。該集合涵蓋ADO連接、記錄集、命令等核心對象模型開發(fā)者可根據(jù)目標系統(tǒng)架構(gòu)從X86與X64目錄中選用對應(yīng)位數(shù)的msado15.dll結(jié)合DLL工具快速完成注冊或沖突排查適配Access、SQL Server等本地或遠程數(shù)據(jù)庫場景有效減少因版本不匹配引發(fā)的運行時錯誤。對需要兼容XP/Server 2003與Win7及以上系統(tǒng)的跨平臺工程尤為實用可直接將DLL放置于應(yīng)用程序目錄或系統(tǒng)目錄省去手動查找多個版本的麻煩。 做 Windows 平臺數(shù)據(jù)庫工具開發(fā)的人十有八九都碰過 msado15.dll 這個文件。它不像那些界面庫一樣天天被你寫代碼引用但只要是走 ADO 通道讀寫 Access、SQL Server、Excel 的舊系統(tǒng)就繞不開它。最近我在整理一套給客戶部署的數(shù)據(jù)遷移工具需求就一句話msado15.dll 的 32 位和 64 位各版本都備齊保證不同系統(tǒng)上都能跑起來。這句話看著簡單真落實起來全是位數(shù)、注冊表、COM 兼容性這些坑。這篇文章把整個整理和排查過程寫下來給后面接手的老哥省點時間。1. msado15.dll 是什么為什么數(shù)據(jù)庫開發(fā)繞不開它1.1 ADO 組件與 msado15.dll 的對應(yīng)關(guān)系A(chǔ)DOActiveX Data Objects是微軟在 COM 基礎(chǔ)上做的一套數(shù)據(jù)訪問組件把數(shù)據(jù)庫操作抽象成了連接Connection、命令Command、記錄集Recordset這幾個概念。你用編程語言創(chuàng)建ADODB.Connection對象時最終實例化的就是 msado15.dll 里的 COM 類。這套東西生命周期很長從 VB6 時代一路用到現(xiàn)在.NET 里的 OleDb 底層也大量走這條鏈路。msado15.dll 這個名字里的“15”其實是 ADO 2.5 時代定下來的文件名后來 ADO 一路升級到 2.6、2.7、2.8再到 Windows 7 時代直接跳到 6.0文件名一直沒改。所以你去看 Windows 不同版本的系統(tǒng)目錄文件都叫 msado15.dll但右鍵屬性里的“文件版本”可能差出好幾個大版本。這個“名字不變、版本在變”的規(guī)律是很多人網(wǎng)上找 DLL 時一臉懵的直接原因。實際整理版本時我最常用的一行命令是 PowerShell 的版本查詢(Get-Item C:\Windows\System32\msado15.dll).VersionInfo.FileVersion在不同機器上跑一遍就能把目標系統(tǒng)的 ADO 版本摸個大概。Windows XP 上一般是 2.8.xWindows 7 以上是 6.xServer 版略有差異。這個信息對做兼容性測試很有用別等部署到客戶現(xiàn)場才去補課。1.2 32位和64位版本到底差在哪進程是 32 位還是 64 位決定了它能加載哪些 DLL。而 COM 組件沒有跨位數(shù)調(diào)用的能力64 位進程加載不了 32 位 DLL32 位進程也加載不了 64 位 DLL。所以 64 位 Windows 在磁盤上同時維護兩份 msado15.dll 副本分開給兩套進程用64 位副本C:\Windows\System32\msado15.dll32 位副本C:\Windows\SysWOW64\msado15.dll這里有個反直覺的坑要特意說System32 目錄名字帶 32實際放的是 64 位文件SysWOW64 名字帶 64放的卻是 32 位文件。因為 Windows 為了不讓老程序在 64 位系統(tǒng)上“找不著北”把 32 位文件放進 SysWOW64并在文件系統(tǒng)層面做了重定向。你要是手動把 32 位 DLL 塞進 System32很容易被系統(tǒng)文件保護攔下甚至直接復(fù)制失敗。另外常規(guī)安裝路徑下還有兩份副本C:\Program Files\Common Files\System\ado\msado15.dll和C:\Program Files (x86)\Common Files\System\ado\msado15.dll。64 位系統(tǒng)上存在兩套 Program Files對應(yīng)的就是兩套 ADO 安裝目錄檢查現(xiàn)場時別漏了這里。順便提一個容易跟文件位數(shù)混淆的點ADO 的參數(shù)類型adIntegerType3底層就是 32 位有符號整數(shù)范圍是 -2147483648 到 2147483647。一旦你要傳給數(shù)據(jù)庫的值超過這個范圍就得用adBigIntType20否則會溢出變成負數(shù)或被截斷。這個跟 DLL 位數(shù)是兩碼事但查問題的人經(jīng)?；煸谝黄鹚盐矣龅竭^好幾次。2. 怎么選版本一看系統(tǒng)二看 Office 三看程序位數(shù)2.1 位數(shù)匹配的三種場景判斷場景一你的程序是 32 位編譯部署在 64 位系統(tǒng)上比如很多 VB6、Delphi 老項目或者為了兼容舊控件強制 x86 的 .NET 程序。此時程序走 WOW64 模擬層加載的是 SysWOW64 下的 32 位 msado15.dll代碼里CreateObject(ADODB.Connection)拿到的就是 32 位 COM 實例。這種情況你不需要任何特殊操作只要別手賤去注冊 64 位版本就行。場景二程序是 64 位編譯原生 x64 或 .NET 的 x64 / AnyCPU 跑在 64 位系統(tǒng)。進程加載 System32 下的 64 位 msado15.dll。此時如果拋“未找到提供程序”或0x800a0e7a大概率不是 ADO DLL 本身的問題而是驅(qū)動或者連接串問題后面第五章細說。場景三開發(fā)環(huán)境是 64 位但需要模擬 32 位環(huán)境。比如在 VS 里調(diào)試時選 x86 平臺或者用 32 位 Python 調(diào) ADO。很多程序員在 64 位機器上裝了 64 位 Python然后發(fā)現(xiàn)連不上 Access 數(shù)據(jù)庫就是因為 Python 是 64 位、ACE 驅(qū)動是 32 位位數(shù)對不上跟 msado15.dll 本身沒關(guān)系。2.2 Access 數(shù)據(jù)庫引擎驅(qū)動的位數(shù)陷阱這里要單獨說 ACE 引擎。微軟從 Office 2007 開始提供 Access Database Engine替代老的 Jet 4.0 驅(qū)動。ACE 同時有 32 位和 64 位版本但兩個版本不能在同一臺機器上共存安裝器會互相阻止。ACE 裝成幾位直接決定哪個位數(shù)的程序能通過 OLEDB 連 Access。也就是說你在 64 位系統(tǒng)上裝了 64 位 Office那 ACE 就是 64 位只有 64 位程序能成功創(chuàng)建 ADODB.Connection 去連接 .accdb 文件。如果你開發(fā)的工具是 32 位它連 Access 時很容易報“請先安裝 Access 數(shù)據(jù)庫 64 位系統(tǒng)驅(qū)動程序”之類提示——這是系統(tǒng)里只有 64 位 ACE 驅(qū)動的結(jié)果。反過來也一樣裝了 32 位 ACE64 位程序就是連不上 Access。解決辦法就兩條路要么統(tǒng)一程序位數(shù)和 ACE 位數(shù)要么用舊版 JET 驅(qū)動只讀 .mdb 文件。注意 JET 只有 32 位且不支持 .accdb 格式所以老驅(qū)動救不了新文件。如果一臺機器必須跑多個位數(shù)的程序別指望 ACE 32/64 共存我見過有人強行裝兩個版本把注冊表搞得一團糟最后只能重裝 Office。2.3 一張決策表搞定版本選擇程序位數(shù)目標系統(tǒng)位數(shù)加載的 msado15.dll 路徑Access 驅(qū)動方案32 位32 位System32 下的 32 位副本裝 32 位 ACE 引擎32 位64 位SysWOW64 下的 32 位副本裝 32 位 ACE 引擎64 位64 位System32 下的 64 位副本裝 64 位 ACE 引擎64 位32 位不存在64 位程序無法在 32 位系統(tǒng)運行表格最后一行是我特意加的。很多人問“我 64 位程序能不能部署到 32 位機器”答案是不能跟 ADO 無關(guān)這是整個進程運行環(huán)境不支持。真正能做的只有改編譯目標為 x86。3. 三步確認 DLL 位數(shù)從 PE 頭讀到命令行工具3.1 用 dumpbin 查看機器類型整理各版本 DLL 時第一件事就是確認手里這個文件是 32 位還是 64 位。如果機器裝了 Visual Studio 或者 Build Tools直接用 dumpbin 最快。方法是打開“Developer Command Prompt for VS”執(zhí)行dumpbin /headers C:\Windows\System32\msado15.dll | findstr /i machine輸出里如果看到machine (8664)代表 x64如果看到machine (14C)代表 x86。8664和14C這兩個值可以稍微記一下因為后面讀 PE 頭時還會遇到。dumpbin 輸出的東西很長務(wù)必用 findstr 過濾不然滿屏都是沒用的段信息。如果你電腦上沒裝 VS 全家桶但裝了 Build Tools 或者 .NET SDK也可以試試link /dump /headers底層是同一個工具鏈。實在沒有這些環(huán)境就跳到 3.2 的 PowerShell 方案。3.2 用 PowerShell 直接解析 PE 頭不想裝任何工具時可以用一段 PowerShell 腳本直接讀文件的 PE 頭。原理很簡單PE 文件開頭是 DOS 頭在偏移0x3C處有一個 4 字節(jié)指針指向真正的 PE 頭起始位置PE 頭開始后的第 4 個字節(jié)就是 Machine 字段一個 2 字節(jié)無符號整數(shù)。$path C:\Windows\SysWOW64\msado15.dll $bytes [System.IO.File]::ReadAllBytes($path) $peOffset [System.BitConverter]::ToInt32($bytes, 0x3C) $machine [System.BitConverter]::ToUInt16($bytes, $peOffset 4) if ($machine -eq 0x014C) { 32-bit (x86) } elseif ($machine -eq 0x8664) { 64-bit (x64) } else { Unknown: 0x{0:X4} -f $machine }這段腳本我在很多沒裝開發(fā)工具的現(xiàn)場機器上用過只要 PowerShell 能用就能跑。0x3C這個偏移可以不用硬記但理解它的含義以后排查其他 DLL 時也管用。嫌麻煩的話把腳本存成CheckDllArch.ps1每次只要改路徑。3.3 借助 7-Zip 與 Sigcheck 的備用方案如果你連命令行都不想敲還有一個土辦法用 7-Zip 打開 DLL 文件在文件屬性里能看到 CPU 架構(gòu)。這個方法在公司內(nèi)網(wǎng)機器上特別實用因為 7-Zip 裝機率很高隨便右鍵打開就能確認位數(shù)不用額外裝任何開發(fā)工具。更專業(yè)一點的是 Sysinternals 套件里的 sigchecksigcheck -a C:\Windows\System32\msado15.dll輸出里會有Machine:一欄直接寫 x64 或 x86同時還帶著文件版本、數(shù)字簽名、公司名這些信息。我整理“各版本 ADO”時一般先把從各個系統(tǒng)提取的 DLL 放在一個目錄里挨個跑一遍 sigcheck生成清單再按位數(shù)和版本號歸檔。這比靠文件名猜靠譜得多。4. regsvr32 注冊 msado15.dll 的正確姿勢4.1 32位和64位注冊命令的區(qū)別需要手工注冊 msado15.dll 的場景挺常見文件被誤刪、被安全軟件隔離、或者你從干凈系統(tǒng)提取了一個版本想注冊進目標機器。注冊命令本身不難難在很多人不知道regsvr32自己也分位數(shù)。64 位系統(tǒng)上regsvr32.exe默認在C:\Windows\System32\regsvr32.exe是 64 位32 位版本在C:\Windows\SysWOW64\regsvr32.exe。注冊 DLL 時必須用位數(shù)匹配的 regsvr32 去注冊對應(yīng)的 DLLrem 注冊 64 位 msado15.dll在管理員命令行下執(zhí)行 regsvr32 C:\Windows\System32\msado15.dll rem 注冊 32 位 msado15.dll務(wù)必用 SysWOW64 下的 regsvr32 C:\Windows\SysWOW64\regsvr32.exe C:\Windows\SysWOW64\msado15.dll我踩過的坑就是第二種情況在 64 位命令行里直接敲regsvr32 某個 32 位 DLL系統(tǒng)用 64 位 regsvr32 去加載 32 位 COM 組件結(jié)果報“已加載但找不到入口點 DllRegisterServer”?？粗?DLL 壞了其實是工具選錯了。注冊完可以用一行 PowerShell 驗證注意一定要用對應(yīng)位數(shù)的 PowerShell。驗證腳本如下$conn New-Object -ComObject ADODB.Connection $conn.ConnectionString ProviderMicrosoft.ACE.OLEDB.12.0;Data SourceC:\test.accdb; $conn.Open() Write-Host OK $conn.Close()這里補充一個知識點64 位 PowerShell默認會加載 64 位 COM 組件32 位 PowerShell 則要運行C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe才會加載 32 位 COM。驗證時用錯 PowerShell結(jié)果會被誤導(dǎo)。我自己就曾經(jīng)在 64 位 PowerShell 里明明連上了 Access轉(zhuǎn)頭用 32 位程序跑就報錯折騰半小時才發(fā)現(xiàn)根本不是 DLL 問題。4.2 注冊失敗的原因與處理注冊報錯基本集中在四類管理員權(quán)限不足regsvr32 需要寫 HKCR 和 HKLM普通權(quán)限會報“拒絕訪問”。解決方式是右鍵“以管理員身份運行”命令行。位數(shù)不匹配64 位 regsvr32 加載 32 位 DLL報找不到入口點。解決方式是用完整路徑調(diào)用對應(yīng)位數(shù)的 regsvr32。依賴缺失msado15.dll 依賴系統(tǒng)公共組件如果目標機器太精簡可能缺基礎(chǔ)運行庫。解決方式是補裝 VC 運行庫或確認系統(tǒng)版本不低于預(yù)期。系統(tǒng)文件保護往 System32 里覆蓋系統(tǒng)自帶的 msado15.dll可能被系統(tǒng)還原或報無權(quán)訪問。其實系統(tǒng)自帶的版本不需要覆蓋只需要重新注冊一遍即可。如果你是從網(wǎng)上下載的 DLL注冊前建議先校驗數(shù)字簽名和哈希。msado15.dll 這類系統(tǒng)關(guān)鍵文件被二次修改的風(fēng)險不小我用過的原則是能提取自微軟官方鏡像或干凈系統(tǒng)絕不從第三方 DLL 站下載。5. ADO 調(diào)用中的高頻報錯與排查實錄5.1 “未找到提供程序”先檢查位數(shù)再檢查驅(qū)動報錯信息通常長這樣“未找到提供程序。該程序可能未正確安裝?！?x800a0e7a或者“當(dāng)前不會在此計算機上激活 Microsoft Access 數(shù)據(jù)庫引擎...”。很多人第一反應(yīng)是重裝 Office 或者修復(fù) ADO但更高效的排查順序應(yīng)該是第一步確認程序位數(shù)。是 64 位進程就去系統(tǒng)里看已安裝的 ACE 驅(qū)動是不是 64 位是 32 位進程反過來查。第二步確認連接串里的 Provider 名。ProviderMicrosoft.ACE.OLEDB.12.0和ProviderMicrosoft.Jet.OLEDB.4.0對驅(qū)動的要求完全不同Jet 只支持 .mdb 且只有 32 位。第三步去注冊表看對應(yīng)位數(shù)下有沒有這個 OLEDB Provider?？梢栽贖KLM\SOFTWARE\Microsoft和HKLM\SOFTWARE\WOW6432Node\Microsoft里分別看兩個節(jié)點代表 64 位和 32 位的組件注冊信息。我印象最深的一個案例某客戶機器裝了 64 位 OfficeACE 是 64 位但我們交付的工具為了兼容舊報表控件是 32 位的結(jié)果在客戶現(xiàn)場反復(fù)報“未找到提供程序”。當(dāng)時一開始懷疑是 DLL 沒注冊折騰半天最后才發(fā)現(xiàn)是 ACE 引擎位數(shù)和程序位數(shù)沖突。后來我們在部署文檔里加了一條硬性約定工具為 32 位時必須額外安裝 32 位 AccessDatabaseEngine_x86.exe并且不能跟 64 位 Office 共存只能選一條路走。5.2 64位程序調(diào)用 32 位 DLL 的經(jīng)典場景這里講一個很多人問的“64位模式下調(diào)用32位dll”問題。在 64 位進程里用 LoadLibrary 加載 32 位 DLL系統(tǒng)會直接返回ERROR_BAD_EXE_FORMAT錯誤碼 193根本不會讓你靜默執(zhí)行。COM 組件也是同理32 位 COM 組件在 64 位進程里表現(xiàn)為“類未注冊”或“找不到對象”。如果你的項目必須在 64 位進程里用某個 32 位組件通常只有三條路把進程改成 32 位。自己控制的程序最省事把編譯目標改成 x86 即可。很多工具性能完全不受位數(shù)影響沒必要死磕 64 位。進程隔離。寫一個 32 位 helper 進程去完成 COM 調(diào)用64 位主進程通過命名管道或 TCP 和 helper 通信。這是老組件單方面只能 32 位時的常規(guī)做法。找替代組件?？纯赐瑯拥墓δ苡袥]有 64 位版本或者直接用原生代碼重寫一遍。對 msado15.dll 來說微軟本來就提供了 32 位和 64 位兩種版本所以一般不存在“只有 32 位”的情況缺的是你按正確位數(shù)去加載。真遇到訪問不了優(yōu)先懷疑系統(tǒng)目錄里的副本沒配對而不是到處找 DLL 覆蓋。5.3 常見問題速查表現(xiàn)象原因處理64位進程連 Access 報“未找到提供程序”系統(tǒng)只裝了 32 位 ACE 驅(qū)動安裝 64 位 ACE 引擎32位進程連 .accdb 報錯系統(tǒng)只裝了 64 位 ACE 驅(qū)動安裝 32 位 ACE 引擎32位程序在 64 位系統(tǒng)跑提示缺 msado15.dll未裝任何 ADO 組件或文件被刪除用系統(tǒng)自帶 ADO重新注冊或修復(fù)系統(tǒng)regsvr32 報“找不到入口點 DllRegisterServer”用錯了位數(shù)的 regsvr32換 SysWOW64 下的 regsvr32 注冊 32 位 DLL程序運行時“類未注冊”COM 組件 CLSID 沒注冊按位數(shù)重新注冊對應(yīng) DLL覆蓋 System32 的 msado15.dll 后被還原Windows 文件保護攔截不要覆蓋系統(tǒng)文件改用官方注冊方式這份速查表看起來簡單但我實際排查時有一半問題都能落回表格前兩行。多數(shù)“連不上 Access”的報錯最終原因都是 ACE 引擎位數(shù)不匹配而不是 msado15.dll 本身損壞。先查位數(shù)一致性能省下大把時間。5.4 一個值得保留的部署檢查思路項目最終交付時我整理了一份環(huán)境檢查腳本按順序做三件事用 PowerShell 輸出當(dāng)前 ADO 版本、確認 msado15.dll 的位數(shù)、列出已安裝的 ACE 驅(qū)動位數(shù)。然后根據(jù)目標程序位數(shù)自動給出“是否匹配”的結(jié)論。這條思路整個過程讓我節(jié)省了很多現(xiàn)場排查時間也讓我對 msado15.dll 的 32 位和 64 位版本情況有了更深的記憶。客戶機器上那些“昨天還能用今天突然不行”的問題多半不只是 DLL 丟了而是某個殺軟隔離了文件或者某個清理工具把注冊表項刪了。遇到這種情況先靜下心確認位數(shù)和組件注冊狀態(tài)往往比盲目重裝靠譜得多。本文還有配套的精品資源點擊獲取