前陣子我在一臺(tái)剛重新裝好系統(tǒng)的機(jī)器上裝數(shù)據(jù)庫(kù)客戶端安裝包跑起來不到兩秒紅叉彈窗直接懟臉Microsoft Visual C 2019 Redistributable Package (x64) is not installed. Latest binary compatible version...。第一次遇到這條報(bào)錯(cuò)的人十個(gè)里有八個(gè)會(huì)以為要裝Visual Studio 2019——那是個(gè)動(dòng)輒幾個(gè)GB的IDE下載下來純屬浪費(fèi)時(shí)間。這個(gè)報(bào)錯(cuò)本質(zhì)上是在說你的Windows環(huán)境里缺少一個(gè)叫VC運(yùn)行庫(kù)的組件或者已安裝的版本太老不滿足這個(gè)軟件的啟動(dòng)條件。缺的不是某個(gè)具體軟件而是這個(gè)軟件依賴的系統(tǒng)級(jí)運(yùn)行環(huán)境。這篇分享我會(huì)把這個(gè)報(bào)錯(cuò)的來龍去脈講清楚包括為什么2019和2015-2022其實(shí)是一回事、x64和x86到底該裝哪個(gè)、裝完依舊報(bào)錯(cuò)該怎么排查以及開發(fā)者常見的那句error: Microsoft Visual C 14.0 is required和這個(gè)運(yùn)行庫(kù)報(bào)錯(cuò)到底有什么區(qū)別。不管你是普通用戶還是程序員照著操作基本都能解決。1. 先搞懂報(bào)錯(cuò)本身這個(gè)彈窗到底在檢查什么這條報(bào)錯(cuò)的完整表達(dá)雖然經(jīng)常被截?cái)嗟诵囊馑己苊鞔_——安裝程序在啟動(dòng)階段做了一個(gè)運(yùn)行庫(kù)依賴預(yù)檢查沒檢查通過于是拒絕繼續(xù)安裝。這不是某個(gè)軟件特有的問題而是一類大型軟件的通用做法數(shù)據(jù)庫(kù)工具、工業(yè)軟件、視頻處理軟件、開發(fā)工具等只要它們的本體或某個(gè)關(guān)鍵組件是用C編譯的安裝器就會(huì)先確認(rèn)目標(biāo)機(jī)器上有沒有對(duì)應(yīng)的VC Redistributable Runtime。1.1 典型出現(xiàn)時(shí)機(jī)我遇到這條報(bào)錯(cuò)的場(chǎng)景大致有三類剛裝完系統(tǒng)還沒裝任何全家桶直接裝大型軟件時(shí)彈出從網(wǎng)上下載的綠色版、精簡(jiǎn)版、漢化版軟件運(yùn)行時(shí)提示缺失DLL或直接退出公司批量部署軟件時(shí)用命令行靜默安裝日志里報(bào)這個(gè)錯(cuò)其中第二類最容易迷惑人。很多人下載的是免安裝版解壓就能用根本沒有安裝器但程序一啟動(dòng)就提示找不到msvcp140.dll或者vcruntime140.dll這不等于缺文件本質(zhì)是缺運(yùn)行庫(kù)。1.2 隱藏的含義安裝器在找二進(jìn)制兼容版本報(bào)錯(cuò)里那句Latest binary compatible version最新的二進(jìn)制兼容版本是關(guān)鍵。它的意思是安裝器需要的不是某年某月某個(gè)特定版本而是一個(gè)滿足最低要求的二進(jìn)制接口版本。只要你的系統(tǒng)里存在一個(gè)比編譯該軟件時(shí)所用版本更新的運(yùn)行庫(kù)安裝就能通過。這就解釋了一個(gè)常見現(xiàn)象軟件要求VC 2019但你機(jī)器里只有VC 2015-2022它照樣能過。因?yàn)樵谖④浀陌姹倔w系里這些年的VC運(yùn)行庫(kù)用的是同一套二進(jìn)制規(guī)范互相兼容。1.3 它和msvcp140.dll缺失是什么關(guān)系如果你在網(wǎng)上搜索過這個(gè)報(bào)錯(cuò)大概率會(huì)看到一堆下載msvcp140.dll放到System32的答案。這種操作能解決一時(shí)的問題但不是治本的辦法。原因在于msvcp140.dll就是VC 2015-2022運(yùn)行庫(kù)的核心文件之一運(yùn)行庫(kù)安裝器的工作就是把這些DLL系統(tǒng)化安裝、注冊(cè)到系統(tǒng)目錄并寫入正確的注冊(cè)表項(xiàng)。你手動(dòng)放一個(gè)DLL進(jìn)去等于跳過注冊(cè)過程程序有時(shí)候能跑有時(shí)候半路崩全看這個(gè)DLL碰巧能用多久。正確思路永遠(yuǎn)是缺運(yùn)行庫(kù)就裝運(yùn)行庫(kù)不要去單個(gè)DLL網(wǎng)站上碰運(yùn)氣。2. 版本命名的混亂現(xiàn)場(chǎng)2019、2015-2022、14.x 是怎么對(duì)應(yīng)起來的這個(gè)問題我一開始也很暈。為什么市面上同時(shí)有VC 2015 Redistributable、VC 2019 Redistributable、VC 2015-2022 Redistributable它們到底是不是同一個(gè)東西裝哪個(gè)才對(duì)搞清楚這段歷史報(bào)錯(cuò)理解起來就順了。2.1 從2005到2022的幾代運(yùn)行庫(kù)VC運(yùn)行庫(kù)從2005年那代開始基本維持年份命名的習(xí)慣每一代對(duì)應(yīng)一個(gè)獨(dú)立的大版本號(hào)各自安裝、互不替代運(yùn)行庫(kù)名稱內(nèi)部工具集版本典型DLL名稱Visual C 20058.0msvcp80.dllVisual C 20089.0msvcp90.dllVisual C 201010.0msvcp100.dllVisual C 201211.0msvcp110.dllVisual C 201312.0msvcp120.dllVisual C 2015-202214.0 - 14.4xmsvcp140.dll從2015年開始微軟做了一個(gè)關(guān)鍵調(diào)整編譯器工具集的主版本號(hào)統(tǒng)一為14.x不再隨年份跳動(dòng)。也就是說用VS2015編譯的程序、用VS2017編譯的程序、用VS2019編譯的程序、用VS2022編譯的程序它們依賴的運(yùn)行庫(kù)是同一套二進(jìn)制體系只是內(nèi)部細(xì)節(jié)版本不同。2.2 Latest binary compatible version說的其實(shí)是工具集開發(fā)者在用Visual Studio編譯軟件時(shí)程序員可以選擇動(dòng)態(tài)鏈接到運(yùn)行庫(kù)/MD編譯選項(xiàng)這會(huì)讓你最終的exe不包含C/C運(yùn)行時(shí)邏輯而是依賴目標(biāo)機(jī)器上安裝的VC Redistributable。安裝器里寫的那個(gè)檢查邏輯實(shí)際上就是檢查這個(gè)運(yùn)行庫(kù)的內(nèi)部版本號(hào)是否夠新。比如一個(gè)軟件用VS2019的工具集v142編譯它的安裝器會(huì)讓用戶至少裝VC 2019版運(yùn)行庫(kù)但VS2022的Redistributable內(nèi)部版本號(hào)更高、二進(jìn)制兼容于是安裝器同樣放行。這就是為什么你裝了2022的包軟件卻寫著需要2019但不再報(bào)錯(cuò)的原因。2.3 為什么裝2015-2022一個(gè)就夠微軟官方目前在下載中心提供的Microsoft Visual C 2015-2022 Redistributable (x64)”是一個(gè)合并后的統(tǒng)一安裝包它覆蓋了2015、2017、2019、2022這四代程序的運(yùn)行需求。你在官網(wǎng)搜最新支持的VC運(yùn)行庫(kù)下載大概率看到的就是這個(gè)文件文件名是vc_redist.x64.exe。注意2015-2022的合并包不等于你不需要裝更早的版本。如果你的某個(gè)老軟件依賴VC 2008或2010運(yùn)行庫(kù)仍然需要額外安裝對(duì)應(yīng)版本那些老庫(kù)不在合并包范圍內(nèi)。2019的Redistributable其實(shí)沒有獨(dú)立的官方下載頁(yè)面你在第三方網(wǎng)站看到的VC 2019運(yùn)行庫(kù)要么是微軟各時(shí)期舊鏈接的存檔要么就是拿2015-2022合并包改了個(gè)名。所以拿到這個(gè)報(bào)錯(cuò)時(shí)直接下載2015-2022合并包沒有毛病。3. 讓報(bào)錯(cuò)消失的正確安裝姿勢(shì)搞清楚原理之后實(shí)際操作就快了。這一步我會(huì)講官方安裝、命令行部署、以及新手最容易忽略的x86運(yùn)行庫(kù)問題。3.1 官方直裝VC_redist.x64.exe最穩(wěn)妥的方式是去微軟的官方文檔頁(yè)面最新支持的Visual C下載找vc_redist.x64.exe。下載后雙擊勾選同意條款點(diǎn)安裝十幾秒就完成。裝完之后建議去設(shè)置 - 應(yīng)用 - 已安裝的應(yīng)用里搜一下Microsoft Visual C確認(rèn)出現(xiàn)了Microsoft Visual C 2015-2022 Redistributable (x64)版本號(hào)大概14.30以上。看到這一項(xiàng)說明運(yùn)行庫(kù)真的落盤了而不是安裝器表面提示成功。3.2 順手把x86也裝掉64位系統(tǒng)上的經(jīng)典坑這一步被無數(shù)人跳過然后又回頭踩坑。64位的Windows系統(tǒng)上既可以運(yùn)行64位程序也可以運(yùn)行32位程序通過WOW64子系統(tǒng)。如果你的軟件安裝包顯示要求Microsoft Visual C 2019 Redistributable (x64)理論上裝x64運(yùn)行庫(kù)就夠了但實(shí)際開發(fā)中很多安裝器是做成32位進(jìn)程的它啟動(dòng)時(shí)檢測(cè)的是32位注冊(cè)表路徑有些安裝器甚至直接把檢測(cè)邏輯寫死成檢測(cè)x86運(yùn)行庫(kù)——結(jié)果就是報(bào)錯(cuò)信息里寫著x64實(shí)際上缺的是x86運(yùn)行庫(kù)。更麻煩的情況是某些軟件的主體是64位但通過一個(gè)32位引導(dǎo)器拉起安裝流程安裝器自身就依賴x86運(yùn)行庫(kù)于是報(bào)錯(cuò)。這種場(chǎng)景下你只裝x64運(yùn)行庫(kù)它照樣彈窗。所以我的建議很簡(jiǎn)單不管你的系統(tǒng)是64位還是32位也不管軟件要求哪個(gè)架構(gòu)把X64和X86兩個(gè)版本都裝了。反正兩個(gè)加起來也就幾十MB裝了之后能省掉后續(xù)一大堆明明裝了為什么還報(bào)錯(cuò)的折騰。3.3 命令行和winget的安裝方式如果被這個(gè)問題困擾的是IT運(yùn)維場(chǎng)景需要在多臺(tái)機(jī)器批量部署或者你單純不想用圖形界面點(diǎn)來點(diǎn)去可以用命令行。官方安裝包支持靜默安裝參數(shù)# 靜默安裝不重啟 vc_redist.x64.exe /install /quiet /norestart vc_redist.x86.exe /install /quiet /norestart如果你系統(tǒng)上有wingetWin10 1809之后自帶Win11默認(rèn)有還可以直接winget install Microsoft.VC2015-2022Redist-x64 --accept-source-agreements --accept-package-agreements winget install Microsoft.VC2015-2022Redist-x86 --accept-source-agreements --accept-package-agreements用winget的好處是以后重裝系統(tǒng)時(shí)可以把安裝命令寫進(jìn)腳本一鍵把常用運(yùn)行庫(kù)全部補(bǔ)齊。3.4 第三方AIO合集怎么用網(wǎng)上流傳著一些VC運(yùn)行庫(kù)合集——把2005到2022所有版本的運(yùn)行庫(kù)打包成一個(gè)安裝包。這類工具在重裝系統(tǒng)后的確方便一次裝完全家桶省得一個(gè)個(gè)下載。但選擇時(shí)要注意兩點(diǎn)建議去TechPowerUp這類知名論壇或社區(qū)找打包版本盡量別在來路不明的小站下載exe警惕捆綁修改裝完之后還是要自己在應(yīng)用列表里核對(duì)是否真的裝上了防止集合工具假成功。我的習(xí)慣是官方包優(yōu)先AIO合集只用來批量補(bǔ)齊老版本。比如有些老工業(yè)軟件依賴VC 2008這時(shí)候單裝2015-2022解決不了AIO合集反而順手。4. 裝上之后依然報(bào)錯(cuò)的完整排查鏈路運(yùn)行庫(kù)明明裝好了甚至版本號(hào)還是最新的重新打開軟件卻依然彈同樣的錯(cuò)。這種裝好等于沒裝的情況才是這個(gè)報(bào)錯(cuò)最折磨人的地方。按下面的順序排查基本能定位問題。4.1 第一步在應(yīng)用和功能里核對(duì)已裝版本先打開設(shè)置搜索Microsoft Visual C逐條檢查是否存在核心版本Microsoft Visual C 2015-2022 Redistributable (x64)如果只有2015或者2017舊版和2019報(bào)錯(cuò)之間可能仍存在版本間隙建議升級(jí)合并包是否安裝的是x86版本而漏了x64或反過來是否存在同一個(gè)版本同時(shí)裝了好幾遍的記錄有的話可能意味著系統(tǒng)注冊(cè)表中有殘留如果列表里干干凈凈那說明剛才安裝其實(shí)失敗了只是安裝器沒彈錯(cuò)誤信息。回到第3節(jié)用靜默安裝跑一遍再通過cmd看退出碼比如0代表成功0x80070666代表已有更高版本等。4.2 安裝包返回0x80070666 / 0x80070643的處理安裝運(yùn)行庫(kù)時(shí)最常見的兩個(gè)錯(cuò)誤碼值得單獨(dú)說0x80070666意思是已經(jīng)安裝了此產(chǎn)品的更新版本。這不是壞事系統(tǒng)里已經(jīng)有比你正在裝的更高的運(yùn)行庫(kù)版本安裝器選擇罷工而已。你想要的那個(gè)能力系統(tǒng)已經(jīng)具備了此時(shí)應(yīng)該去應(yīng)用列表確認(rèn)真實(shí)版本而不是試圖強(qiáng)裝。0x80070643一般是Windows Installer本身出了問題常見原因包括MSI緩存損壞、系統(tǒng)更新服務(wù)被禁用、或者之前的運(yùn)行庫(kù)安裝殘留在注冊(cè)表里。處理思路先右鍵以管理員身份運(yùn)行cmd執(zhí)行sfc /scannow等系統(tǒng)文件檢查再用微軟的程序安裝和卸載疑難解答工具清理?yè)p壞的安裝記錄實(shí)在不行把已裝的VC運(yùn)行庫(kù)全部卸載重啟后重新安裝。4.3 精簡(jiǎn)版系統(tǒng)與軟件綠色化的影響國(guó)內(nèi)網(wǎng)絡(luò)上有大量精簡(jiǎn)版、Ghost版、深度優(yōu)化版Windows它們?yōu)榱藟嚎s體積會(huì)刪除一些看似沒用的組件VC運(yùn)行庫(kù)往往是第一批被刪的。這導(dǎo)致一個(gè)現(xiàn)象裝完系統(tǒng)后軟件要求運(yùn)行庫(kù)你手動(dòng)裝了報(bào)錯(cuò)卻依然出現(xiàn)。原因大概率是精簡(jiǎn)系統(tǒng)動(dòng)了注冊(cè)表權(quán)限或組件存儲(chǔ)WinSxS導(dǎo)致運(yùn)行庫(kù)雖然裝上了但安裝器的檢測(cè)進(jìn)程無法正常讀取安裝信息。這種場(chǎng)景下先把系統(tǒng)更新跑一遍裝齊官方的通用C運(yùn)行庫(kù)更新KB系列再裝VC運(yùn)行庫(kù)如果依然報(bào)錯(cuò)考慮換回官方原版系統(tǒng)鏡像。4.4 安裝程序自身的bug檢測(cè)邏輯寫死x64的誤導(dǎo)前面提到過一種情況報(bào)錯(cuò)文字明確寫著*(x64)*但實(shí)際安裝器內(nèi)部調(diào)用的檢測(cè)項(xiàng)卻是x86。這是因?yàn)椴糠衷缙诎惭b器用NSIS或InstallShield編寫預(yù)先寫死了提示文本而實(shí)際的注冊(cè)表檢測(cè)路徑既查x64也查x86或者相反。如果你確認(rèn)x64和x86運(yùn)行庫(kù)都裝齊了、版本也沒問題但彈窗還出現(xiàn)那可以重點(diǎn)檢查x86運(yùn)行庫(kù)的版本情況——把x86的運(yùn)行庫(kù)也升級(jí)到最新版問題往往就消失了。4.5 終極兜底手動(dòng)注冊(cè)DLL或直接拷貝如果以上步驟都做完了軟件還是報(bào)缺msvcp140.dll在沒有其他方案時(shí)的最后一招從一臺(tái)正常的、已經(jīng)裝好運(yùn)行庫(kù)的機(jī)器上把對(duì)應(yīng)架構(gòu)的msvcp140.dll、vcruntime140.dll、vcruntime140_1.dll拷貝到軟件安裝目錄。這樣程序啟動(dòng)時(shí)會(huì)優(yōu)先加載同目錄下的DLL而不是去系統(tǒng)目錄找。這個(gè)方法只適合臨時(shí)應(yīng)急。因?yàn)槭謩?dòng)拷貝的DLL不會(huì)跟隨系統(tǒng)運(yùn)行庫(kù)更新而且如果程序是C運(yùn)行庫(kù)重度用戶短期能用后期大概率遇到內(nèi)存崩潰或隨機(jī)報(bào)錯(cuò)。治本還是要解決系統(tǒng)運(yùn)行庫(kù)安裝問題。5. 開發(fā)者還要分清的另一件事Runtime與Build Tools前面幾節(jié)解決的是運(yùn)行時(shí)報(bào)錯(cuò)這是普通用戶遇到最多的情況。但如果你是一名開發(fā)者打開終端敲pip install xxx時(shí)報(bào)出error: Microsoft Visual C 14.0 or greater is required那完全是另一回事別用VC Redistributable去解決。5.1 error: Microsoft Visual C 14.0 is required為什么是另一回事Redistributable提供的是運(yùn)行組件解決的是編譯好的程序啟動(dòng)時(shí)找不到DLLBuild Tools提供的是編譯工具鏈解決的是源代碼編譯成可執(zhí)行程序時(shí)找不到編譯器。pip在安裝帶有C擴(kuò)展的Python包時(shí)需要調(diào)用cl.exe微軟的C/C編譯器來把C/C源碼編譯成Python擴(kuò)展。如果你的機(jī)器上只有VC運(yùn)行庫(kù)沒有編譯工具鏈pip就會(huì)報(bào)Microsoft Visual C 14.0 is required。正確的解法是下載Microsoft C Build Tools官方安裝器安裝時(shí)勾選使用C的桌面開發(fā)工作負(fù)載。這個(gè)包很大好幾個(gè)GB但它解決的是編譯問題不是運(yùn)行問題。5.2 pip安裝時(shí)觸發(fā)編譯的場(chǎng)景和應(yīng)對(duì)現(xiàn)實(shí)里經(jīng)常出現(xiàn)的情況是pip install某個(gè)包時(shí)優(yōu)先下載預(yù)編譯的wheel包如果該包在當(dāng)前Python版本下沒有wheelpip就退化到源碼編譯于是觸發(fā)C編譯錯(cuò)誤。應(yīng)對(duì)思路分優(yōu)先級(jí)換用3.11的Python版本很多老包已有新版wheel或者使用--only-binary :all:強(qiáng)制只裝wheel包跳過源碼編譯終極的方案才是安裝Build Tools。既然你機(jī)器上已經(jīng)有編譯需求順手把Visual Studio Build Tools裝上更省心一勞永逸。5.3 node-gyp / node-sass等環(huán)境的處理類似的情況在Node.js生態(tài)里也很常見構(gòu)建原生模塊時(shí)node-gyp需要Python2/3和一個(gè)可用的Visual Studio C環(huán)境。很多前端開發(fā)者在這個(gè)環(huán)節(jié)被Visual Studio 2019嚇退其實(shí)只需要裝VS Build Tools即可不用裝完整IDE。在較新的Node版本下裝好Build Tools后還要檢查一下環(huán)境變量是否指向正確的VS實(shí)例。用npm config set msvs_version 2022之類的命令來指定版本可以減少構(gòu)建時(shí)的搜索開銷。5.4 給自己的軟件打包時(shí)把運(yùn)行庫(kù)藏對(duì)地方作為軟件作者如果你發(fā)布的程序動(dòng)態(tài)鏈接了VC運(yùn)行庫(kù)發(fā)現(xiàn)用戶電腦上有一半人報(bào)運(yùn)行庫(kù)缺失這時(shí)候最好直接在安裝包里帶上VC_redist.x64.exe并在安裝流程中靜默調(diào)用一次更穩(wěn)妥的方案是在項(xiàng)目屬性里把運(yùn)行庫(kù)設(shè)置為靜態(tài)鏈接/MT使用戶完全不需要裝VC運(yùn)行庫(kù)代價(jià)是exe體積會(huì)變大一些。我個(gè)人的經(jīng)驗(yàn)是對(duì)外發(fā)布的正式安裝版條件允許就帶官方運(yùn)行庫(kù)安裝器如果做綠色版、便攜版就直接靜態(tài)鏈接運(yùn)行庫(kù)避免用戶解壓即用后一把報(bào)錯(cuò)。另外提醒一下Visual Studio安裝目錄里有一個(gè)redist文件夾里面已經(jīng)替你準(zhǔn)備好了對(duì)應(yīng)年份的VC_redist.exe和MSM合并模塊文件。發(fā)布時(shí)直接把那個(gè)exe拷出來打包進(jìn)安裝流程即可不需要另外去找下載地址。最后再分享一個(gè)我自己的安裝習(xí)慣電腦裝完系統(tǒng)后我第一件是會(huì)把VC運(yùn)行庫(kù)2015-2022的x64和x86裝好然后順手把VC 2005到2013的老版本也裝齊U盤里常備一份離線安裝包。這樣一來之后裝任何軟件基本不會(huì)再被運(yùn)行庫(kù)報(bào)錯(cuò)打斷。雖然這套操作看起來有點(diǎn)強(qiáng)迫癥但說實(shí)話省下的排查時(shí)間遠(yuǎn)比安裝那幾分鐘要多得多。