Windows Server 2012 R2（Hyper-V虚拟机） – 随机BSOD
我有个问题。 我的虚拟机（Hyper-V） – Windows Server 2012 R2经常重启（BSOD：CRITICAL_STRUCTURE_CORRUPTION（109））。 上次是周末的11倍。 我有新的硬件，2倍超微服务器。 我在两台服务器上安装了Windows Server 2012 R2和Hyper-Vangular色（安装了来自Supermicro网站的+驱动程序）。 作为访客系统（VM），每个Hyper-V主机上都有两个Windows Server 2012和一个Windows Server 2012 R2。 就像我写的，问题是，W2012R2虚拟机随机重启。 但是只有W2012R2的虚拟机。 W2012的虚拟机是可以的。 所有的系统都很干净，没有安装应用程序，也没有工作量。
重新启动后，这些事件logging在虚拟机上：
核心力量41
EventData: BugcheckCode 265 BugcheckParameter1 0xa3a01f59e148b50a BugcheckParameter2 0xb3b72be033c8b301 BugcheckParameter3 0x1a0 BugcheckParameter4 0x7 SleepInProgress 0 PowerButtonTimestamp 0 BootAppStatus 0 BugCheck 1001
EventData param1 0x00000109 (0xa3a01f59e148b50a, 0xb3b72be033c8b301, 0x00000000000001a0, 0x0000000000000007) param2 C:\Windows\MEMORY.DMP param3 021516-3093-01
WinDbg输出：
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, eg 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
debugging细节：
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
有时候，主机服务器上会logging此事件。 但不是每次虚拟机失败时：
Hyper-V-Worker 18590
VmErrorCode0 0x109 VmErrorCode1 0xbb8d251d VmErrorCode2 0xe0d2304 VmErrorCode3 0x1a0 VmErrorCode4 0x7
你能帮我解决这个问题吗？
解决scheme，为我工作：
- 在高级电源pipe理configuration下设置以下自定义电源设置：
注：突出显示的行是重要的更改，但确保其他设置也与图片中的相同
其他事情，我做了，可能有帮助（我做了这些之前做了上述，所以我不知道这是否有关）。
-
从微软安装的KB2970215 – 修复了特定CPU芯片组上的“随机蓝屏”
-
从Supermicro网站安装最新的英特尔芯片组驱动程序（对于我来说，这是ftp://ftp.supermicro.nl/driver/Intel_INF/C612_Series_Chipset/Chipset_v10.1.2.8.zip – find一个最适合你的）
- 安装最新的networking驱动程序（例如： ftp : //ftp.supermicro.nl/driver/LAN/Intel/PRO_v20.3.zip ）
- 安装了RSTE Utility＆Driver（例如： ftp ://ftp.supermicro.nl/driver/SATA/Intel_PCH_RAID_Romley_RSTE/Management/4.3.0.1219/IATA_CD.exe）
资料来源：
设置“ 封装C状态限制 – C0 / C1状态 ”导致BSOD （以及设置电源技术 – [禁用] ）。 因为不能设定“C0 / C1状态”，所以select了没有问题的“C2状态”。 简而言之，您select的Package C State Limit越高，CPU的能效越高（通过停止时钟，降低电压…）。
在这种情况下最好的性能设置应该是：
高级电源pipe理configuration：
电源技术 – [自定义]
能源性能调整 – [禁用]
能源绩效偏离设置。 – [性能]
节能涡轮 – [禁用]
CPU P状态控制：
EIST（P-States） – [Enable]
Turbo模式 – [启用]
P状态协调 – [HW_ALL]
CPU C状态控制：
包C状态限制 – [C2状态]
CPU C3报告 – [禁用]
CPU C6报告 – [禁用]
增强暂停状态（C1E） – [禁用]
我发现，这种types的问题在过去几次出现，并通过更新ROM或主机微代码更新来解决： KB2970215 。 但我还没有find任何工作更新。
来源：
http://www.supermicro.com/support/faqs/faq.cfm?faq=21555 http://www.supermicro.com/support/faqs/faq.cfm?faq=21499
我们也有同样的错误。 @KeyszerS的答案是一个非常好的提示。
看来这些错误与X10电路板的电源pipe理有关（至less对于超微电路来说）。 我做了几个testing，没有任何电源pipe理 – 有时蓝屏发生更频繁，有时甚至几乎通过。
自从几天以来，我的解决scheme（至less对我们来说）是可靠的。 我们已经在一台受影响的服务器上评估了20台虚拟机的稳定性 – 不再有崩溃。
所以，如何得到它：最简单的方法是恢复BIOS设置为默认值，只是禁用“节能涡轮” 。
更新：
大约7天没有问题 – 工作量似乎相当稳定。 以下是BIOS中电源pipe理设置的屏幕截图 – 这似乎与“节能Turbo”有关。
