Windows Server 2012 R2 (Hyper-V VM) - 随机 BSOD

Windows Server 2012 R2 (Hyper-V VM) - 随机 BSOD


我遇到了一个问题。我的虚拟机 (Hyper-V) - Windows Server 2012 R2 经常自行重启 (BSOD: CRITICAL_STRUCTURE_CORRUPTION (109))。上次是周末 11 次。我有新硬件,2 台 Supermicro 服务器。我在两台服务器上都安装了 Windows Server 2012 R2 和 Hyper-V 角色(+ 安装了 Supermicro 网站上的驱动程序)。作为客户系统 (VM),我在每个 Hyper-V 主机上都有 2 个 Windows Server 2012 和 1 个 Windows Server 2012 R2。就像我写的,问题是 W2012R2 VM 会随机自行重启。但只有 W2012R2 VM。带有 W2012 的 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-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, 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

有时,主机服务器上会记录此事件。但并非每次虚拟机发生故障时都会发生:

Hyper-V-Worker 18590

VmErrorCode0 0x109
VmErrorCode1 0xbb8d251d
VmErrorCode2 0xe0d2304
VmErrorCode3 0x1a0
VmErrorCode4 0x7

你能帮我解决这个问题吗?

答案1

对我有用的解决方案:

  • 在高级电源管理配置下设置以下自定义电源设置:

高级电源管理配置 CPU C 状态控制

注意:突出显示的行是重要的变化,但请确保其他设置也与图片中相同

我做的其他事情可能会有所帮助(我在做上述事情之前就做过这些事情,所以我不确定是否相关):

资料来源:

答案2

环境 ”包 C 状态限制 - C0/C1 状态“ 原因蓝屏死机(以及设置电源技术 - [禁用])。因为我无法设置“C0/C1 状态”,所以我选择了“C2 状态”,这个状态工作正常。简而言之:您选择的 Package C 状态限制越高,CPU 的能效就越高(通过停止时钟、降低电压……)。

在这种情况下,最佳性能设置应该是:

高级电源管理配置:

电源技术 - [自定义]
能源性能调节 - [禁用]
能源性能偏差设置。 - [性能]
节能涡轮 - [禁用]

高级电源管理配置

CPU P 状态控制:

EIST(P 状态) - [启用]
Turbo 模式 - [启用]
P 状态协调 - [HW_ALL]

CPU P 状态控制

CPU C 状态控制:

包 C 状态限制 - [C2 状态]
CPU C3 报告 - [禁用]
CPU C6 报告 - [禁用]
增强型暂停状态 (C1E) - [禁用]

CPU C 状态控制


我发现,这种类型的问题过去出现过几次,并且可以通过更新 ROM 或主机微码更新来修复,如下所示:KB2970215。但我还没发现任何有效的更新。

来源:
http://www.supermicro.com/support/faqs/faq.cfm?faq=21555 http://www.supermicro.com/support/faqs/faq.cfm?faq=21499

答案3

我们也遇到过同样的错误。@KeyszerS 的回答是一个很好的提示。

错误似乎与 X10 主板的电源管理有关(至少对于超微而言)。我做了几次有和没有电源管理的测试 - 有时 BSOD 出现得更频繁,有时几乎已经过去了。

几天以来,我找到了一个可靠的解决方案(至少对我们来说)。我们在一台受影响的服务器上评估了 20 台虚拟机的稳定性 - 不再崩溃。

那么,如何获取它:最简单的方法是将 BIOS 设置恢复为默认设置,然后禁用“节能涡轮”

更新:

大约 7 天内没有任何问题 - 工作负载似乎相当稳定。这是 BIOS 中电源管理设置的屏幕截图 - 它似乎与“节能 Turbo”有关。

在此处输入图片描述

相关内容