I have a problem. My VMs (Hyper-V) - Windows Server 2012 R2 restart themselves quite often (BSOD: CRITICAL_STRUCTURE_CORRUPTION (109)). Last time it was 11x over weekend. I have new HW, 2x Supermicro server. I installed Windows Server 2012 R2 and Hyper‑V role on both servers (+ drivers from Supermicro website are installed). As a guest systems (VMs) I have 2x Windows Server 2012 and 1x Windows Server 2012 R2 on each Hyper-V host. Like I wrote, problem is, that W2012R2 VMs randomly restart themselves. But only W2012R2 VMs. VMs with W2012 are OK. All systems are clean, no applications are installed and there is no workload.

After reboot, there are these events logged on VMs:

Kernel-Power 41

BugcheckCode 265 
BugcheckParameter1 0xa3a01f59e148b50a 
BugcheckParameter2 0xb3b72be033c8b301 
BugcheckParameter3 0x1a0 
BugcheckParameter4 0x7 
SleepInProgress 0 
PowerButtonTimestamp 0 
BootAppStatus 0 

BugCheck 1001

param1 0x00000109 (0xa3a01f59e148b50a, 0xb3b72be033c8b301, 0x00000000000001a0, 0x0000000000000007) 
param2 C:\Windows\MEMORY.DMP 
param3 021516-3093-01

WinDbg output:

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.
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 Details:

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
ffffd001\`1bb7e088 00000000\`00000000 : 00000000\`00000109 a3a01f5a\`69a8b6bb b3b72be0\`bc28b4a2 00000000\`000001a0 : nt!KeBugCheckEx
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME:  Unknown_Image
FAILURE_ID_HASH:  {75814664-faf6-4b70-bbc7-dc592132ecdd}
Followup: MachineOwner

Sometimes, there is this event logged on the host server. But not every time when VM fails:

Hyper-V-Worker 18590

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

Could you help me solve this problem please?

  • 1
    Defective hardware, crappy driver. One of them. If that is a brand machine - why do you ask here, get it fixed. We can not fix broken hardware. – TomTom Feb 17 '16 at 14:57
  • I don't think it's broken hardware, because I have 2 brand new servers and both suffer in the same way. I don't think, that both servers are broken. And host systems (OSs) are running without problems. – devlin Feb 17 '16 at 15:01
  • Then you have a driver problem. Simple like that. – TomTom Feb 17 '16 at 15:22
  • What supoermicro drivers are you using? I would suggest using the drivers for the hardware exposed to the virtual machine by the host (which means, letting windows update handle it). Your virtual boxes should have no idea what physical hardware you are using as it is all abstracted. – Jonathan Piccirilli Feb 17 '16 at 15:35
  • TomTom: No, it's not simple like that. It can be also UEFI settings, something with virtualization layer etc.. – devlin Feb 18 '16 at 9:49

Solution that worked for me:

  • Set the following Custom Power Settings under Advanced Power Management Configuration:

Advanced Power Management Configuration CPU C State Control

Note: The highlighted lines are the important changes, but make sure the other settings are also the same as in the pictures

Other things that I did, which may have helped (I did these before doing the above, so I'm not sure if it is relevant or not):


  • we're seeing this issue on one of our servers as well - tried several power settings already over the last two days (according to ms forums). issue just persists – Daniel Nachtrub Feb 23 '16 at 10:28
  • Thanks for the feedback - it's why I've put in "Potential" solution :) I'm trying this out myself since I have the same issue. Do you have Supermicro too? – KeyszerS Feb 23 '16 at 10:52
  • yep - we're seeing it on a X10SRW-F with an E5 2660v3. our supplier saw propably the same issue on another X10 board. we've two other X10SRW-F with Xeon E5 1650v3 running without any issues. – Daniel Nachtrub Feb 23 '16 at 11:13
  • Thx - I'm seeing this on a SYS-1028U-TR4+, which has the X10DRU-i+ motherboard. – KeyszerS Feb 23 '16 at 11:42
  • 1
    I tested mentioned hotfix, but it didn't work. When I disable "Power Technology", VMs are failing. What seems to be a problematic option (when setting "Power Technology - Custom") is "Package C State Limit - C0/C1 State". When I leave that option on "Custom default" - "C6(Retention) state", it works. At least for now. I need more time to be sure. "Power Technology - Energy Efficient" works for me too, but nobody wants that. – devlin Feb 23 '16 at 12:52

Setting "Package C State Limit - C0/C1 State" causes BSODs (as well as setting Power Technology - [Disable]). Because I can't set "C0/C1 State", I choosed "C2 state" which is working without problems. In a nutshell: The higher Package C State Limit you chose, the more energy efficient CPU would be (by stopping clocks, reducing voltage...).

The best performance settings in this case should be:

Advanced Power Management Configuration:

Power Technology - [Custom]
Energy Performance Tuning - [Disable]
Energy Performance BIAS setting. - [Performance]
Energy Efficient Turbo - [Disable]

Advanced Power Management Configuration

CPU P State Control:

EIST(P-States) - [Enable]
Turbo Mode - [Enable]
P-state Coordination - [HW_ALL]

CPU P State Control

CPU C State Control:

Package C State Limit - [C2 state]
CPU C3 Report - [Disable]
CPU C6 Report - [Disable]
Enhanced Halt State (C1E) - [Disable]

CPU C State Control

I found, that this type of problem appeared few times in the past and was fixed by updating ROM or by Host Microcode update like this: KB2970215. But I haven't found any working update yet.

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


We've had the same errors also. The answer from @KeyszerS is a really good hint.

It seems that the errors are related to the power management of X10 boards (at least for supermicro). I did several tests with and without any power management - sometimes the BSODs occured more often and sometimes they've been nearly passed.

Since a few days i've a solution that works (at least for us) reliable. We've evaluating the stability with 20 VMs on one affected server - no crashes anymore.

So, how to get it: Easiest way is to revert BIOS settings to defaults and just disable "energy efficient turbo".


No issues at all for around 7 days - workload seems to be quite stable. Here's a screenshot of power management settings in BIOS - it seems to be related to "Energy Efficient Turbo".

enter image description here

protected by Community Oct 4 '16 at 8:33

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.