在 TSMaster 里寫腳本這件事寫得越深越早晚會撞上一堵墻手上有一堆現(xiàn)成的 dll里面有算法、有加密、有設備廠商給的驅(qū)動接口可腳本這邊就是夠不著。TSMaster 自帶的腳本 API 覆蓋的是總線收發(fā)、仿真、診斷、標定這些常規(guī)動作一旦要接第三方庫腳本訪問 dll 就成了繞不開的基本功。這篇按我自己的實操順序把 Python 腳本、C/C 小程序、C# 小程序三條訪問 dll 的路子從頭捋一遍重點講那些文檔里不寫、但一定會讓你卡半天的細節(jié)位數(shù)匹配、調(diào)用約定、依賴鏈、回調(diào)對象的生命周期、字符串編碼、dll 沖突。不管你是剛裝完 TSMaster 想跑第一個腳本的新手還是已經(jīng)在做臺架自動化、想把老代碼搬進來的老手都能直接抄配置、抄代碼。1. 先想清楚腳本為什么要去訪問 dll1.1 TSMaster 里三個能寫腳本的入口這三個入口能碰 dll 的方式完全不同這也是很多人第一次踩坑的根本原因——拿著 Python 的思路去寫 C 小程序或者拿 C 小程序的寫法去套 C#結(jié)果編譯能過、運行就崩。Python 腳本是上手最快的入口在腳本編輯器、全局腳本、測試用例的腳本步驟里都能寫。它的優(yōu)勢是改一行跑一行不用編譯特別適合算法驗證、報文解析、數(shù)據(jù)后處理這類活兒。它訪問 dll 靠的是 Python 自帶的ctypes模塊本質(zhì)是動態(tài)加載 運行時查符號不需要任何頭文件和 lib 文件。C/C 小程序是編譯型的跑在軟件進程內(nèi)部適合高頻、實時性要求高、需要貼著底層接口做的場合。TSMaster 的定時器回調(diào)、報文事件回調(diào)基本都在這個小程序里落地。它訪問 dll 走的是標準 Windows 的鏈接/加載機制需要 dll、lib、頭文件三件套齊活。C# 小程序介于兩者之間.NET 生態(tài)里現(xiàn)成的東西拿來就用寫串口、寫數(shù)據(jù)庫、調(diào) HTTP 接口都很舒服。它訪問 dll 靠的是DllImport這個平臺調(diào)用特性簽名聲明寫對了就能直接調(diào)。1.2 什么情況下非碰 dll 不可我把這些年遇到的場景歸成四類基本能覆蓋九成以上的需求。第一類是公司內(nèi)部已有的算法庫比如 CRC 校驗、信號濾波、標定算法、故障診斷邏輯這些代碼往往跑了很多年只有 dll 沒有源碼重寫的風險比復用大得多。第二類是硬件廠商給的接口電源、程控電阻、示波器、數(shù)據(jù)采集卡、加密狗廠商一般只給 dll 加一份頭文件和一份 PDF你沒有別的選擇。第三類是老的測試代碼本身就是 C/C 寫的邏輯復雜且經(jīng)過長期驗證直接包成 dll 復用比翻譯成 Python 劃算。第四類是需要被 TSMaster 驅(qū)動的 .NET 程序集設備這時候 C# 小程序反而是最順的路。1.3 三條路線怎么選選路線的核心判斷依據(jù)只有三個調(diào)用頻率、實時性要求、以及你手上的資源形態(tài)有源碼還是只有 dll。下面這張表是我自己總結(jié)的對照可以直接照著挑。判斷維度Python ctypesC/C 小程序C# DllImport上手速度最快改完就跑最慢要配工程中等要編譯調(diào)用頻率上限幾千次/秒有解釋器開銷幾十萬次/秒量級幾萬次/秒量級實時性差有 GC 和解釋器抖動最好可控一般需要頭文件/lib不需要需要不需要處理結(jié)構(gòu)體/指針要手寫類型映射直接用要寫封送特性回調(diào)支持可以但有坑最自然可以委托要保引用適合的場景驗證、后處理、低頻控制實時回調(diào)、高頻算法.NET 生態(tài)集成我的習慣是先用 Python 把 dll 調(diào)通確認導出名、參數(shù)、返回值、編碼全對再決定要不要搬到 C 小程序。這個順序能省掉大量時間因為 Python 側(cè)報錯清晰、改起來快而 C 小程序一旦加載失敗往往連個像樣的錯誤信息都看不到。2. 動手前的三道硬門檻位數(shù)、調(diào)用約定、依賴鏈這三道門檻不跨過去后面寫多少代碼都是白費。它們的共同特點是報錯信息極其模糊看起來像是代碼寫錯了實際上是環(huán)境問題。2.1 位數(shù)必須嚴格對上現(xiàn)在的 TSMaster 基本是 64 位程序這意味著三件事。Python 腳本跑在 TSMaster 主進程里解釋器跟著主進程走所以是 64 位C/C 小程序編譯時必須選 x64 平臺選了 Win32 會直接加載失敗C# 小程序要看清目標平臺是 Any CPU 還是 x64Any CPU 在 64 位宿主下會以 64 位運行通常沒問題但如果引用了 32 位的托管程序集就會炸。典型癥狀是OSError: [WinError 193] %1 不是有效的 Win32 應用程序或者 C 小程序加載時提示模塊無效。這個錯誤碼看著像文件損壞實際九成是位數(shù)不匹配。怎么確認一個 dll 是幾位用 Visual Studio 開發(fā)者命令行的dumpbindumpbin /headers CalcLib.dll | findstr machine輸出8664是 x64輸出14C是 x86。沒有 VS 的話用任意一個 PE 查看工具或依賴分析工具看頭信息也行。提示不要試圖用32 位兼容的思路硬扛。32 位進程沒法把 64 位 dll 加載到自己地址空間里跨位調(diào)用只能走進程外方案——起一個 32 位中轉(zhuǎn)進程用命名管道或共享內(nèi)存通信。這套東西的成本和復雜度完全是另一個量級除非萬不得已不要碰。2.2 調(diào)用約定stdcall 和 cdecl 差的那一下棧平衡調(diào)用約定說白了就是函數(shù)返回時誰來清理棧上的參數(shù)。Windows API 用的是__stdcall參數(shù)由被調(diào)用方清理很多第三方 C 庫默認是__cdecl參數(shù)由調(diào)用方清理。如果調(diào)用方和被調(diào)用方的理解不一致棧指針就會錯位后果是返回值全是垃圾、參數(shù)看起來被吃掉了、或者直接崩潰。Python 側(cè)的區(qū)分方式很直接ctypes.CDLL(path)加載默認按cdecl調(diào)用ctypes.WinDLL(path)加載默認按stdcall調(diào)用。選錯的表現(xiàn)非常典型函數(shù)明明返回 0你拿到的是個七位數(shù)或者第一次調(diào)用沒事第二次調(diào)用直接進程消失。C 小程序側(cè)更嚴格頭文件里寫的是__stdcall你的聲明就必須寫__stdcall一個字都不能少。否則編譯鏈接都能過運行必崩。怎么確認一個 dll 的導出函數(shù)用的哪種約定看導出名的裝飾形式dumpbin /exports CalcLib.dll如果看到_Calc_Add8這種帶字節(jié)數(shù)后綴的是stdcall看到_Calc_Add這種只有前導下劃線的是cdecl如果看到一長串帶?和的亂碼名字那是 C 編譯器做了名稱修飾說明 dll 作者沒加extern C。最后這種情況最麻煩因為名字會隨編譯器版本變化只能靠GetProcAddress拿到修飾名去調(diào)或者找廠商要一個 C 接口的導出。2.3 依賴鏈真正的兇手往往是 dll 自己的 dllWinError 126找不到指定的模塊是最常見的加載失敗。絕大多數(shù)人的第一反應是路徑寫錯了于是反復檢查路徑檢查半天沒問題。實際上八成的 126 不是目標 dll 不在而是目標 dll 依賴的某個 dll 不在。常見依賴有三類VC 運行庫msvcp140.dll、vcruntime140.dll、vcruntime140_1.dll廠商的底層驅(qū)動以及某個被其他模塊搶先加載的同名不同版本 dll——這就是大家常說的 dll 沖突。排查三板斧按順序來用依賴分析工具打開目標 dll看哪幾個節(jié)點標紅裝對應版本的 VC 運行庫注意要裝x64版裝成 x86 版解決不了問題把目標 dll 和它所有依賴 dll 全部丟進同一個目錄然后用絕對路徑加載。關于 dll 沖突原理值得說清楚Windows 在同一個進程里同名 dll 只會加載一份。如果某個模塊先把老版本的xxx.dll加載進來了你后面請求加載新版本時系統(tǒng)發(fā)現(xiàn)這個名字已經(jīng)加載過了就會直接把老版本的句柄給你。你調(diào)用的一切都正常但行為就是不對。規(guī)避辦法有兩個。C 側(cè)用LoadLibraryEx加LOAD_WITH_ALTERED_SEARCH_PATH標志讓系統(tǒng)到 dll 自己所在的目錄去找它的依賴而不是從主程序目錄開始找。Python 側(cè)用os.add_dll_directory()把依賴目錄加進搜索路徑這個在 Python 3.8 之后是必須的因為那時起 Windows 上加載 dll 不再默認搜 PATH。3. Python 腳本用 ctypes 訪問 dll 全流程Python 是我最推薦的起點因為它的錯誤反饋最清晰。這一章按實際操作順序走一遍。3.1 環(huán)境確認與 dll 放置策略第一件事是確認 TSMaster 內(nèi)置 Python 的版本。在腳本里跑一句import sys print(sys.version)注意內(nèi)置的 Python 環(huán)境只保證標準庫可用numpy、pandas這類第三方包要看你的安裝包版本里帶沒帶。如果你打算在腳本里做大量數(shù)組運算先在腳本里import numpy試一下不行就得換個思路——要么自己在 C 側(cè)把運算做完要么用ctypes配合原生數(shù)組手寫循環(huán)。第二件事是 dll 放哪。我的習慣是在 TSMaster 工程目錄下建一個libs子目錄把 dll 和它的所有依賴一起丟進去然后腳本里用絕對路徑拼出來。不要依賴系統(tǒng) PATH也不要指望放到主程序目錄就行——那會污染安裝目錄換個工程就亂套。import os DLL_DIR rD:\Project\TSMaster\Demo\libs if hasattr(os, add_dll_directory): os.add_dll_directory(DLL_DIR) # Python 3.8 必須 DLL_PATH os.path.join(DLL_DIR, CalcLib.dll)如果你的腳本需要跨機器部署別把絕對路徑寫死。可以讀一個同目錄的配置文件或者用工程根目錄加子路徑拼出來。有些執(zhí)行方式下的 TSMaster 腳本拿不到__file__這種時候老老實實從工程配置里讀路徑比猜要靠譜。3.2 參數(shù)類型映射表與結(jié)構(gòu)體對齊ctypes有一套自己的類型系統(tǒng)和 C 類型不是一一對應。下面這張表是我平時貼在顯示器邊上的照著填基本不會錯。C 側(cè)聲明ctypes 寫法關鍵備注intctypes.c_int固定 32 位unsigned intctypes.c_uintshortctypes.c_short16 位unsigned charctypes.c_ubytecharctypes.c_char單字節(jié)字符const char*ctypes.c_char_p傳bytes不是strvoid*ctypes.c_void_p萬能指針float/doublectypes.c_float/c_double別混用BOOLWin32ctypes.c_int4 字節(jié)boolCctypes.c_bool1 字節(jié)和 BOOL 不是一回事unsigned char[N](ctypes.c_ubyte * N)定長數(shù)組struct自定義Structure子類_pack_必須對齊字符串編碼是另一個高頻坑。C 側(cè)的char*絕大多數(shù)情況下是 ANSI 編碼在中文 Windows 上就是 GBK而 Python 側(cè)字符串是 Unicode。傳參的時候要顯式編碼取回來的時候要顯式解碼name 左前輪速 calc.Calc_SetName.argtypes [ctypes.c_char_p] calc.Calc_SetName.restype ctypes.c_int calc.Calc_SetName(name.encode(gbk))踩過的坑記錄一下有一次我順手寫了encode(utf-8)傳過去 C 側(cè)按 GBK 解結(jié)果所有中文全變亂碼但英文和數(shù)字完全正常排查了半天才想起來是編碼問題。所以規(guī)矩就這么定死——對外傳參一律 GBK除非頭文件里明確寫了寬字符接口。結(jié)構(gòu)體的對齊更隱蔽。C 側(cè)結(jié)構(gòu)體如果有#pragma pack(1)Python 側(cè)就必須寫_pack_ 1否則字段偏移會差幾個字節(jié)你會讀到看起來完全隨機的值。class CanFrame(ctypes.Structure): _pack_ 1 _fields_ [ (id, ctypes.c_uint), (dlc, ctypes.c_ubyte), (data, ctypes.c_ubyte * 8), (timestamp, ctypes.c_ulonglong), ]3.3 一個能跑通的完整例子假設廠商給了我們一個CalcLib.dll導出三個函數(shù)int Calc_Add(int, int)、int Calc_CRC16(const unsigned char*, int, unsigned short*)、void Calc_SetLogCallback(void(*)(int, const char*))全部是stdcall。完整腳本如下。import ctypes import os DLL_DIR rD:\Project\TSMaster\Demo\libs if hasattr(os, add_dll_directory): os.add_dll_directory(DLL_DIR) DLL_PATH os.path.join(DLL_DIR, CalcLib.dll) # stdcall 用 WinDLL若是 cdecl 則換成 CDLL calc ctypes.WinDLL(DLL_PATH) # 1) 簡單函數(shù) calc.Calc_Add.argtypes [ctypes.c_int, ctypes.c_int] calc.Calc_Add.restype ctypes.c_int print(Calc_Add(3,4) , calc.Calc_Add(3, 4)) # 2) 帶輸出緩沖區(qū)的函數(shù) calc.Calc_CRC16.argtypes [ ctypes.c_void_p, ctypes.c_int, ctypes.POINTER(ctypes.c_ushort), ] calc.Calc_CRC16.restype ctypes.c_int def crc16(data: bytes) - int: buf (ctypes.c_ubyte * len(data)).from_buffer_copy(data) out ctypes.c_ushort(0) rc calc.Calc_CRC16( ctypes.cast(buf, ctypes.c_void_p), len(data), ctypes.byref(out) ) if rc ! 0: raise RuntimeError(Calc_CRC16 failed, rc%d % rc) return out.value print(CRC16 0x%04X % crc16(b\x01\x02\x03\x04\x05\x06\x07\x08))幾個細節(jié)值得單獨說。第一argtypes和restype一定要寫。不寫的話 ctypes 會按默認規(guī)則猜指針會被截斷成 32 位在 64 位進程里直接崩。第二輸出參數(shù)用ctypes.byref(out)比ctypes.pointer(out)更輕量也更快。第三from_buffer_copy會復制一份數(shù)據(jù)避免你后續(xù)改動原 bytes 影響 dllbytes 本身不可變但換成bytearray時就有這個風險了。讀寫一個結(jié)構(gòu)體數(shù)組也順手給出來做批量報文處理時用得上frames (CanFrame * 64)() calc.Calc_ReadFrames.argtypes [ctypes.POINTER(CanFrame), ctypes.c_int] calc.Calc_ReadFrames.restype ctypes.c_int n calc.Calc_ReadFrames(frames, 64) for i in range(n): print(hex(frames[i].id), frames[i].dlc, bytes(frames[i].data[:frames[i].dlc]))3.4 回調(diào)函數(shù)最容易閃退的地方回調(diào)是 Python 調(diào) dll 里最危險的一環(huán)。寫法本身很簡單CALLBACK ctypes.CFUNCTYPE(None, ctypes.c_int, ctypes.c_char_p) def _on_log(level, msg): text msg.decode(gbk, errorsignore) if msg else print([dll][%d] %s % (level, text)) _cb CALLBACK(_on_log) # 存成模塊級變量 calc.Calc_SetLogCallback.argtypes [CALLBACK] calc.Calc_SetLogCallback.restype None calc.Calc_SetLogCallback(_cb)大坑在這里如果你偷懶寫成calc.Calc_SetLogCallback(CALLBACK(_on_log))Python 側(cè)沒有任何變量持有這個回調(diào)對象垃圾回收一觸發(fā)就把它回收了。dll 下一次回調(diào)時跳到已經(jīng)釋放的地址整個進程瞬間消失。這種崩潰的惡心之處在于——它不在注冊的那一刻發(fā)生而是在幾秒或幾十秒之后看起來毫無規(guī)律特別難定位。第二個要注意的點是線程。回調(diào)是在 dll 自己的線程里進來的跟你的腳本主線程不是一回事。在回調(diào)里直接動手操作 TSMaster 的界面對象或發(fā)報文接口很容易出現(xiàn)競態(tài)。我的做法是在回調(diào)里只做一件事把數(shù)據(jù)塞進一個線程安全的隊列然后在腳本的主循環(huán)或定時器里取出來處理。第三個點是異常。回調(diào)函數(shù)里拋出的 Python 異常不會優(yōu)雅地傳回 dll跨語言邊界的行為是未定義的。所以回調(diào)體里必須自己包一層try/except出錯就記日志絕不讓異常逃出去。4. C/C 小程序直接鏈接 dll 的做法C 小程序的調(diào)用開銷最小實時性最好代價是配置麻煩、出錯難查。這一章講配置和兩種調(diào)用方式。4.1 工程配置的三件套與輸出目錄在 TSMaster 里寫 C/C 小程序需要在工程設置里配好三樣東西頭文件搜索路徑、lib 文件搜索路徑、附加依賴項。配完之后編譯鏈接能過但運行還會掛——因為小程序編譯出來的 dll 是要被主程序加載的它所在的目錄和你配的路徑?jīng)]關系。關鍵動作是把第三方 dll 復制到小程序輸出 dll 的同一個目錄里。如果你在小程序工程設置里找到了附加依賴項或DLL 搜索路徑這類配置項優(yōu)先用它沒有的話就靠同目錄擺放 絕對路徑加載兩條腿走路穩(wěn)。還有兩個編譯選項必須注意。平臺選x64和 TSMaster 保持一致。運行時庫選/MD多線程 DLL不要選 /MT。原因是 dll 之間的內(nèi)存分配和釋放必須共用同一份 CRT如果你用 /MT第三方 dll 用 /MD就會出現(xiàn)在我這邊 new、在你那邊 delete的災難癥狀是隨機崩潰或者內(nèi)存泄漏極難查。4.2 隱式調(diào)用與顯式調(diào)用的取舍隱式調(diào)用就是編譯期鏈接代碼干凈#pragma comment(lib, CalcLib.lib) extern C __declspec(dllimport) int __stdcall Calc_Add(int a, int b); void demo_implicit() { int r Calc_Add(3, 4); printf(Calc_Add %d\n, r); }優(yōu)點是寫起來清爽IDE 能補全。缺點也很致命程序啟動時就必須能找到這個 dll找不到的話整個小程序加載失敗而 TSMaster 那邊給出的提示往往只是一句小程序加載失敗你完全不知道是哪個 dll 的問題。顯式調(diào)用多寫幾行但可控性完全不一樣#include windows.h #include cstdio typedef int (__stdcall *PFN_ADD)(int, int); static PFN_ADD g_pfn_add nullptr; static HMODULE g_hmod nullptr; int ensure_calclib_loaded() { if (g_hmod g_pfn_add) return 0; g_hmod ::LoadLibraryExW( LD:\\Project\\Demo\\libs\\CalcLib.dll, nullptr, LOAD_WITH_ALTERED_SEARCH_PATH); if (!g_hmod) { DWORD err ::GetLastError(); printf([CalcLib] LoadLibrary failed, err%lu\n, err); return (int)err; } g_pfn_add (PFN_ADD)::GetProcAddress(g_hmod, Calc_Add); if (!g_pfn_add) { printf([CalcLib] GetProcAddress failed, err%lu\n, ::GetLastError()); return -1; } return 0; }LOAD_WITH_ALTERED_SEARCH_PATH這個標志的作用前面提過——讓系統(tǒng)從 dll 自己所在的目錄去找它的依賴。當你把依賴 dll 全放在libs目錄里時這個標志幾乎是必須的否則系統(tǒng)會從主程序目錄開始找找不到就報 126。我的建議很明確調(diào)試期一律用顯式調(diào)用把所有錯誤碼都打出來。等接口穩(wěn)定、部署環(huán)境固定了再決定要不要換成隱式。很多時候根本換回來——顯式調(diào)用的那點代碼量換來的可診斷性太值了。4.3 在定時器回調(diào)里調(diào) dll 的注意事項TSMaster 的定時器回調(diào)跑在實時線程上在這個上下文里調(diào)外部 dll有幾條線不能碰。首先不要在回調(diào)里做大塊內(nèi)存分配、磁盤 IO 或Sleep。這些操作會阻塞實時線程表現(xiàn)出來就是定時不準、界面卡頓、報文丟幀。實測過一個案例dll 單次調(diào)用耗時 3 毫秒定時器周期設成 1 毫秒界面上肉眼可見地卡報文時間戳也開始漂。其次一定要搞清楚 dll 是不是線程安全的。很多廠商的 dll 內(nèi)部有全局緩沖區(qū)多個線程同時調(diào)用會互相踩。判斷方法很簡單——看頭文件里有沒有提到線程安全或者不可重入含糊不清的就當它不安全處理。做法是自己加一把臨界區(qū)static CRITICAL_SECTION g_cs; static bool g_cs_inited false; int safe_calc_add(int a, int b) { if (!g_cs_inited) { ::InitializeCriticalSection(g_cs); g_cs_inited true; } ::EnterCriticalSection(g_cs); int r g_pfn_add ? g_pfn_add(a, b) : -1; ::LeaveCriticalSection(g_cs); return r; }第三絕對不要讓 C 異常穿過 dll 邊界。如果你的 dll 和主程序的 CRT 版本不一致異常穿越邊界時會直接終止進程連日志都沒有。規(guī)矩就是dll 內(nèi)部自己try/catch對外只返回錯誤碼一個異常都不許漏出來。第四如果你在回調(diào)里同時用 TSMaster 自身的接口TSApp命名空間那一套和外部 dll功能上沒問題但要注意別在兩邊都做阻塞操作。我一般把外部 dll 的耗時調(diào)用抽到一個獨立工作線程回調(diào)里只投遞任務這樣實時線程永遠輕裝。5. C# 小程序用 DllImport 引入外部接口C# 小程序的平臺調(diào)用寫起來最像聲明一下就能用但封送處理有它自己的坑。5.1 簽名聲明與封送處理using System; using System.Runtime.InteropServices; public static class CalcLib { [DllImport(CalcLib.dll, CallingConvention CallingConvention.StdCall, CharSet CharSet.Ansi)] public static extern int Calc_Add(int a, int b); [DllImport(CalcLib.dll, CallingConvention CallingConvention.Cdecl)] public static extern int Calc_CRC16(byte[] data, int len, out ushort crc); }幾個要點。CallingConvention的默認值是StdCall對應Winapi但很多 C 庫是Cdecl必須顯式寫清楚。雖然現(xiàn)在 64 位下 Windows 的調(diào)用約定已經(jīng)統(tǒng)一了寫清楚的好處是將來萬一要切 32 位不會莫名其妙地崩。out ushort會被自動封送成指針比在 C 里手寫指針舒服得多。結(jié)構(gòu)體要顯式標注布局和對齊[StructLayout(LayoutKind.Sequential, Pack 1)] public struct CanFrame { public uint Id; public byte Dlc; [MarshalAs(UnmanagedType.ByValArray, SizeConst 8)] public byte[] Data; public ulong Timestamp; }Pack要和 C 側(cè)的#pragma pack一致。結(jié)構(gòu)體里有定長字符串時用[MarshalAs(UnmanagedType.ByValTStr, SizeConst 32)]配CharSet.Ansi能自動幫你做 ANSI 和 Unicode 的轉(zhuǎn)換。dll 的加載路徑是另一個坑。C# 小程序的 dll 搜索路徑和主進程有關最穩(wěn)的辦法是顯式設置搜索目錄[DllImport(kernel32.dll, CharSet CharSet.Unicode, SetLastError true)] private static extern bool SetDllDirectory(string lpPathName); SetDllDirectory(D:\Project\Demo\libs);不要圖省事把 dll 復制到 TSMaster 主程序目錄那會讓安裝目錄越來越亂而且換臺機器就失效。5.2 內(nèi)存生命周期與托管對象釘住數(shù)組傳給非托管代碼時有個隱蔽陷阱如果 dll 把這個指針存起來了、稍后再用那么 GC 一旦壓縮堆數(shù)組就被移動了dll 手里那個指針就變成了野指針。這種場景必須把托管對象釘住var buffer new byte[4096]; var handle GCHandle.Alloc(buffer, GCHandleType.Pinned); try { IntPtr ptr handle.AddrOfPinnedObject(); // 把 ptr 傳給 dll } finally { handle.Free(); // 必須釋放否則句柄泄漏 }回調(diào)這塊和 Python 是同一類問題。委托必須有人持有引用否則 GC 回收之后非托管側(cè)的回調(diào)就跳飛了。做法是把委托存成靜態(tài)字段或者在調(diào)用完之后加一句GC.KeepAlive(callback)。還有一條規(guī)矩要記牢誰分配的內(nèi)存誰釋放。dll 里分配的內(nèi)存一定要用 dll 自己導出的釋放函數(shù)去釋放絕對不要在 C# 里調(diào)Marshal.FreeHGlobal去放掉——兩邊的堆管理器不一樣這么干必崩。6. 報錯排查速查表與實測踩坑記錄6.1 加載失敗類報錯速查報錯含義最可能的原因處理辦法WinError 126找不到模塊依賴缺失少了 VC 運行庫或依賴 dll依賴分析工具查紅色節(jié)點補齊依賴WinError 193不是有效 Win32 程序位數(shù)不匹配64 位宿主加載 32 位 dlldumpbin /headers確認位數(shù)WinError 127找不到指定程序?qū)С雒环中揎?、拼寫錯誤、大小寫dumpbin /exports核對導出名WinError 1114DLL 初始化例程失敗DllMain 出錯dll 在 DllMain 里加載別的 dll 或建線程找廠商確認或用顯式延遲加載繞開加載成功但行為不對dll 沖突同名老版本已被搶先加載絕對路徑 獨立目錄隔離WinError 1114這個特別值得說一句。它出現(xiàn)的時候通常意味著 dll 的DllMain里干了不該干的事——比如在DLL_PROCESS_ATTACH階段去調(diào)用LoadLibrary加載另一個 dll、創(chuàng)建線程、或者調(diào)用會阻塞的同步 API。Windows 的加載鎖還在持有狀態(tài)這些操作就會死鎖或者失敗。如果廠商不給你源碼唯一的辦法是繞開把 dll 的加載推遲到實際調(diào)用的時候顯式LoadLibrary而不是在進程啟動階段就讓它被隱式加載。6.2 調(diào)用即崩潰類問題調(diào)用一次就崩和調(diào)用兩次才崩是兩種完全不同的問題不要混在一起查。調(diào)用一次就崩八成是參數(shù)類型或調(diào)用約定錯了。檢查順序先確認stdcall還是cdecl再確認參數(shù)寬度int和long在 64 位下都是 4 字節(jié)但size_t是 8 字節(jié)unsigned long在 Windows 上也是 4 字節(jié)unsigned long long是 8 字節(jié)最后確認結(jié)構(gòu)體對齊。Python 側(cè)特別容易犯的錯是沒寫argtypes導致指針被當成int截斷。調(diào)用兩次才崩基本就是回調(diào)對象被 GC 回收了或者某個緩沖區(qū)被寫越界、破壞了相鄰內(nèi)存。回調(diào)的問題前面講過了解決辦法就是把回調(diào)對象存成長生命周期變量。緩沖區(qū)越界的問題可以在 Python 側(cè)把緩沖區(qū)開大一圈前后各留 32 字節(jié)的哨兵調(diào)完之后檢查哨兵有沒有被改寫能快速判斷是不是越界寫。6.3 結(jié)果不對但不崩的問題這一類最難查因為沒有任何報錯。常見的三種情況我按出現(xiàn)頻率排一下。排第一的是字符串編碼。前面說過char*在中文 Windows 上基本都是 GBK你按 UTF-8 編過去就會亂碼。排查辦法很簡單——傳一個純英文串過去如果正常基本就是編碼問題。排第二的是結(jié)構(gòu)體對齊。C 側(cè)用了#pragma pack(1)Python 側(cè)沒寫_pack_ 1字段偏移全錯你會看到 ID 和 DLC 好像對得上但時間戳完全離譜。這種部分字段正確的現(xiàn)象是對齊問題的典型特征。排第三的是返回值語義理解錯了。有些 dll 返回的是實際寫入的字節(jié)數(shù)有些返回的是錯誤碼有些返回 0 表示成功、有些返回 0 表示失敗。這種事只能翻文檔或者做實驗確認——給一組已知輸入看返回值是不是符合你的預期。6.4 一套固定的排查流程踩了足夠多次之后我固化下來一套排查順序從下往上打基本能在二十分鐘內(nèi)定位到問題用dumpbin /headers確認位數(shù)和宿主進程一致用dumpbin /exports把導出名原樣抄下來別憑記憶拼用依賴分析工具打開 dll把紅色節(jié)點全部解決掉改成絕對路徑加載加上LOAD_WITH_ALTERED_SEARCH_PATH先在 Python 里最小化復現(xiàn)把參數(shù)、返回值、編碼全部驗證正確再把驗證過的調(diào)用原樣搬到 C 小程序或 C#全程打日志——加載結(jié)果、每次調(diào)用的參數(shù)和返回值、錯誤碼一個都不省。第 5 步是我最想強調(diào)的。很多人上來就在 C 小程序里硬剛編譯半天加載失敗只會給一句模糊提示來回折騰幾個小時。同樣的邏輯用 Python 寫十行代碼報錯清清楚楚十幾分鐘就能確認 dll 本身有沒有問題。確認沒問題了再搬效率差好幾倍。7. 一些不成體系但很值錢的經(jīng)驗cts里加載 dll 的時候WinDLL和CDLL的選擇可以現(xiàn)場驗證。如果你不確定調(diào)用約定可以兩個都試一次哪個不崩就是哪個——這個方法土但有效前提是崩的是 Python 進程而不是整個 TSMaster。所以務必先在獨立的 Python 環(huán)境里做這個實驗別在 TSMaster 里試。dll 目錄隔離這件事我的做法是每個第三方庫單獨一個子目錄目錄名帶上版本號。這樣做的直接好處是同名不同版本的 dll 永遠不會互相干擾出問題的時候也知道該退回到哪個版本。代價是磁盤上多幾份文件這個代價值得付。關于調(diào)試有個小技巧特別管用在 Python 側(cè)寫一個probe.py腳本內(nèi)容就是把 dll 加載一遍、把每個導出符號打印出來、用一組固定輸入跑一遍調(diào)用。換機器、換版本、換編譯器的時候先跑這個腳本二十秒就能判斷環(huán)境是不是健康的。這個腳本我改過七八個版本現(xiàn)在是每次接手新 dll 的第一件事。最后一個經(jīng)驗是關于文檔的。廠商給的 PDF 里參數(shù)表和返回值說明通常寫得像謎語。真正靠譜的做法是拿 dll 去打邊界值——傳 0、傳負數(shù)、傳超大值看它返回什么、會不會崩。打完之后你對這個 dll 的脾氣就有底了比讀十頁文檔管用。當然這個實驗必須在隔離的 Python 環(huán)境里做崩了也不影響 TSMaster 主進程。