111945
Goto Top

Hyper-V VM Stützt mit Bluescreen ab und rebootet

Hallo,

ich habe einen Hyper-V Server (Windows Server 2012R2 DataCenter) auf dem 10 VMs laufen. Eine VM stürzt in regelmäßigen, unregelmäßigen abständen ab (mal ist 1x die Woche, mal 3 mal am Tag)

Der Eventlog vom Host gibt folgende Fehlermeldung:

Von "VM001" wurde ein schwerwiegender Fehler erkannt. Vom Gastbetriebssystem wurde ein Fehler mit den folgenden Fehlercodes gemeldet: Fehlercode0: 0xA, Fehlercode1: 0x238, Fehlercode2: 0x2, Fehlercode3: 0x1, Fehlercode4: 0xD8E44D7A.  Falls das Problem weiterhin besteht, wenden Sie sich an den Produktsupport für das Gastbetriebssystem. (ID des virtuellen Computers: BD29320F-0DD7-4C10-B48B-DC326923FAAE)  

In der VM selbst gibt es nur einen Dump, dort ist mir folgende Zeile aufgefallen (Siehe Anhang)


Folgendes wurde zur Lösungsfindung getan.
- Umzug der VM auf anderen Host (ohne Erfolg)
- Neuerstellung der VM (ohne Erfolg)


Habt ihr Ideen? Erfahrungen? Vielleicht hat(te) jemand das selbe Problem


Danke!
dump_trust

Content-Key: 304737

Url: https://administrator.de/contentid/304737

Printed on: April 19, 2024 at 21:04 o'clock

Mitglied: 129413
129413 May 18, 2016 updated at 06:54:54 (UTC)
Goto Top
Lade das Dump-File hier hoch und poste dann das detaillierte Ergebnis.

  • Was läuft in der VM an Software/OS ?
  • Ist zufällig ein Virenscanner in der VM aktiv?
  • Irgendwelche zusätzlichen Treiber in der VM installiert?
  • Resourcenzuordnung für VM ist ausreichend? Speicher läuft nicht voll?

Fragen über Fragen ...

Gruß skybird
Mitglied: 111945
111945 May 18, 2016 at 07:18:33 (UTC)
Goto Top
Die Fragen haben mir aber schon weitergeholfen. Bzw die Vermutungen bestätigt.

Zur Vollständigkeit:

-An Software läuft neben dem OS noch SwyxWare 2015R3
-Virenscanner etc laufen dort nicht
- Treiber sind keine installiert
- Resourcenauslastung unter 5 %

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 9600.18146.amd64fre.winblue_ltsb.151121-0600
Machine Name:
Kernel base = 0xfffff800`86e75000 PsLoadedModuleList = 0xfffff800`87149630
Debug session time: Thu Mar 31 08:44:54.791 2016 (UTC - 4:00)
System Uptime: 0 days 0:25:12.784
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffe00100000238, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80086ea9ace, address which referenced memory

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

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

WRITE_ADDRESS: fffff80087137020: Unable to get special pool info
fffff80087137020: Unable to get special pool info
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
 ffffe00100000238 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!KxWaitForLockOwnerShip+12
fffff800`86ea9ace 48890a          mov     qword ptr [rdx],rcx

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT_SERVER

BUGCHECK_STR:  AV

PROCESS_NAME:  LinkMgr.exe

TRAP_FRAME:  ffffd001762f2470 -- (.trap 0xffffd001762f2470)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=ffffd001762f2650
rdx=ffffe00100000238 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80086ea9ace rsp=ffffd001762f2600 rbp=0000000000000000
 r8=ffffd001762f2650  r9=ffffe001c2f1b360 r10=0000000000000000
r11=ffffd001762f26f8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
nt!KxWaitForLockOwnerShip+0x12:
fffff800`86ea9ace 48890a          mov     qword ptr [rdx],rcx ds:ffffe001`00000238=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80086fcf3e9 to fffff80086fc38a0

STACK_TEXT:  
ffffd001`762f2328 fffff800`86fcf3e9 : 00000000`0000000a ffffe001`00000238 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
ffffd001`762f2330 fffff800`86fcdc3a : 00000000`00000001 ffffe001`c3003820 ffffe001`c1de7000 fffff800`00000000 : nt!KiBugCheckDispatch+0x69
ffffd001`762f2470 fffff800`86ea9ace : 00000000`00000000 00000000`00000000 00000000`0000002f fffff800`86e0aff2 : nt!KiPageFault+0x23a
ffffd001`762f2600 fffff801`c7ebdae9 : ffffe001`c3003820 ffffe001`c0906500 00000000`00000004 00000000`00000000 : nt!KxWaitForLockOwnerShip+0x12
ffffd001`762f2630 fffff801`c6d64db1 : ffffd872`09ede7d8 ffffd001`762f2800 ffffd001`762f2a60 ffffe001`c08e8b28 : pacer!PcQoSPQueryTrafficClass+0x79
ffffd001`762f2700 fffff801`c74c7f87 : 00000000`00000000 ffffe001`c08e8b28 00000000`00000002 ffffd001`762f2a60 : NETIO!NetioQueryNetBufferListTrafficClass+0x51
ffffd001`762f2760 fffff801`c74af7a4 : 00000000`00000000 00000000`00000804 fffff801`c7645180 ffffe001`c1fc82d0 : tcpip!IppSendDatagramsCommon+0x437
ffffd001`762f2940 fffff801`c74aff3a : ffffe001`c033c110 00000000`00000000 ffffe001`c36eb844 fffff801`c7645180 : tcpip!UdpSendMessagesOnPathCreation+0x484
ffffd001`762f2d90 fffff801`c74b05b4 : ffffd001`791a6180 ffffe001`c328ced8 00000000`00000000 fffff800`86f079f9 : tcpip!UdpSendMessages+0x24a
ffffd001`762f31d0 fffff800`86f2ef63 : 00000000`0000e172 c6d44940`dddc5156 00000000`40720088 00000000`00000000 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
ffffd001`762f3200 fffff801`c74b187c : fffff801`c74b05a0 ffffd001`762f3320 00000000`00000000 00000000`00000002 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd001`762f32f0 fffff801`c7e70676 : ffffe001`c36eb7e0 ffffd001`762f3b80 ffffe001`c36eb7e0 ffffe001`c36eb7e0 : tcpip!UdpTlProviderSendMessages+0x6c
ffffd001`762f3370 fffff801`c7e58580 : 00000000`00017a11 00000000`00000001 ffffd001`762f35b9 00000000`00000001 : afd!AfdFastDatagramSend+0x536
ffffd001`762f3540 fffff800`8731485c : ffffe001`c0a16bf0 00000000`00000000 ffffd001`762f3a01 00000000`068ce9b0 : afd!AfdFastIoDeviceControl+0x1570
ffffd001`762f3890 fffff800`872d55ba : 00000000`00000000 00000000`00000a98 00000000`00000001 00000000`00000000 : nt!IopXxxControlFile+0x62c
ffffd001`762f3a20 fffff800`86fcf0b3 : ffffe001`c2ce6880 00000000`068ce978 ffffd001`762f3aa8 00000000`0865f7f4 : nt!NtDeviceIoControlFile+0x56
ffffd001`762f3a90 00000000`77472352 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`068ce958 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77472352


STACK_COMMAND:  kb

FOLLOWUP_IP: 
pacer!PcQoSPQueryTrafficClass+79
fffff801`c7ebdae9 8b4608          mov     eax,dword ptr [rsi+8]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  pacer!PcQoSPQueryTrafficClass+79

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: pacer

IMAGE_NAME:  pacer.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  5215f7a6

FAILURE_BUCKET_ID:  X64_AV_pacer!PcQoSPQueryTrafficClass+79

BUCKET_ID:  X64_AV_pacer!PcQoSPQueryTrafficClass+79

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


Danke
Mitglied: 111945
111945 May 18, 2016 at 07:23:11 (UTC)
Goto Top
Und hier das Dump nachdem die VM neuerstellt wurde.

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 8 Kernel Version 9600 MP (2 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 9600.18264.amd64fre.winblue_ltsb.160310-0600
Machine Name:
Kernel base = 0xfffff801`d8e0f000 PsLoadedModuleList = 0xfffff801`d90e2630
Debug session time: Tue May 17 08:30:26.197 2016 (UTC - 4:00)
System Uptime: 0 days 3:06:02.636
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffc00000000238, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff801d8e44d7a, address which referenced memory

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

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

WRITE_ADDRESS: fffff801d90d0020: Unable to get special pool info
fffff801d90d0020: Unable to get special pool info
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
 ffffc00000000238 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!KxWaitForLockOwnerShip+12
fffff801`d8e44d7a 48890a          mov     qword ptr [rdx],rcx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT_SERVER

BUGCHECK_STR:  AV

PROCESS_NAME:  LinkMgr.exe

TRAP_FRAME:  ffffd000f180c4c0 -- (.trap 0xffffd000f180c4c0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=ffffd000f180c6a0
rdx=ffffc00000000238 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801d8e44d7a rsp=ffffd000f180c650 rbp=0000000000000000
 r8=ffffd000f180c6a0  r9=ffffe001b9e06510 r10=0000000000000000
r11=ffffd000f180c748 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
nt!KxWaitForLockOwnerShip+0x12:
fffff801`d8e44d7a 48890a          mov     qword ptr [rdx],rcx ds:ffffc000`00000238=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff801d8f68ee9 to fffff801d8f5d3a0

STACK_TEXT:  
ffffd000`f180c378 fffff801`d8f68ee9 : 00000000`0000000a ffffc000`00000238 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
ffffd000`f180c380 fffff801`d8f6773a : 00000000`00000001 ffffe001`ba4a0b10 ffffe001`b89f5c00 00000000`00000000 : nt!KiBugCheckDispatch+0x69
ffffd000`f180c4c0 fffff801`d8e44d7a : ffffe001`b74bdc60 00000000`00000000 00000000`00000004 fffff801`30805180 : nt!KiPageFault+0x23a
ffffd000`f180c650 fffff801`30e92ac9 : ffffe001`ba4a0b10 ffffe001`ffffffff 51535351`00000004 53535157`00000000 : nt!KxWaitForLockOwnerShip+0x12
ffffd000`f180c680 fffff801`2fe1d4e0 : ffff7ec4`2d028560 ffffd000`f180c840 ffffd000`f180cab0 ffffe001`b7552b28 : pacer!PcQoSPQueryTrafficClass+0x79
ffffd000`f180c750 fffff801`30688247 : 00000000`00000000 ffffe001`b7552b28 00000000`00000002 ffffd000`f180cab0 : NETIO!NetioQueryNetBufferListTrafficClass+0x51
ffffd000`f180c7b0 fffff801`306707b4 : 00000000`00000000 00000000`00007c04 fffff801`30805180 ffffe001`ba00b8b0 : tcpip!IppSendDatagramsCommon+0x437
ffffd000`f180c990 fffff801`30670f4a : ffffe001`b73f22b0 00000000`00000000 ffffe001`ba4df844 fffff801`30805180 : tcpip!UdpSendMessagesOnPathCreation+0x484
ffffd000`f180cde0 fffff801`306715c4 : 40f30300`a90d0880 d4dec1c6`3bef1734 00000000`00000000 00000000`00000002 : tcpip!UdpSendMessages+0x24a
ffffd000`f180d220 fffff801`d8e97c23 : ffffe001`ba4b4231 ffffe001`ba4b4080 ffffe001`b9218280 fffff801`d8eb48d1 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
ffffd000`f180d250 fffff801`3067288c : fffff801`306715b0 ffffd000`f180d370 ffffd000`f180d800 ffffe001`ba4b41c0 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd000`f180d340 fffff801`30e45676 : ffffe001`ba4df7e0 ffffd000`f180db80 ffffe001`ba4df7e0 ffffe001`ba4df7e0 : tcpip!UdpTlProviderSendMessages+0x6c
ffffd000`f180d3c0 fffff801`30e2d580 : 00000000`00066111 00000000`00000001 ffffd000`f180d609 00000000`00000001 : afd!AfdFastDatagramSend+0x536
ffffd000`f180d590 fffff801`d92ae4f2 : 00000000`00000038 ffffe001`b9237070 ffffd000`f180da50 00000000`00000001 : afd!AfdFastIoDeviceControl+0x1570
ffffd000`f180d8e0 fffff801`d927c2fe : 00000000`00000000 00000000`000018dc 00000000`00000001 00000000`00000000 : nt!IopXxxControlFile+0x7c2
ffffd000`f180da20 fffff801`d8f68bb3 : ffffe001`ba4b4080 00000000`02e4efa8 ffffd000`f180daa8 00000000`0599f638 : nt!NtDeviceIoControlFile+0x56
ffffd000`f180da90 00000000`772f2352 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`02e4ef88 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x772f2352


STACK_COMMAND:  kb

FOLLOWUP_IP: 
pacer!PcQoSPQueryTrafficClass+79
fffff801`30e92ac9 8b4608          mov     eax,dword ptr [rsi+8]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  pacer!PcQoSPQueryTrafficClass+79

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: pacer

IMAGE_NAME:  pacer.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  545054ca

FAILURE_BUCKET_ID:  X64_AV_pacer!PcQoSPQueryTrafficClass+79

BUCKET_ID:  X64_AV_pacer!PcQoSPQueryTrafficClass+79

Followup: MachineOwner
---------
Mitglied: 129413
129413 May 18, 2016 updated at 07:36:53 (UTC)
Goto Top
Sieht für mich eindeutig aus:
LinkMgr.exe
ist ein Teil von deiner Software SwyxWare 2015R3 also wird diese wohl am Bluescreen schuld sein. Wende dich an den Hersteller oder Swyx-Forum und frage nach ob der Fehler bekannt ist und es eventuellen Updates/Fixes dazu gibt.
http://www.swyx-forum.com/topic/665-server-crashes-spontaneously-and-re ...
Mitglied: 111945
111945 May 18, 2016 at 07:44:12 (UTC)
Goto Top
Auf den ersten blick scheint es eindeutig zu sein. Mich stört aber die pacer.sys. Diese ist dann wohl die Schnittstelle von Swyxware zu Windows. Ich gehe nicht davon aus, dass die Swyxware ein Betriebssystem zum "Absturz" bringen kann.

pacer.sys deutet auf QoS, ich werd mal in die Richtung suchen.


Danke erstmal
Member: MrFlow
MrFlow May 18, 2016 at 07:56:19 (UTC)
Goto Top
Was man auch noch checken könnte, wär Integrationsdienste installiert und geupdatet bis mindestens auf dem Stand, welche beim Hyper V mitgeliefert wird.

Gruß
Mitglied: 129413
129413 May 18, 2016 updated at 09:28:37 (UTC)
Goto Top
Zitat von @111945:
Ich gehe nicht davon aus, dass die Swyxware ein Betriebssystem zum "Absturz" bringen kann.
Das ist durchaus möglich wenn die Software Treiber verwendet oder installiert hat ...

Ich schätze mal das der Netzwerktreiber der VM hier Probleme macht. Wie MrFlow schreibt solltest du prüfen ob die Integrationsdienste aktuell sind. Und mal den "QoS-Packetplaner" auf dem Netzwerkadapter deaktivieren.

Welche Generation ist die VM?
Mitglied: 111945
111945 May 18, 2016 updated at 09:40:52 (UTC)
Goto Top
Ich habe jetzt mal ms_pacer und VMQ deaktiviert. Ist wohl ein Fehler der schon 2015 auftrat.

Es sind VMs der Generation 2
Mitglied: 129413
129413 May 18, 2016 updated at 09:45:26 (UTC)
Goto Top
Zitat von @111945:
Ich habe jetzt mal ms_pacer und VMQ deaktiviert. Ist wohl ein Fehler der schon 2015 auftrat.
VMQ sollte man sowieso deaktivieren denn mit dem gibt's häufig noch heftige Probleme wie auch hier zu sehen ist.
Server 2012 - Hyper-V verliert Netzwerkverbindung
Member: Coreknabe
Coreknabe May 19, 2016 at 08:01:43 (UTC)
Goto Top
Moin,

VMQ sollte man sowieso deaktivieren denn mit dem gibt's häufig noch heftige Probleme wie auch hier zu sehen ist.

Kann ich so pauschal nicht bestätigen, wir haben hier zwei Fujitsu Primergy RX300 S8, da ist VMQ von Beginn an aktiviert (Ende 2014) und wir haben keinerlei Probleme mit den VMs.

Du verlinkst auf einen anderen Thread hier, der wiederrum diesen Link enthält:
http://www.aidanfinn.com/?p=19367

Lies mal ganz unten den Kommentar, Dinge ändern sich... Setzt natürlich voraus, dass keine Uralt-Hardware vorhanden ist und die Treiber aktuell sind (inkl. Firmware).

Ich würde VMQ zunächst mal aussen vorlassen und mich auf die Fakten konzentrieren (pacer.sys). Alle Links, die ich gefunden habe, deuten auf fehlerhafte / veraltete Treiber hin:
http://www.file.net/prozess/pacer.sys.html
http://www.sevenforums.com/bsod-help-support/303349-random-blue-screen- ...
http://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/blu ...

Gruß
Mitglied: 129413
129413 May 19, 2016 at 08:03:35 (UTC)
Goto Top
Setzt natürlich voraus, dass keine Uralt-Hardware vorhanden ist und die Treiber aktuell sind (inkl. Firmware).
Das meinte ich damit. Bei zertifizierter Hardware ist das natürlich was anderes.