Windows Server 2012 R2 (VMs do Hyper-V) - BSOD aleatório

3


Eu tenho um problema. Minhas VMs (Hyper-V) - O Windows Server 2012 R2 é reiniciado com bastante frequência (BSOD: CRITICAL_STRUCTURE_CORRUPTION (109)). A última vez foi 11x no final de semana. Eu tenho o novo servidor HW, 2x Supermicro. Eu instalei o Windows Server 2012 R2 e a função Hyper-V em ambos os servidores (+ drivers do site da Supermicro estão instalados). Como sistemas convidados (VMs), tenho 2x Windows Server 2012 e 1x Windows Server 2012 R2 em cada host Hyper-V. Como escrevi, o problema é que as VMs W2012R2 reiniciam aleatoriamente. Mas apenas as VMs W2012R2. VMs com W2012 estão OK. Todos os sistemas estão limpos, não há aplicativos instalados e não há carga de trabalho.

Após a reinicialização, há esses eventos registrados nas VMs:

Kernel-Power 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

Saída do 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  

Detalhes da depuração:

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

Às vezes, há esse evento registrado no servidor host. Mas nem sempre toda vez que a VM falha:

Hyper-V-Worker 18590

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

Você poderia me ajudar a resolver esse problema, por favor?

    
por devlin 17.02.2016 / 15:48

3 respostas

1

Configuração " Limite de estado do pacote C - Estado C0 / C1 " causa BSODs (bem como define Tecnologia de energia - [Desativar] ) . Porque eu não posso definir "Estado C0 / C1", eu escolhi "estado C2", que está funcionando sem problemas. Resumindo: quanto maior o limite de estado do pacote C que você escolher, mais CPU eficiente será (parando os relógios, reduzindo a tensão ...).

As melhores configurações de desempenho, neste caso, devem ser:

Configuração avançada de gerenciamento de energia:

Tecnologia de potência - [Custom]
Ajuste do desempenho energético - [Desativar]
Configuração de BIAS de desempenho energético. - [Performance]
Turbo eficiente em termos de energia - [Desativar]

ControledoestadodaCPUP:

EIST(P-States)-[Ativar]
ModoTurbo-[Ativar]
CoordenaçãodoestadoP-[HW_ALL]

ControledeestadodaCPUC:

LimitedeestadodopacoteC-[estadoC2]
CPUC3Report-[Desabilitar]
CPUC6Report-[Desabilitar]
Estadoavançadodeparada(C1E)-[Desabilitar]

DescobriqueessetipodeproblemaapareciapoucasvezesnopassadoefoicorrigidopelaatualizaçãodaROMoupelaatualizaçãodoHostMicrocodedestaforma: KB2970215 . Mas ainda não encontrei nenhuma atualização de trabalho.

fontes: link link

    
por 03.03.2016 / 10:24
1

Solução que funcionou para mim:

  • Defina as seguintes configurações personalizadas de energia em Configuração avançada de gerenciamento de energia:

Nota:Aslinhasdestacadassãoasalteraçõesimportantes,mascertifique-sedequeasoutrasconfiguraçõestambémsãoasmesmasdasimagens

Outrascoisasquefiz,quepodemterajudado(eufizissoantesdefazeroacima,entãonãotenhocertezaseérelevanteounão):

Fontes:

  • link
  • Suporte a parceiros da Supermicro
por 22.02.2016 / 12:20
0

Também tivemos os mesmos erros. A resposta do @KeyszerS é uma boa dica.

Parece que os erros estão relacionados ao gerenciamento de energia das placas X10 (pelo menos para o supermicro). Fiz vários testes com e sem qualquer gerenciamento de energia - às vezes, as BSODs aconteciam com mais frequência e, às vezes, quase já passavam.

Desde alguns dias eu tenho uma solução que funciona (pelo menos para nós) confiável. Estamos avaliando a estabilidade com 20 VMs em um servidor afetado - não há mais falhas.

Então, como obtê-lo: A maneira mais fácil é reverter as configurações do BIOS para os padrões e apenas desativar o "turbo energeticamente eficiente" .

Atualização:

Sem problemas durante cerca de 7 dias - a carga de trabalho parece ser bastante estável. Aqui está uma captura de tela de configurações de gerenciamento de energia no BIOS - parece estar relacionado ao "Energy Efficient Turbo".

    
por 27.02.2016 / 16:09