Ich habe einen Web-Service in IIS-10 auf einer Windows Server 2016-Instanz innerhalb eines VM Hypervisor ausgeführt. Eine separate geplante Aufgabe ruft Funktionen des Webdienstes außerhalb der Spitzenzeiten auf, um Statusaktualisierungen von einem System eines Drittanbieters abzurufen. Die geplante Aufgabe unterteilt die Elemente, deren Status in kleine Stapel gezogen werden muss, und ruft eine Funktion auf, die die Datensätze über Tasks parallel abruft/aktualisiert und nach Abschluss aller Tasks eine Rückgabe zurückgibt.WCF-Dienst hart Absturz Windows 2016
Manchmal (jedes dritte Mal?), Während dieser geplanten Aufgabe, hängt der App-Pool, auf dem der Dienst ausgeführt wird, auf. Log4Net beendet die Protokollierung, Anfragen an den Dienst erhalten keine Antwort, die IIS-Protokollierung für den Dienst wird nicht mit Anfragen aktualisiert. In meinen Protokollen oder in den Windows-Ereignisprotokollen sind keine Fehler aufgezeichnet. Wenn dies geschieht, bleibt der App-Pool unbegrenzt in diesem Zustand. Wenn ich den App-Pool, auf dem der Dienst ausgeführt wird, wiederverwende, wird der Dienst normalerweise ~ 30 Sekunden lang reagieren und der Server wird dann einen harten Neustart durchführen.
Nach dem Neustart die Ereignisprotokolle zeigen die folgenden Fehler:
The computer has rebooted from a bugcheck. The bugcheck was: 0x00000139 (0x0000000000000003, 0xffffd60019506680, 0xffffd600195065d8, 0x0000000000000000).
Die DMP-Datei, die den gleichen Fehlercode zeigt erzeugt wird, und identifiziert die Datei als ntoskrnl.exe.
Alle Treiber sind auf dem neuesten Stand. Ich habe sichergestellt, dass alle Aufgaben und Anfragen Timeouts haben. Ich habe die Serverressourcen über den Punkt hinaus erhöht, wo dies die Ursache sein könnte. Ich habe die Chargengröße der zu bearbeitenden Artikel angepasst.
Ich bin aus der Fehlersuche Ideen und würde mich über jede Hilfe freuen, die ich bekommen kann.
'0x139' ist [' KERNEL_SECURITY_CHECK_FAILURE'] (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check---bug-check-0x139-kernel-security -check-failure), und der erste Parameter zeigt an, dass dies auf eine 'LIST_ENTRY'-Beschädigung zurückzuführen ist. Mit anderen Worten: Sie haben einen Treiber, der einen Fehler enthält, unabhängig davon, ob dieser aktuell ist. ("ntoskrnl.exe" ist genau dort, wo das Problem entdeckt wird, höchstwahrscheinlich nicht dort, wo der eigentliche Fehlercode liegt.) –
Ohne in ein vollständiges Kernel-Debugging-Tutorial zu gehen, könnten Sie [windbg] installieren (https://docs.microsoft .com/de-de/windows-hardware/drivers/debugger/index), laden Sie den Dump ('windbg -z') und machen Sie einen schnellen'! analyze -v', um zu sehen, ob er den Treiber lokalisieren kann. Da dies eine VM ist, ist es natürlich auch möglich, dass der Hypervisor selbst fehlerhaft ist (die virtuelle Hardware ist "kaputt"), und die Analyse ergibt nichts Sinnvolles (da Sie die Treiber nicht kontrollieren können). Aber dafür haben Sie Microsoft Support. –
Korrektur zu dem oben genannten: das ist, was Sie VMWare-Unterstützung haben. Microsoft behandelt keine Support-Tickets für kaputte virtuelle Hardware, wenn diese nicht Hyper-V betreffen, da die Drittanbieter-Virtualisierungsebene dafür verantwortlich sein könnte. –