Jump to content

Neustart bei "Verbindung zurücksetzen" - Err 0x...8E


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo allerseits,

 

wir haben einen 2k3R2 Enterprise auf echter Hardware (Dell Power Edge 2950) in einem klimatisierten Raum. Dieser läuft seit Jahren problemlos durch. Er dient als Terminalserver für Mitarbeiter die ausschliesslich in unserem Warenwirtschaftssystem arbeiten.

 

Regelmäßig werden getrennte Verbindungen per Hand zurück gesetzt:

- Per Remotedesktopverbindung als Administrator zum Server verbinden

- Terminaldienstverwaltung aufrufen

- In der Sitzungsübersicht alle getrennten Sitzungen markieren

- Kontextmenü per rechter Maustaste öffnen und auf "Verbindung zurücksetzen" klicken

 

Dies ist notwendig, weil die Sitzungen sonst teilweise blockieren (Benutzer die sich am Mo Abend vom Server getrennt haben können dann zB. am Di Morgen keine neue Sitzung starten).

 

Nun ist es in den letzten Wochen zweimal vorgekommen, dass der Server ohne erkenntlichen Grund direkt nach dem Klick auf "Verbindung zurücksetzen" neu gestartet ist. Er hat dann ein Speicherabbild erstellt und ist fehlerfrei hochgefahren.

 

Die Ereignismeldung dazu:

Quelle:

SaveDump

Ereigniskennung:

1001

Beschreibung:

Der Computer ist nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x0000008e (0xc0000005, 0xbf8a28d8, 0xf1c1cb1c, 0x00000000). Ein volles Abbild wurde gespeichert in C:\WINDOWS\MEMORY.DMP.

 

Weitere Beeinträchtigungen konnten bisher nicht festgestellt werden. Am Server wurden seit Langem KEINERLEI Änderungen vorgenommen, weder auf Hardware- noch auf Softwareseite. Da Software nicht verschleisst, gehen wir grundsätzlich von einem Hardwaredefekt aus. Dies wird auch in einem anderen Thread in dem ich nachgefragt hatte als Ursache vermutet (hier).

 

Inzwischen hat mein Kollege, welcher hauptsächlich den Server und das Warenwirtschaftssystem betreut, den Server mal komplett vom Netz getrennt (nachdem der Server mit "Memtest86 4.0a" hängen blieb) und neu hochgefahren. Danach fand beim Zurücksetzen von Verbindungen kein Neustart mehr statt, was aber auch Zufall sein kann.

 

Wir haben bereits den RAM mit "Memtest86 Version 4.0b (Server)" getestet ohne Fehler zu finden.

 

Des Weiteren hat der Server bereits von Dell einige Analyse- und Überwachungsfunktionen für die Hardware, welche ebenfalls keine Probleme finden.

 

Wir planen nun einen Stresstest mit der AIDA-Software, alternativ wurde auch eine testweise Neuinstallation des Server vorgeschlagen. Die Neuinstallation ist für uns jedoch momentan schwer realisierbar.

 

Der Inhalt des MEMORY.DMP (mit WinDbg geöffnet) folgt in Kürze.

 

Wir tappen noch ziemlich im Dunkeln woher die Neustarts kommen, daher würde ich mich über sachdienliche Hinweise freuen!

 

Beste Grüße

Robert

Link zu diesem Kommentar

Hier Auszüge der Memory.dmp-Analyse, die mir mein Kollege gerade geschickt hat:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: bf8a28d8, The address that the exception occurred at
Arg3: f1c1cb1c, Trap Frame
Arg4: 00000000

[...]

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: win32k

FAULTING_MODULE: 80800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4a8417a6

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx" verweist auf Speicher in "0x%08lx". Der Vorgang  "%s" konnte nicht auf dem Speicher durchgef hrt werden.

FAULTING_IP: 
win32k+a28d8
bf8a28d8 f6461e40        test    byte ptr [esi+1Eh],40h

TRAP_FRAME:  f1c1cb1c -- (.trap 0xfffffffff1c1cb1c)
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=0000029d edx=00000001 esi=00000000 edi=bc367b40
eip=bf8a28d8 esp=f1c1cb90 ebp=f1c1cba8 iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282
win32k+0xa28d8:
bf8a28d8 f6461e40        test    byte ptr [esi+1Eh],40h     ds:0023:0000001e=??
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 8082d820 to 80827c83

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
f1c1c6e8 8082d820 0000008e c0000005 bf8a28d8 nt!KeBugCheckEx+0x1b
f1c1caac 8088a2aa f1c1cac8 00000000 f1c1cb1c nt!KeTerminateThread+0xee2
f1c1cb28 bf85dab7 00000000 00000000 bc367b00 nt!Kei386EoiHelper+0x1d2
f1c1cba8 bf84abdd 00000000 bc367b40 00000000 win32k+0x5dab7
f1c1cc00 bf83c96d 00000000 f1c1cc64 bf8b83c4 win32k+0x4abdd
f1c1cc0c bf8b83c4 be112d90 bc235cc0 bc235c40 win32k+0x3c96d
f1c1cc64 bf8b701a 00000001 f1c1cc8c bf8b7e77 win32k+0xb83c4
f1c1cc70 bf8b7e77 92f1ab08 00000001 00000000 win32k+0xb701a
f1c1cc8c 8094c38a 92f1ab08 00000001 92f1ab08 win32k+0xb7e77
f1c1cd18 8094c71d 00000000 00000000 92f1ab08 nt!PsGetProcessExitTime+0xa58
f1c1cd30 8094ca6f 92f1ab08 00000000 00000001 nt!PsGetProcessExitTime+0xdeb
f1c1cd54 808897cc fffffffe 00000000 012bffdc nt!PsGetProcessExitTime+0x113d
f1c1cd64 7c94860c badb0d00 012bffd4 00000000 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb64
f1c1cd68 badb0d00 012bffd4 00000000 00000000 0x7c94860c
f1c1cd6c 012bffd4 00000000 00000000 00000000 0xbadb0d00
f1c1cd70 00000000 00000000 00000000 00000000 0x12bffd4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k+a28d8
bf8a28d8 f6461e40        test    byte ptr [esi+1Eh],40h

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  win32k+a28d8

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  win32k.sys

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner

 

Wird daraus jemand schlau?

 

Beste Grüße

Robert

Link zu diesem Kommentar

Hier auszugsweise die Analyse des Memory.dmp:

 

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: bf8a28d8, The address that the exception occurred at
Arg3: f1c1cb1c, Trap Frame
Arg4: 00000000

[...]

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: win32k

FAULTING_MODULE: 80800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4a8417a6

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx" verweist auf Speicher in "0x%08lx". Der Vorgang  "%s" konnte nicht auf dem Speicher durchgef hrt werden.

FAULTING_IP: 
win32k+a28d8
bf8a28d8 f6461e40        test    byte ptr [esi+1Eh],40h

TRAP_FRAME:  f1c1cb1c -- (.trap 0xfffffffff1c1cb1c)
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=0000029d edx=00000001 esi=00000000 edi=bc367b40
eip=bf8a28d8 esp=f1c1cb90 ebp=f1c1cba8 iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282
win32k+0xa28d8:
bf8a28d8 f6461e40        test    byte ptr [esi+1Eh],40h     ds:0023:0000001e=??
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 8082d820 to 80827c83

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
f1c1c6e8 8082d820 0000008e c0000005 bf8a28d8 nt!KeBugCheckEx+0x1b
f1c1caac 8088a2aa f1c1cac8 00000000 f1c1cb1c nt!KeTerminateThread+0xee2
f1c1cb28 bf85dab7 00000000 00000000 bc367b00 nt!Kei386EoiHelper+0x1d2
f1c1cba8 bf84abdd 00000000 bc367b40 00000000 win32k+0x5dab7
f1c1cc00 bf83c96d 00000000 f1c1cc64 bf8b83c4 win32k+0x4abdd
f1c1cc0c bf8b83c4 be112d90 bc235cc0 bc235c40 win32k+0x3c96d
f1c1cc64 bf8b701a 00000001 f1c1cc8c bf8b7e77 win32k+0xb83c4
f1c1cc70 bf8b7e77 92f1ab08 00000001 00000000 win32k+0xb701a
f1c1cc8c 8094c38a 92f1ab08 00000001 92f1ab08 win32k+0xb7e77
f1c1cd18 8094c71d 00000000 00000000 92f1ab08 nt!PsGetProcessExitTime+0xa58
f1c1cd30 8094ca6f 92f1ab08 00000000 00000001 nt!PsGetProcessExitTime+0xdeb
f1c1cd54 808897cc fffffffe 00000000 012bffdc nt!PsGetProcessExitTime+0x113d
f1c1cd64 7c94860c badb0d00 012bffd4 00000000 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb64
f1c1cd68 badb0d00 012bffd4 00000000 00000000 0x7c94860c
f1c1cd6c 012bffd4 00000000 00000000 00000000 0xbadb0d00
f1c1cd70 00000000 00000000 00000000 00000000 0x12bffd4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k+a28d8
bf8a28d8 f6461e40        test    byte ptr [esi+1Eh],40h

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  win32k+a28d8

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  win32k.sys

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner

 

Wird jemand daraus schlau?

 

Beste Grüße

Robert

Link zu diesem Kommentar

Hallo,

 

ich denke es handelt sich hier um keinen Software- sondern um einen Hardwarefehler. Auch wenn die von Dell nichts auslesen konnten könnte es zum Beispiel sein, dass die Kühlung der CPU nicht anständig läuft oder die Leitpaste unter dem Lüfter über die Jahre verdrocknet ist. Lüfter mal runternehmen, neue Leitpaste drauf und schauen was passiert. Kommt gerade bei Servern die sehr lange schon am laufen sind häufiger vor.

 

cu

 

##mur

Link zu diesem Kommentar

Hallo,

 

ich verweise nochmal auf meine Vermutung oben. Hast du diese einmal kontrolliert?

 

ich denke es handelt sich hier um keinen Software- sondern um einen Hardwarefehler. Auch wenn die von Dell nichts auslesen konnten könnte es zum Beispiel sein, dass die Kühlung der CPU nicht anständig läuft oder die Leitpaste unter dem Lüfter über die Jahre verdrocknet ist. Lüfter mal runternehmen, neue Leitpaste drauf und schauen was passiert. Kommt gerade bei Servern die sehr lange schon am laufen sind häufiger vor.

 

Ansonsten würde ich auch sagen, dringend einen Notfallplan erstellen. Eventuell P2V Migration wenn du einen geeigneten Host hast.

 

cu

 

##MUR

Link zu diesem Kommentar
  • 2 Wochen später...

Hallo Allerseits,

 

inzwischen sind wir ein bis zwei Schritte weiter gekommen. Viele Telefonate mit sogenannten "Systemhäusern" und mit Dell sind geführt worden. Nach Test von RAM, HDDs, CPU-Temperaturen, diversen zusätzlichen Diagnose-Tools (unter Anderem auch von Dell) und Installation aller verfügbaren (und sinnvollen) Windows-Updates scheint der Fehler eingegrenzt:

 

Es gab doch eine Software-Änderung. Im Jahr des Herrn 2011 haben wir selbst eine "Schadsoftware" auf dem Server installiert, die jedoch erst durch intensivere Nutzung seit Februar 2012 in Aktion getreten ist.

Die Software ist ein pdf-Reader mit einem X im Namen. :suspect:

 

So konnten wir teilweise nachvollziehen, dass beim Zurücksetzen von ganz bestimmten Verbindungen der Server einen automatischen Neustart nach einem Fehler durchgeführt hat. Diese Verbindungen gehörten zu Nutzern, welche mit dem Reader in einer Terminalsitzung gearbeitet haben.

 

Wir haben geplant testweise auf die Vorgängerversion des Readers umzusteigen, wofür die Vorbereitungen jetzt laufen.

 

Soweit der Stand!

 

Beste Grüße

Robert

Link zu diesem Kommentar

Es gab doch eine Software-Änderung. Im Jahr des Herrn 2011 haben wir selbst eine "Schadsoftware" auf dem Server installiert, die jedoch erst durch intensivere Nutzung seit Februar 2012 in Aktion getreten ist.

Die Software ist ein pdf-Reader mit einem X im Namen. :suspect:

 

Welche genaue Version des uns unbekannten PDF Reader habt ihr im Einsatz? Und auf welche Version wollt ihr zurück?

Link zu diesem Kommentar

Hallo sunny61.

 

Dieser euch unbekannte Reader ist der wahrscheinlich am häufigsten auf der Welt eingesetzte pdf-Reader in der Version 10.1.2.

 

Wir wollen dann auf eine 9er Version zurück, die mein Kollege ermittelt hat - die genaue Versionsnummer weiß ich nicht.

Er meinte nur, es wäre auch eine vom Softwarehersteller für Windows Server 2003 R2 32bit freigegebene Version.

 

Warum fragst du?

Link zu diesem Kommentar

Guten Morgen lefg,

 

nein, wir haben noch keinen Stresstest durchgeführt. Mein Kollege (der unsere EDV-Abteilung darstellt und Entscheidungsträger ist - ich bin "nur" die rechte Hand der EDV-Abteilung) hat das Neu-Aufsetzen des Server geplant, wenn das pdf-Reader-Downgrade (kann man das so nennen?) auch keine Wirkung zeigt. Aber im Moment ist die Spur heiß!

 

Der Server muss hochverfügbar sein, die zeitraubende Neuinstallation soll direkt auf der Maschine erfolgen und Zeit für abschliessende Tests nach dem Neuaufsetzen soll auch noch bleiben. Dafür bleibt uns nur das Wochenende und eine Menge Rahmenbedingungen müssen passen. Erschwerend kommt hinzu, dass wir eben für mehrere Standorte und einige hundert Mitarbeiter mit 1 1/2 Mann völlig unterbesetzt sind...

Aber verworfen haben wir den Test nicht.

 

Beste Grüße

Robert

 

Edit: Wir haben übrigens von Dell noch ein Diagnoseprogramm speziell für den Server bekommen, welches auch eine Art Stresstest durchführt. Das lassen wir bei Gelegenheit noch laufen - dafür muss der Server aber auch heruntergefahren werden.

bearbeitet von GERoS
Was soll ich begründen? Mir ist eben noch was eingefallen!
Link zu diesem Kommentar

Hello again,

 

mein Kollege meinte gerade, er hat einen AIDA-Komplett-Test schon vor einer Weile laufen lassen (nicht tagelang, aber ein Weilchen), ohne dass Fehler gefunden wurden bzw. ohne dass er Probleme erkennen konnte (zB. mit CPU-Temperaturen).

 

Der neue (alte) Reader ist inzwischen seit gestern Abend drauf - mal sehen wie es läuft!

 

Beste Grüße

Robert

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...