1. 問(wèn)題初探當(dāng)你的C#應(yīng)用在KERNELBASE.dll處崩潰如果你正在維護(hù)一個(gè)基于.NET Framework 4.0.30319的C#應(yīng)用程序突然在客戶現(xiàn)場(chǎng)或生產(chǎn)環(huán)境遇到一個(gè)彈窗告訴你程序崩潰了錯(cuò)誤模塊指向KERNELBASE.dll異常信息卻是System.Data.SqlClient.SqlException你的第一反應(yīng)是什么是數(shù)據(jù)庫(kù)連接斷了還是代碼有bug這個(gè)組合錯(cuò)誤信息非常典型也極具迷惑性。表面上看這是一個(gè)數(shù)據(jù)庫(kù)異常但崩潰點(diǎn)卻在Windows系統(tǒng)的核心模塊KERNELBASE.dll。這通常意味著一個(gè)未被妥善處理的數(shù)據(jù)庫(kù)異常SqlException最終“逃逸”到了應(yīng)用程序的頂層觸發(fā)了系統(tǒng)的結(jié)構(gòu)化異常處理SEH機(jī)制而KERNELBASE.dll正是Windows中負(fù)責(zé)處理這類未處理異常并最終終止進(jìn)程的關(guān)鍵模塊之一。簡(jiǎn)單來(lái)說(shuō)你的程序里有一個(gè)地方在訪問(wèn)數(shù)據(jù)庫(kù)比如執(zhí)行SqlCommand.ExecuteReader()發(fā)生了錯(cuò)誤比如連接超時(shí)、查詢語(yǔ)法錯(cuò)誤、權(quán)限不足但這個(gè)錯(cuò)誤沒(méi)有被try-catch塊捕獲或者在一個(gè)錯(cuò)誤的線程上下文如非UI線程中拋出后未被處理。這個(gè)未處理的異常像一顆沒(méi)有被攔截的子彈一路向上穿透最終被操作系統(tǒng)“接住”操作系統(tǒng)為了維護(hù)系統(tǒng)穩(wěn)定性只能強(qiáng)制終止你的進(jìn)程并在事件查看器或錯(cuò)誤報(bào)告中留下KERNELBASE.dll這個(gè)“案發(fā)現(xiàn)場(chǎng)”的記錄。所以核心問(wèn)題不是KERNELBASE.dll壞了而是你的程序沒(méi)有處理好自己的“家務(wù)事”——數(shù)據(jù)庫(kù)訪問(wèn)異常。這個(gè)問(wèn)題在WinForms、WPF這類桌面客戶端或者一些老舊的ASP.NET WebForms應(yīng)用中尤為常見(jiàn)。這些應(yīng)用通常有復(fù)雜的UI線程和后臺(tái)工作線程異常處理稍有不慎就會(huì)導(dǎo)致程序靜默崩潰用戶體驗(yàn)極差。接下來(lái)我們就深入拆解這個(gè)問(wèn)題從原理到實(shí)操一步步教你如何定位、分析和解決它。2. 核心原理SqlException為何會(huì)“擊穿”到KERNELBASE要徹底理解這個(gè)問(wèn)題我們需要拆解兩個(gè)關(guān)鍵部分System.Data.SqlClient.SqlException的本質(zhì)和KERNELBASE.dll的角色。2.1 SqlException的誕生與傳播System.Data.SqlClient.SqlException是.NET Framework中用于表示所有與SQL Server通信相關(guān)錯(cuò)誤的異常類。當(dāng)你調(diào)用SqlConnection.Open()、SqlCommand.ExecuteNonQuery()等方法時(shí)底層的.NET數(shù)據(jù)提供程序會(huì)通過(guò)TDS協(xié)議與SQL Server通信。一旦服務(wù)器返回一個(gè)錯(cuò)誤錯(cuò)誤號(hào)10或者網(wǎng)絡(luò)超時(shí)、連接中斷客戶端驅(qū)動(dòng)程序就會(huì)構(gòu)造一個(gè)SqlException實(shí)例并將其拋出。這個(gè)異常包含了豐富的信息遠(yuǎn)不止一個(gè)錯(cuò)誤消息。通過(guò)它的屬性我們可以精準(zhǔn)定位問(wèn)題Number: SQL Server的錯(cuò)誤號(hào)。比如18456是登錄失敗547是外鍵約束沖突2627是主鍵/唯一鍵沖突。這是診斷數(shù)據(jù)庫(kù)層面問(wèn)題的首要依據(jù)。Message: 人類可讀的錯(cuò)誤描述。Class: 錯(cuò)誤的嚴(yán)重級(jí)別16-25。通常16-19是用戶可糾正的錯(cuò)誤20-25是嚴(yán)重錯(cuò)誤如硬件故障。State: SQL Server內(nèi)部的狀態(tài)碼有時(shí)對(duì)微軟技術(shù)支持有用。Server: 發(fā)生錯(cuò)誤的服務(wù)器名稱。Procedure和LineNumber: 如果錯(cuò)誤發(fā)生在存儲(chǔ)過(guò)程中這里會(huì)指明是哪個(gè)存儲(chǔ)過(guò)程的哪一行。Errors集合: 一個(gè)SqlError對(duì)象的集合因?yàn)橐淮尾僮骺赡墚a(chǎn)生多個(gè)錯(cuò)誤。關(guān)鍵在于這個(gè)異常必須在它被拋出的地方被捕獲和處理。如果在一個(gè)按鈕點(diǎn)擊事件中執(zhí)行數(shù)據(jù)庫(kù)操作而沒(méi)有try-catch那么異常就會(huì)沿著調(diào)用棧向上冒泡。在WinForms/WPF應(yīng)用中如果這個(gè)冒泡過(guò)程發(fā)生在UI線程主線程上并且沒(méi)有被應(yīng)用程序的全局異常處理程序如Application.ThreadException或AppDomain.CurrentDomain.UnhandledException捕獲那么它就會(huì)成為一個(gè)“未處理的UI線程異?！薄?duì)于非UI線程如ThreadPool.QueueUserWorkItem或Task.Run創(chuàng)建的線程如果異常未被捕獲它會(huì)導(dǎo)致線程終止并且默認(rèn)情況下這個(gè)異常會(huì)被“吞噬”你甚至看不到錯(cuò)誤彈窗但程序行為會(huì)變得詭異。然而在某些配置或特定情況下非UI線程的未處理異常也可能最終觸發(fā)進(jìn)程終止。2.2 KERNELBASE.dll與未處理異常終結(jié)者KERNELBASE.dll是Windows操作系統(tǒng)的一個(gè)核心系統(tǒng)模塊它包含了大量實(shí)現(xiàn)Windows API基礎(chǔ)功能的代碼其中就包括結(jié)構(gòu)化異常處理SEH的底層機(jī)制。當(dāng)托管代碼.NET程序中發(fā)生了一個(gè)未處理的異常并且這個(gè)異常穿透了所有托管層的異常處理屏障包括AppDomain.UnhandledException事件這個(gè)事件本身并不阻止進(jìn)程終止它只是一個(gè)通知CLR公共語(yǔ)言運(yùn)行時(shí)會(huì)將其轉(zhuǎn)換為一個(gè)Windows結(jié)構(gòu)化異常然后交由操作系統(tǒng)處理。操作系統(tǒng)看到這個(gè)來(lái)自應(yīng)用程序的未處理異常為了阻止一個(gè)行為異常的程序影響整個(gè)系統(tǒng)的穩(wěn)定性會(huì)啟動(dòng)默認(rèn)的異常處理流程。在Windows中對(duì)于控制臺(tái)程序可能會(huì)彈出一個(gè)“是否調(diào)試”的對(duì)話框?qū)τ贕UI程序如果沒(méi)有附加調(diào)試器則會(huì)顯示一個(gè)類似于“XXX已停止工作”的錯(cuò)誤報(bào)告對(duì)話框并生成一個(gè)崩潰轉(zhuǎn)儲(chǔ)dump文件。這個(gè)終止進(jìn)程并生成報(bào)告的關(guān)鍵邏輯有一部分就實(shí)現(xiàn)在KERNELBASE.dll中。因此在錯(cuò)誤報(bào)告中看到KERNELBASE.dll就像是看到了“死刑執(zhí)行者”的簽名它告訴你進(jìn)程是因?yàn)橐粋€(gè)未被內(nèi)部消化的嚴(yán)重錯(cuò)誤而被外部力量操作系統(tǒng)終結(jié)的而錯(cuò)誤的根源需要從異常信息這里是SqlException中去尋找。一個(gè)關(guān)鍵的心得不要被KERNELBASE.dll嚇到也不要試圖去“修復(fù)”這個(gè)系統(tǒng)文件。它只是一個(gè)信使告訴你程序內(nèi)部發(fā)生了“叛亂”未處理異常。你的所有調(diào)查精力都應(yīng)該集中在為什么SqlException沒(méi)有被妥善處理上。3. 深度診斷定位未處理SqlException的源頭當(dāng)崩潰發(fā)生后僅僅知道是未處理的SqlException還不夠我們必須找到是哪一行代碼、哪一個(gè)操作引發(fā)了這個(gè)問(wèn)題。由于崩潰發(fā)生在生產(chǎn)環(huán)境或用戶端我們通常無(wú)法直接附加調(diào)試器。這時(shí)就需要依靠日志和轉(zhuǎn)儲(chǔ)文件。3.1 啟用并解析應(yīng)用程序日志首先確保你的應(yīng)用程序有健全的日志系統(tǒng)。對(duì)于.NET Framework 4.0的應(yīng)用log4net或NLog是經(jīng)典選擇。你需要在所有可能拋出SqlException的數(shù)據(jù)訪問(wèn)層DAL方法中進(jìn)行細(xì)致的異常記錄。一個(gè)常見(jiàn)的錯(cuò)誤是只在最外層的UI事件處理器中有一個(gè)籠統(tǒng)的try-catch然后簡(jiǎn)單地記錄ex.Message。這遠(yuǎn)遠(yuǎn)不夠。對(duì)于SqlException你必須記錄其Number和完整的ToString()信息。public User GetUserById(int userId) { string sql “SELECT * FROM Users WHERE Id Id”; try { using (var connection new SqlConnection(_connectionString)) using (var command new SqlCommand(sql, connection)) { command.Parameters.AddWithValue(“Id”, userId); connection.Open(); using (var reader command.ExecuteReader()) { // ... 映射邏輯 } } } catch (SqlException sqlEx) { // 糟糕的日志只記消息丟失關(guān)鍵信息 // _logger.Error($“數(shù)據(jù)庫(kù)錯(cuò)誤: {sqlEx.Message}“); // 正確的日志記錄所有診斷信息 _logger.Error($“SQL錯(cuò)誤 [Number:{sqlEx.Number}, State:{sqlEx.State}, Class:{sqlEx.Class}]。服務(wù)器: {sqlEx.Server}。錯(cuò)誤信息: {sqlEx.Message}“); _logger.Error($“完整異常: {sqlEx.ToString()}“); // 根據(jù)錯(cuò)誤號(hào)決定是向上拋出業(yè)務(wù)異常還是直接處理 if (sqlEx.Number 547) // 外鍵約束沖突 { throw new BusinessException(“該記錄被其他數(shù)據(jù)引用無(wú)法刪除?！?; } else { throw; // 重新拋出由上層統(tǒng)一處理 } } catch (Exception ex) { _logger.Error($“獲取用戶信息時(shí)發(fā)生未知異常: {ex.ToString()}“); throw; } }如果崩潰發(fā)生時(shí)日志文件里恰好有一條SqlException記錄那么恭喜你問(wèn)題已經(jīng)定位了一大半。你需要重點(diǎn)關(guān)注這條記錄前后的操作和錯(cuò)誤號(hào)。3.2 獲取與分析崩潰轉(zhuǎn)儲(chǔ)文件如果日志沒(méi)有捕獲到異常例如異常發(fā)生在一個(gè)根本沒(méi)有日志記錄的代碼路徑上或者日志系統(tǒng)本身初始化失敗了那么崩潰轉(zhuǎn)儲(chǔ)文件就是最后的“救命稻草”。Windows錯(cuò)誤報(bào)告會(huì)在程序崩潰時(shí)生成一個(gè).dmp文件通常位于C:\Users\[用戶名]\AppData\Local\CrashDumps或C:\Windows\LiveKernelReports等目錄。你可以要求用戶或運(yùn)維人員提供這個(gè)轉(zhuǎn)儲(chǔ)文件。拿到.dmp文件后你需要使用調(diào)試工具來(lái)分析它。工具準(zhǔn)備安裝WindbgWindows Debugger或使用Visual Studio。對(duì)于.NET程序更推薦使用Visual Studio因?yàn)樗鼘?duì)托管代碼的符號(hào)支持和分析更友好。加載轉(zhuǎn)儲(chǔ)文件用Visual Studio打開(kāi).dmp文件。設(shè)置符號(hào)路徑在“調(diào)試”-“窗口”-“模塊”中確保能加載clr.dll、mscorlib.dll等.NET運(yùn)行庫(kù)的符號(hào)pdb文件。你可以配置符號(hào)服務(wù)器如微軟的官方服務(wù)器https://msdl.microsoft.com/download/symbols。分析異常Visual Studio通常會(huì)直接顯示崩潰時(shí)的異常信息和調(diào)用堆棧。在“調(diào)用堆棧”窗口中你應(yīng)該能看到從KERNELBASE!RaiseException開(kāi)始回溯到你的應(yīng)用程序代碼中拋出SqlException的那一行。查看線程和變量檢查崩潰線程的局部變量特別是與數(shù)據(jù)庫(kù)連接、命令文本、參數(shù)相關(guān)的變量這能幫你重建崩潰時(shí)的現(xiàn)場(chǎng)。注意分析轉(zhuǎn)儲(chǔ)文件需要對(duì)應(yīng)的應(yīng)用程序的PDB程序數(shù)據(jù)庫(kù)文件。因此在發(fā)布版本時(shí)務(wù)必保留生成的PDB文件并將其與可執(zhí)行文件一起存檔。沒(méi)有PDB你只能看到匯編代碼很難定位到具體的C#源代碼行。3.3 通過(guò)事件查看器獲取線索除了應(yīng)用程序自身的日志和轉(zhuǎn)儲(chǔ)文件Windows事件查看器也是一個(gè)寶貴的信息源。打開(kāi)“事件查看器”導(dǎo)航到“Windows 日志”-“應(yīng)用程序”。在右側(cè)的事件列表中查找來(lái)源為“.NET Runtime”或你的應(yīng)用程序名稱、級(jí)別為“錯(cuò)誤”的事件。雙擊打開(kāi)事件在“常規(guī)”選項(xiàng)卡中你會(huì)看到類似這樣的信息應(yīng)用程序: YourApp.exe Framework 版本: v4.0.30319 說(shuō)明: 由于未經(jīng)處理的異常進(jìn)程終止。 異常信息: System.Data.SqlClient.SqlException 在 YourApp.DataAccess.UserRepository.GetUserById(Int32) 在 YourApp.Business.UserService.GetUserDetails(Int32) ...這個(gè)堆棧跟蹤直接指明了異常是從UserRepository.GetUserById這個(gè)方法開(kāi)始拋出的并且一路向上沒(méi)有被處理。事件查看器提供的堆棧信息通常比錯(cuò)誤彈窗更完整是快速定位問(wèn)題的利器。4. 系統(tǒng)性解決方案構(gòu)建異常處理防線找到問(wèn)題根源后我們需要從架構(gòu)和編碼層面建立多道防線防止任何一個(gè)SqlException或其他異常成為“漏網(wǎng)之魚(yú)”最終導(dǎo)致進(jìn)程崩潰。4.1 第一道防線數(shù)據(jù)訪問(wèn)層的精細(xì)化捕獲與轉(zhuǎn)換數(shù)據(jù)訪問(wèn)層DAL是SqlException的源頭。這里的原則是捕獲、記錄、轉(zhuǎn)換。捕獲所有Sql操作在每個(gè)執(zhí)行SQL命令的方法內(nèi)部使用try-catch。記錄完整信息如上文所述使用日志框架記錄SqlException的所有關(guān)鍵屬性。轉(zhuǎn)換為業(yè)務(wù)異常不要將原始的SqlException直接拋給上層如業(yè)務(wù)邏輯層或UI層。SqlException是技術(shù)細(xì)節(jié)上層可能不關(guān)心錯(cuò)誤號(hào)。應(yīng)該根據(jù)錯(cuò)誤號(hào)將其轉(zhuǎn)換為有明確業(yè)務(wù)語(yǔ)義的自定義異常。catch (SqlException sqlEx) when (sqlEx.Number 18456 || sqlEx.Number 4060) { _logger.Error($“數(shù)據(jù)庫(kù)登錄失敗: {sqlEx.Message}“); throw new DataAccessException(“無(wú)法連接到數(shù)據(jù)庫(kù)請(qǐng)檢查網(wǎng)絡(luò)或聯(lián)系管理員。”, sqlEx); } catch (SqlException sqlEx) when (sqlEx.Number 547) { _logger.Error($“違反外鍵約束操作被拒絕?！?; throw new BusinessRuleViolationException(“該數(shù)據(jù)正在被使用無(wú)法刪除?！?; } catch (SqlException sqlEx) { _logger.Error($“未預(yù)期的數(shù)據(jù)庫(kù)錯(cuò)誤: {sqlEx}“); throw new DataAccessException(“執(zhí)行數(shù)據(jù)庫(kù)操作時(shí)發(fā)生錯(cuò)誤?！? sqlEx); // 包裝原異常 }這樣上層代碼捕獲到的是DataAccessException或BusinessRuleViolationException它們更清晰也避免了UI層直接依賴System.Data.SqlClient命名空間。4.2 第二道防線全局異常處理事件這是防止未處理異常導(dǎo)致進(jìn)程崩潰的最后一道托管代碼防線。對(duì)于不同類型的應(yīng)用程序設(shè)置方式不同。WinForms 應(yīng)用程序在Program.cs的Main方法中或應(yīng)用程序啟動(dòng)時(shí)添加以下代碼[STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); // 處理UI線程異常 Application.ThreadException new ThreadExceptionEventHandler(Application_ThreadException); // 設(shè)置UI線程的異常處理模式重要 Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); // 處理非UI線程的未處理異常 AppDomain.CurrentDomain.UnhandledException new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); Application.Run(new MainForm()); } static void Application_ThreadException(object sender, ThreadExceptionEventArgs e) { // 處理UI線程上拋出的未處理異常 // 這里可以進(jìn)行友好提示、記錄日志等操作 _logger.Fatal(“UI線程發(fā)生未處理異常程序?qū)⑼顺觥！? e.Exception); MessageBox.Show($“程序遇到意外錯(cuò)誤即將關(guān)閉。錯(cuò)誤信息{e.Exception.Message}“, “錯(cuò)誤”, MessageBoxButtons.OK, MessageBoxIcon.Error); // 記錄完日志后可以安全退出 Application.Exit(); } static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) { // 處理非UI線程的未處理異常 Exception ex e.ExceptionObject as Exception; _logger.Fatal($“非UI線程發(fā)生未處理異常。是否即將終止: {e.IsTerminating}“, ex); // 注意在這個(gè)事件處理程序中應(yīng)用程序域可能即將卸載不要做太多操作 // 通常只能進(jìn)行緊急日志記錄 }WPF 應(yīng)用程序在App.xaml.cs中重寫(xiě)OnStartup方法并訂閱事件public partial class App : Application { protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); // 處理UI線程異常 this.DispatcherUnhandledException App_DispatcherUnhandledException; // 處理非UI線程異常 AppDomain.CurrentDomain.UnhandledException CurrentDomain_UnhandledException; } private void App_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) { _logger.Fatal(“UI調(diào)度器線程發(fā)生未處理異常?！? e.Exception); MessageBox.Show($“發(fā)生未預(yù)期錯(cuò)誤{e.Exception.Message}“, “錯(cuò)誤”, MessageBoxButton.OK, MessageBoxImage.Error); e.Handled true; // 標(biāo)記為已處理阻止進(jìn)程崩潰 // 注意將e.Handled設(shè)為true后程序會(huì)繼續(xù)運(yùn)行但可能處于不穩(wěn)定狀態(tài)通常建議安全關(guān)閉。 this.Shutdown(); } private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) { Exception ex e.ExceptionObject as Exception; _logger.Fatal($“應(yīng)用程序域發(fā)生未處理異常。是否終止: {e.IsTerminating}“, ex); } }重要提示AppDomain.CurrentDomain.UnhandledException事件中即使你處理了異常也無(wú)法阻止CLR終止進(jìn)程對(duì)于非UI線程的嚴(yán)重未處理異常。e.IsTerminating屬性會(huì)告訴你進(jìn)程是否即將結(jié)束。這個(gè)事件主要用于最后的日志記錄和資源清理而不是恢復(fù)程序運(yùn)行。4.3 第三道防線異步代碼與Task的異常處理如果你的應(yīng)用使用了async/await或直接操作Task需要特別注意Task中未觀察到的異常Unobserved Task Exception默認(rèn)不會(huì)立即導(dǎo)致進(jìn)程崩潰但在.NET Framework 4.0及更高版本的某些配置下它可能會(huì)在垃圾回收器最終化Task時(shí)觸發(fā)AppDomain.CurrentDomain.UnhandledException事件從而導(dǎo)致進(jìn)程終止。處理方式// 1. 始終等待awaitTask或者訪問(wèn)其Result/Exception屬性。 try { await SomeAsyncDatabaseOperation(); } catch (SqlException ex) { // 處理異常 } // 2. 如果使用Task.Run或Task.Factory.StartNew創(chuàng)建“即發(fā)即棄”的任務(wù)務(wù)必使用ContinueWith處理異常。 Task.Run(() DoDangerousWork()) .ContinueWith(t { if (t.IsFaulted) { _logger.Error(“后臺(tái)任務(wù)失敗”, t.Exception?.InnerException ?? t.Exception); } }, TaskScheduler.FromCurrentSynchronizationContext()); // 如果需要回到UI線程 // 3. 訂閱全局的未觀察任務(wù)異常事件.NET 4.5對(duì).NET 4.0需注意版本行為 TaskScheduler.UnobservedTaskException (sender, args) { _logger.Error(“捕獲到未觀察的Task異?！? args.Exception); args.SetObserved(); // 標(biāo)記為已觀察防止觸發(fā)進(jìn)程終止 };5. 實(shí)戰(zhàn)排查清單與進(jìn)階技巧當(dāng)你面對(duì)一個(gè)具體的“KERNELBASE.dll SqlException”崩潰報(bào)告時(shí)可以按照以下清單進(jìn)行排查檢查連接字符串確認(rèn)數(shù)據(jù)庫(kù)服務(wù)器地址、名稱、用戶名、密碼是否正確。特別是當(dāng)程序從開(kāi)發(fā)環(huán)境部署到生產(chǎn)環(huán)境時(shí)連接字符串是否已更新。檢查網(wǎng)絡(luò)與防火墻客戶端機(jī)器能否ping通數(shù)據(jù)庫(kù)服務(wù)器1433端口SQL Server默認(rèn)端口是否開(kāi)放檢查數(shù)據(jù)庫(kù)狀態(tài)與權(quán)限登錄的賬號(hào)是否有執(zhí)行特定操作SELECT, INSERT, UPDATE, DELETE, EXEC的權(quán)限數(shù)據(jù)庫(kù)是否在線審查SQL命令與參數(shù)是否是動(dòng)態(tài)拼接的SQL導(dǎo)致了語(yǔ)法錯(cuò)誤或SQL注入風(fēng)險(xiǎn)參數(shù)化查詢是否使用正確參數(shù)的值是否為NULL或格式不正確檢查資源管理是否使用了using語(yǔ)句確保SqlConnection,SqlCommand,SqlDataReader被及時(shí)釋放連接泄露會(huì)導(dǎo)致連接池耗盡進(jìn)而引發(fā)超時(shí)異常。超時(shí)配置SqlCommand.CommandTimeout屬性默認(rèn)是30秒。對(duì)于復(fù)雜查詢或網(wǎng)絡(luò)慢的環(huán)境這個(gè)時(shí)間可能不夠?？梢赃m當(dāng)增加但也要防止無(wú)限等待。并發(fā)與鎖異常是否只在多用戶同時(shí)操作時(shí)發(fā)生可能是死鎖或阻塞。檢查SQL Server的錯(cuò)誤日志或使用SQL Server Profiler跟蹤死鎖事件。框架與驅(qū)動(dòng)版本確認(rèn)服務(wù)器上的.NET Framework版本和SQL Server Native Client或ODBC驅(qū)動(dòng)版本是否與開(kāi)發(fā)環(huán)境一致。有時(shí)更新驅(qū)動(dòng)可以解決一些兼容性問(wèn)題。進(jìn)階技巧使用MiniDump進(jìn)行現(xiàn)場(chǎng)保留如果問(wèn)題難以復(fù)現(xiàn)可以在全局異常處理程序中編程生成一個(gè)完整的內(nèi)存轉(zhuǎn)儲(chǔ)文件這比系統(tǒng)自動(dòng)生成的小型轉(zhuǎn)儲(chǔ)包含更多信息如所有線程的堆棧、堆內(nèi)存數(shù)據(jù)。using System.Diagnostics; using System.Runtime.InteropServices; using Microsoft.Win32.SafeHandles; static void CreateMiniDump() { string dumpPath Path.Combine(Path.GetTempPath(), $“YourApp_Crash_{DateTime.Now:yyyyMMdd_HHmmss}.dmp”); using (FileStream fs new FileStream(dumpPath, FileMode.Create)) { // 需要引用Windows API // 這里調(diào)用MiniDumpWriteDump函數(shù)代碼略復(fù)雜可搜索相關(guān)實(shí)現(xiàn) // 生成后可以將dumpPath路徑記錄到日志方便后續(xù)取用分析 } } // 在CurrentDomain_UnhandledException或類似地方調(diào)用CreateMiniDump()生成完整轉(zhuǎn)儲(chǔ)后結(jié)合日志和源代碼幾乎可以100%還原崩潰現(xiàn)場(chǎng)。處理KERNELBASE.dll處的SqlException崩潰本質(zhì)上是一場(chǎng)關(guān)于異常處理紀(jì)律的戰(zhàn)役。從數(shù)據(jù)訪問(wèn)層的細(xì)致捕獲和轉(zhuǎn)換到全局異常事件的兜底再到異步編程模型的正確使用每一環(huán)都不可或缺。建立起這套防御體系后你的C#應(yīng)用程序的健壯性將得到質(zhì)的提升用戶再也不會(huì)看到那個(gè)令人沮喪的“已停止工作”對(duì)話框取而代之的是友好的錯(cuò)誤提示和穩(wěn)定的程序行為。記住好的錯(cuò)誤處理不是讓程序永不報(bào)錯(cuò)而是讓錯(cuò)誤以可控、可理解、可修復(fù)的方式呈現(xiàn)出來(lái)。