Windows Server 2012 R2（Hyper-V 虛擬機）- 隨機藍屏
我有個問題。我的虛擬機 (Hyper-V) - Windows Server 2012 R2 經常自行重啟（BSOD：CRITICAL_STRUCTURE_CORRUPTION (109)）。上次是周末的 11 倍。我有新的硬體，2x Supermicro 伺服器。我在兩台伺服器上都安裝了 Windows Server 2012 R2 和 Hyper-V 角色（安裝了來自 Supermicro 網站的驅動程序）。作為來賓系統 (VM)，我在每台 Hyper-V 主機上安裝了 2 個 Windows Server 2012 和 1 個 Windows Server 2012 R2。就像我寫的那樣，問題是 W2012R2 虛擬機隨機重啟。但只有 W2012R2 虛擬機。帶有 W2012 的 VM 可以。所有系統都很乾淨，沒有安裝任何應用程序，也沒有工作負載。
重新啟動後，VM 上會記錄以下事件：
核心電源 41
EventData: BugcheckCode 265 BugcheckParameter1 0xa3a01f59e148b50a BugcheckParameter2 0xb3b72be033c8b301 BugcheckParameter3 0x1a0 BugcheckParameter4 0x7 SleepInProgress 0 PowerButtonTimestamp 0 BootAppStatus 0錯誤檢查 1001
EventData param1 0x00000109 (0xa3a01f59e148b50a, 0xb3b72be033c8b301, 0x00000000000001a0, 0x0000000000000007) param2 C:\Windows\MEMORY.DMP param3 021516-3093-01WinDbg 輸出：
CRITICAL_STRUCTURE_CORRUPTION (109) This bugcheck is generated when the kernel detects that critical kernel code or data have been corrupted. There are generally three causes for a corruption: 1) A driver has inadvertently or deliberately modified critical kernel code or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx 2) A developer attempted to set a normal kernel breakpoint using a kernel debugger that was not attached when the system was booted. Normal breakpoints, "bp", can only be set if the debugger is attached at boot time. Hardware breakpoints, "ba", can be set at any time. 3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data. Arguments: Arg1: a3a01f5a69a8b6bb, Reserved Arg2: b3b72be0bc28b4a2, Reserved Arg3: 00000000000001a0, Failure type dependent information Arg4: 0000000000000007, Type of corrupted region, can be 0 : A generic data region 1 : Modification of a function or .pdata 2 : A processor IDT 3 : A processor GDT 4 : Type 1 process list corruption 5 : Type 2 process list corruption 6 : Debug routine modification 7 : Critical MSR modification調試細節：
PG_MISMATCH: 40000 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT_SERVER BUGCHECK_STR: 0x109 PROCESS_NAME: System CURRENT_IRQL: 2 ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre STACK_TEXT: ffffd001\`1bb7e088 00000000\`00000000 : 00000000\`00000109 a3a01f5a\`69a8b6bb b3b72be0\`bc28b4a2 00000000\`000001a0 : nt!KeBugCheckEx STACK_COMMAND: kb SYMBOL_NAME: ANALYSIS_INCONCLUSIVE FOLLOWUP_NAME: MachineOwner MODULE_NAME: Unknown_Module IMAGE_NAME: Unknown_Image DEBUG_FLR_IMAGE_TIMESTAMP: 0 IMAGE_VERSION: BUCKET_ID: BAD_STACK FAILURE_BUCKET_ID: BAD_STACK ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:bad_stack FAILURE_ID_HASH: {75814664-faf6-4b70-bbc7-dc592132ecdd} Followup: MachineOwner有時，主機伺服器上會記錄此事件。但並非每次 VM 失敗時：
Hyper-V-Worker 18590
VmErrorCode0 0x109 VmErrorCode1 0xbb8d251d VmErrorCode2 0xe0d2304 VmErrorCode3 0x1a0 VmErrorCode4 0x7你能幫我解決這個問題嗎？
設置“包 C 狀態限制 - C0/C1 狀態”會導致BSOD（以及設置電源技術 -$$ Disable $$）。因為我無法設置“C0/C1 狀態”，所以我選擇了“C2 狀態”，它可以正常工作。簡而言之：您選擇的包 C 狀態限制越高，CPU 的能效就越高（通過停止時鐘，降低電壓……）。
在這種情況下，最佳性能設置應該是：
高級電源管理配置：
電源技術 -
$$ Custom $$
能源性能調整 -$$ Disable $$
能源績效偏差設置。-$$ Performance $$
節能渦輪 -$$ Disable $$
CPU P 狀態控制：
EIST（P-狀態）-
$$ Enable $$
渦輪模式 -$$ Enable $$
P-狀態協調 -$$ HW_ALL $$
CPU C 狀態控制：
包 C 狀態限制 -
$$ C2 state $$
CPU C3 報告 -$$ Disable $$
CPU C6 報告 -$$ Disable $$
增強停止狀態 (C1E) -$$ Disable $$
我發現，這種類型的問題在過去出現過幾次，並通過更新 ROM 或通過主機微碼更新修復，如下所示：KB2970215。但我還沒有找到任何有效的更新。
來源：
http ://www.supermicro.com/support/faqs/faq.cfm?faq=21555 http://www.supermicro.com/support/faqs/faq.cfm?faq=21499
對我有用的解決方案：
- 在高級電源管理配置下設置以下自定義電源設置：
注意：突出顯示的行是重要的更改，但請確保其他設置也與圖片中的相同
我做的其他事情，可能有幫助（我在做上述事情之前做了這些，所以我不確定它是否相關）：
- 從 Microsoft安裝KB2970215 - 這修復了特定 CPU 晶片組上的“隨機藍屏”
- 從 Supermicro 的網站安裝英特爾晶片組的最新驅動程序（對我來說，它是<ftp://ftp.supermicro.nl/driver/Intel_INF/C612_Series_Chipset/Chipset_v10.1.2.8.zip> - 找到最適合您的驅動程序）
- 安裝了最新的網路驅動程序（例如： ftp: //ftp.supermicro.nl/driver/LAN/Intel/PRO_v20.3.zip）
- 安裝了 RSTE 實用程序和驅動程序（例如：ftp ://ftp.supermicro.nl/driver/SATA/Intel_PCH_RAID_Romley_RSTE/Management/4.3.0.1219/IATA_CD.exe ）
資料來源：
