Losowe zamrażanie w środowisku ESXi na kilku serwerach

W ciągu ostatnich kilku tygodni mieliśmy problemy z naszym środowiskiem VDI opartym na ESXi, w wyniku którego obrazy pulpitu Windows 7 losowo zawieszają się w ciągu dnia.

Może się to zdarzyć na dowolnym obrazie VDI Win7 na dowolnym z naszych hostów ESXi i, o ile wiemy, ostatnio nie wprowadzono żadnych zmian w systemie ani oprogramowaniu (hmmm ...).

Jeśli spojrzę na konsolę zamrożonego systemu, nie zawsze jest ona całkowicie zamrożona. Czasami mogę wysłać sygnał ctrl + alt + del i zrobi coś, ale nie zawsze. Co więcej, użycie procesora dla maszyny wirtualnej w ESXi jest w rzeczywistości dość niskie (zużycie <5%), więc nie wydaje się, że jest to ciągły proces przeciągający go w dół.

Próbując zdiagnozować problem, zrobiłem migawkę kilku maszyn wirtualnych podczas zamrożenia i przekonwertowałem ich pliki vms na pliki dmp. Następnie załadowałem je do windbg i otrzymałem następujące informacje:

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

NMI_HARDWARE_FAILURE (80)
This is typically due to a hardware malfunction.  The hardware supplier should
be called.
Arguments:
Arg1: 00000000004f4454
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------


DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x80

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80001886113 to fffff80001e0d0ba

STACK_TEXT:  
fffff800`0169aad0 fffff800`01886113 : 00000000`00000000 fffff800`01e293c0 00000000`00000000 00000000`00000000 : hal!HalpRtcClockInterrupt+0x2a
fffff800`0169ab00 fffff880`033cd9c2 : fffff800`01892709 00000000`00369e99 fffffa80`0249d638 00000000`00000000 : nt!KiInterruptDispatchNoLock+0x163
fffff800`0169ac98 fffff800`01892709 : 00000000`00369e99 fffffa80`0249d638 00000000`00000000 00000000`00000000 : intelppm!C1Halt+0x2
fffff800`0169aca0 fffff800`0188189c : fffff800`01a04e80 fffff800`00000000 00000000`00000000 fffff880`0105e800 : nt!PoIdle+0x52a
fffff800`0169ad80 00000000`00000000 : fffff800`0169b000 fffff800`01695000 fffff800`0169ad40 00000000`00000000 : nt!KiIdleLoop+0x2c


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiInterruptDispatchNoLock+163
fffff800`01886113 f685f3000000ff  test    byte ptr [rbp+0F3h],0FFh

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!KiInterruptDispatchNoLock+163

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  521ea035

FAILURE_BUCKET_ID:  X64_0x80_nt!KiInterruptDispatchNoLock+163

BUCKET_ID:  X64_0x80_nt!KiInterruptDispatchNoLock+163

Followup: MachineOwner
---------

i to...

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

NMI_HARDWARE_FAILURE (80)
This is typically due to a hardware malfunction.  The hardware supplier should
be called.
Arguments:
Arg1: 00000000004f4454
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------


DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x80

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80001892709 to fffff880033cd9c2

STACK_TEXT:  
fffff880`009fbc98 fffff800`01892709 : 00000000`00369e99 fffffa80`0249b598 fffff880`009f2f40 00000000`00000001 : intelppm!C1Halt+0x2
fffff880`009fbca0 fffff800`0188189c : fffff880`009e8180 fffff880`00000000 00000000`00000000 fffff800`01941430 : nt!PoIdle+0x52a
fffff880`009fbd80 00000000`00000000 : fffff880`009fc000 fffff880`009f6000 fffff880`009fbd40 00000000`00000000 : nt!KiIdleLoop+0x2c


STACK_COMMAND:  kb

FOLLOWUP_IP: 
intelppm!C1Halt+2
fffff880`033cd9c2 c3              ret

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  intelppm!C1Halt+2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: intelppm

IMAGE_NAME:  intelppm.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc0fd

FAILURE_BUCKET_ID:  X64_0x80_intelppm!C1Halt+2

BUCKET_ID:  X64_0x80_intelppm!C1Halt+2

Followup: MachineOwner
---------

Chociaż sugeruje to problem ze sprzętem (o ile wiem), trudno mi w to uwierzyć, ponieważ mamy kilka różnych farm z różnym sprzętem i występuje na wszystkich z nich.

Czy jest coś, co mogę zrobić, aby rozwiązać ten problem? Moje doświadczenie z windbg jest bardzo podstawowe.

Patrzyłem na problem z przypadkowym zawieszaniem się serwerów 2008, uzyskałem plik dmp z plików vmss i zobaczyłem dokładnie to samo wyjście. Wgłębiłem się do pliku dmp i prześledziłem końcowe lokalizacje pamięci do jakiegoś interfejsu API na poziomie systemu, wskazując, że przerwanie dotyczące procesorów zostało odebrane, ale nie zostało zakończone.

Pewnie oświadczyłem moim szefom, że oznacza to błąd sprzętowy, pomimo zaangażowania kilku hostów w dwóch centrach danych. W końcu, gdy hiperwizor jest zaangażowany w oderwanie się od samego sprzętu, może nastąpić przerwanie w miejscu, które nie pochodziło od samego sprzętu.

Potem miałem okropną myśl i odpaliłem działającego vm na stacji roboczej, zawiesiłem go, dostałem plik dmp i uruchomiłem go w windbg. Zgadnij co - dokładnie taki sam wynik.

Wierzę, że pokazane NMI jest wynikiem samego procesu zawieszenia. Możesz wyciągnąć inne przydatne rzeczy z windbg - przydział pamięci itp. - ale nie marnuj czasu na próby znalezienia problemu z NMI.