錯誤檢查0x139：KERNEL_SECURITY_CHECK_FAILURE
KERNEL_SECURITY_CHECK_FAILURE錯誤檢查的值為 0x00000139。 這個錯誤檢查表示核心偵測到重大數據結構的損毀。
重要
本文適用於程式設計人員。 如果您是在使用計算機時收到藍色畫面錯誤碼的客戶，請參閱 針對藍色畫面錯誤進行疑難解答。
錯誤檢查0x139 KERNEL_SECURITY_CHECK_FAILURE參數
| 參數 | 描述 |
|---|---|
| 1 | 損毀的類型。 如需詳細資訊，請參閱下表。 |
| 2 | 造成錯誤檢查之例外狀況的陷阱框架位址 |
| 3 | 造成錯誤檢查之例外狀況的例外狀況記錄位址 |
| 4 | 已保留 |
下表描述參數 1 的可能值。
| 參數 1 | 描述 |
|---|---|
| 0 | 堆疊型緩衝區已滿溢（舊版 /GS 違規）。 |
| 1 | VTGuard 檢測程式代碼偵測到嘗試使用非法虛擬函式數據表。 一般而言，C++物件已損毀，然後使用損毀對象的 這個 指標嘗試虛擬方法呼叫。 |
| 2 | 堆疊 Cookie 檢測程式代碼偵測到堆疊型緩衝區超支（/GS 違規）。 |
| 3 | LIST_ENTRY已損毀（例如，雙重移除）。 如需詳細資訊，請參閱下列原因一節。 |
| 4 | 已保留 |
| 5 | 無效的參數傳遞至考慮無效參數的函式。 |
| 6 | 載入器未正確初始化堆疊 Cookie 安全性 Cookie。 這可能是因為建置驅動程式只在 Windows 8 上執行，並嘗試在舊版 Windows 上載入驅動程式映像。 若要避免這個問題，您必須建置驅動程式，才能在舊版 Windows 上執行。 |
| 7 | 已要求嚴重程序結束。 |
| 8 | 編譯程式插入的數位界限檢查偵測到不合法的數位索引作業。 |
| 9 | 對 RtlQueryRegistryValues 的呼叫是在沒有RTL_QUERY_REGISTRY_TYPECHECK的情況下指定RTL_QUERY_REGISTRY_DIRECT，而且目標值不在受信任的系統 Hive 中。 |
| 10 | 間接呼叫防護檢查偵測到無效的控制傳輸。 |
| 11 | 寫入防護檢查偵測到無效的記憶體寫入。 |
| 12 | 嘗試切換到無效的光纖內容。 |
| 13 | 嘗試指派無效的緩存器內容。 |
| 14 | 對象的參考計數無效。 |
| 18 | 嘗試切換至無效jmp_buf內容。 |
| 19 | 對唯讀數據進行了不安全的修改。 |
| 20 | 密碼編譯自我測試失敗。 |
| 21 | 偵測到無效的例外狀況鏈結。 |
| 22 | 發生密碼編譯連結庫錯誤。 |
| 23 | DllMain 內發出無效的呼叫。 |
| 24 | 偵測到無效的映像基位址。 |
| 25 | 保護延遲載入時發生無法復原的失敗。 |
| 26 | 呼叫不安全的擴充功能。 |
| 27 | 已叫用已被取代的服務。 |
| 28 | 偵測到界限外緩衝區存取。 |
| 29 | RTL_BALANCED_NODE RBTree 專案已損毀。 |
| 37 | 叫用超出範圍的切換跳板專案。 |
| 38 | longjmp 嘗試到無效的目標。 |
| 39 | 無法將導出隱藏的呼叫目標設為有效的呼叫目標。 |
原因
使用參數 1 資料表和傾印檔案，可以縮小此類型許多錯誤檢查的原因。
LIST_ENTRY損毀可能難以追蹤，而且這項錯誤檢查表示已將不一致引入到雙重連結的清單中（偵測到何時將個別清單專案專案新增至清單或從清單中移除）。 不幸的是，在發生損毀時不一定偵測到不一致，因此可能需要一些偵探工作來識別根本原因。
清單專案損毀的常見原因包括：
- 驅動程式已損毀核心同步處理物件，例如KEVENT（例如，當線程仍在等候相同的KEVENT時，將KEVENT初始化為雙重初始化，或允許堆棧型KEVENT在另一個線程使用該KEVENT時超出範圍）。 這種類型的錯誤檢查通常發生在 nt！Ke* 或 nt！Ki* 程式代碼。 當線程完成等候同步處理物件或程式代碼嘗試將同步處理物件置於訊號狀態時，就會發生此情況。 通常，要發出訊號的同步處理物件是已損毀的同步處理物件。 有時候，具有特殊集區的驅動程序驗證器有助於追蹤罪魁禍首（如果損毀的同步處理對象位於已釋放的集區區塊中）。
- 驅動程式已損毀定期 KTIMER。 這種類型的錯誤檢查通常發生在 nt！Ke* 或 nt！Ki* 程式代碼並牽涉到發出定時器訊號，或從定時器數據表插入或移除定時器。 正在操作的定時器可能是損毀的定時器，但可能需要使用 ！timer 檢查定時器數據表（或手動步行定時器清單連結），以識別哪些定時器已損毀。 有時候，具有特殊集區的驅動程序驗證器有助於追蹤罪魁禍首（如果損毀的 KTIMER 位於已釋放的集區區塊中）。
- 驅動程式管理不當的內部LIST_ENTRY樣式連結清單。 典型的範例是在同一個清單專案上呼叫 RemoveEntryList 兩次，而不重新插入兩 個 RemoveEntryList 呼叫之間的清單專案。 其他變化是可能的，例如在相同的清單中重複插入專案。
- 驅動程式釋放了包含LIST_ENTRY的數據結構，而不從其對應的清單中移除數據結構，導致稍後在重複使用舊集區區塊之後檢查清單時偵測到損毀。
- 驅動程式已以並行方式使用LIST_ENTRY樣式清單，而不需要適當的同步處理，因而導致清單的更新已損毀。
在大部分情況下，您可以藉由向前和向後走動連結清單來識別損毀的數據結構（ dl 和 dlb 命令適用於此目的），並比較結果。 如果清單在向前和向後走之間不一致，通常是損毀的位置。 由於連結清單更新作業可以修改鄰近專案的清單連結，因此您應該仔細查看損毀清單專案的鄰近專案，因為它們可能是基礎罪魁禍首。
由於許多系統元件會在內部使用LIST_ENTRY清單，因此使用系統 API 的驅動程式對各種資源管理不善可能會導致系統管理的連結清單損毀。
解決方法
判斷此問題的原因通常需要使用調試程式來收集其他資訊。 應該檢查多個傾印檔案，以查看此停止程式代碼是否有類似的特性，例如停止程式代碼出現時執行的程序代碼。
如需詳細資訊，請參閱使用 Windows 調試程式進行損毀傾印分析 （WinDbg），使用 ！analyze 擴充功能和 ！analyze。
使用事件記錄檔來查看是否有較高層級的事件導致此停止程序代碼。
這些一般疑難解答秘訣可能很有説明。
如果您最近將硬體新增至系統，請嘗試移除或取代它。 或者，請洽詢製造商以查看是否有任何修補程式可供使用。
如果最近新增了新的設備驅動器或系統服務，請嘗試移除或更新它們。 嘗試判斷系統中導致出現新錯誤檢查程式代碼的變更。
請檢查系統登入 事件檢視器 是否有其他錯誤訊息，以協助找出造成錯誤的裝置或驅動程式。 如需詳細資訊，請參閱開啟 事件檢視器。 在與藍色畫面相同的時間範圍中，尋找系統記錄檔中發生的嚴重錯誤。
查看 裝置管理員，以查看是否有任何裝置標示為驚嘆號 （！）。 檢閱驅動程式屬性中顯示的事件記錄檔，以取得任何錯誤驅動程式。 請嘗試更新相關的驅動程式。
執行病毒偵測程式。 病毒可以感染針對 Windows 格式化的所有硬碟類型，而產生的磁碟損毀可能會產生系統錯誤檢查碼。 請確定病毒偵測程式會檢查主要開機記錄是否有感染。
如需其他一般疑難解答資訊，請參閱 分析錯誤檢查藍屏幕數據。