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

前端之家收集整理的这篇文章主要介绍了Windows Server 2012 R2(Hyper-V VM) – 随机BSOD前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有个问题.我的VM(Hyper-V) – Windows Server 2012 R2经常重启(BSOD:CRITICAL_STRUCTURE_CORRUPTION(109)).上次是周末的11倍.我有新的HW,2x Supermicro服务器.我在两台服务器上安装了Windows Server 2012 R2和Hyper-V角色(安装了Supermicro网站的驱动程序).作为访客系统(VM),我在每个Hyper-V主机上都有2个Windows Server 2012和1个Windows Server 2012 R2.就像我写的那样,问题是,W2012R2 VM随机重启.但只有W2012R2虚拟机.使用W2012的虚拟机可以.所有系统都很干净,没有安装任何应用程序,也没有工作负载.

重新启动后,VM上会记录这些事件:

核心力量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,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

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

解决方案对我有用:

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


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

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

>从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 Utility&司机(例如:ftp://ftp.supermicro.nl/driver/SATA/Intel_PCH_RAID_Romley_RSTE/Management/4.3.0.1219/IATA_CD.exe)

资料来源:

> https://social.technet.microsoft.com/Forums/en-US/f8ba6d82-b79d-4b17-b13b-269841a9f236/vm-going-down-bugcheck-0x109?forum=winserverhyperv> Supermicro合作伙伴支持

原文链接:https://www.f2er.com/windows/366795.html

猜你在找的Windows相关文章