XID 13, 31, 32, 43 und 45: Fehler der Anwendung oder defekte GPU unterscheiden

Was XID 13, 31, 32, 43 und 45 gemeinsam haben

XID 13, 31, 32, 43 und 45 sind Meldungen des NVIDIA-Treibers, dass ein GPU-Job gescheitert ist, und in den meisten Fällen liegt die Ursache beim Job selbst. NVIDIAs XID-Katalog nennt für 13, 31 und 32 einen Neustart der Anwendung als Sofortmaßnahme, markiert 43 als IGNORE und behandelt 45 über einen kurzen Ablauf. Auf die Hardware deutet erst ein Muster: derselbe Code auf derselben GPU bei verschiedenen Jobs oder ein Code, den auch eine bewährte Anwendung auslöst.

Ein XID ist nach NVIDIAs Worten „an error report from the NVIDIA driver that is printed to the operating system's kernel log or event log“, und die Meldungen können auf ein Hardwareproblem, ein Problem in NVIDIA-Software oder ein Problem der Anwendung hinweisen. Unsere Übersicht der NVIDIA-XID-Fehlercodes führt alle gängigen Codes mit ihren Maßnahmen auf. Dieser Artikel behandelt nur die fünf, die meist eine laufende Anwendung verursacht, und zeigt, wie Sie entscheiden, ob die Karte Aufmerksamkeit braucht.

NVIDIA XID Catalog, „Analyzing Xid Errors with the Xid Catalog“, letzte Aktualisierung 9. September 2026, und seine PDF-Ausgabe (Release 615), gelesen am 24. Oktober 2026. Der Katalog führt alle fünf Codes als zutreffend für A100, H100, B100 und GB200.

Die PDF-Ausgabe definiert RESTART_APP als „The application should be restarted“ und CHECK_APP/CUDA als ein Problem, das „likely caused by an application passing bad data or utilizing incorrect methods in communications with GPU“ ist, mit dem Zusatz „If determined to be a driver issue then REPORT_ISSUE“.

Die Logzeile lesen: PCI-Adresse, PID und Prozessname

Jede XID-Zeile beginnt mit NVRM: Xid, gefolgt von der PCI-Adresse der GPU und dem Code. NVIDIAs Katalog ergänzt: „Some errors will contain PID that can be used to identify source of the problem“, und bei 13 und 31 schreibt der Treiber nach dem Code weitere Details. Ein unbestätigter Nutzerbericht in NVIDIAs Entwicklerforum vom März 2026 zu einer RTX PRO 6000 Blackwell Workstation Edition mit Treiber 590.48.01 zeigt, was solche Zeilen enthalten.

In einem Nutzerbericht in NVIDIAs Entwicklerforum zitierte Logzeilen, 21. März 2026 (zwei RTX PRO 6000 Blackwell Workstation Edition, Treiber 590.48.01), gelesen am 24. Oktober 2026. Ein Bericht, keine Aussage von NVIDIA; der Aufbau der Felder kann sich zwischen Treiberzweigen ändern.

Drei Schritte ordnen eine Zeile einer Last zu. Ordnen Sie zuerst die PCI-Adresse einer Karte zu: nvidia-smi -q -i akzeptiert die PCI-Bus-ID und gibt die Seriennummer aus, sodass jede weitere Notiz die Karte nennt und nicht nur den Steckplatz. Unser Leitfaden zum Finden der defekten GPU über Bus-ID, Slot und Seriennummer zeigt die Schritte. Gleichen Sie dann PID und Prozessnamen mit dem Job ab, der zu dieser Zeit lief. Wenn Sie das Log lesen, ist der Prozess meist schon beendet; suchen Sie deshalb im Job-Log des Schedulers oder im Log der Container-Runtime. nvidia-smi -q -d PIDS zeigt nur die Prozesse, die gerade auf der GPU laufen. Notieren Sie zuletzt bei einem XID 13 die Nummern von GPC, TPC und SM, denn der Ablauf im Katalog fragt, ob Wiederholungen dieselbe Einheit treffen.

In Kubernetes beobachtet NVIDIAs Device Plugin die XIDs und markiert eine GPU bei einem kritischen XID als „unhealthy“. Seine Zustandsprüfung im Main-Zweig, gelesen am 24. Oktober 2026, überspringt eine fest eingetragene Liste mit dem Kommentar „Application errors: the GPU should still be healthy“: 13, 31, 43, 45, 68 und 109. Bricht ein Pod mit XID 31 ab, bleibt seine GPU also für den Scheduler verfügbar, und der nächste Pod landet auf ihr. Andere Codes wie 48 oder 62 markieren das Gerät als „unhealthy“, wenn NVML sie als kritische XID-Ereignisse meldet, und die Datei enthält keinen Codepfad, der ein Gerät wieder als „healthy“ markiert. Mit der Variablen DP_DISABLE_HEALTHCHECKS lässt sich die Prüfung abschalten, mit „all“ oder „xids“ oder mit einer Liste von Codes.

Wir bauen GPU-Server mit RTX PRO 6000 Server Edition, L40S, L4 und H200 NVL und installieren auf Wunsch Treiber, CUDA und eine Container-Runtime; schicken Sie uns Ihre Last und die XID-Zeilen, die Sie sehen, und unser Team antwortet mit dem, was wir zuerst prüfen würden.

XID 13: Graphics Engine Exception

Laut Katalog wird XID 13 „for general user application faults“ protokolliert, und „Typically this is an out-of-bounds error where the user has walked past the end of an array“. Die Sofortmaßnahme ist ein Neustart der Anwendung. NVIDIAs GPU Debug Guidelines, aktualisiert am 4. Oktober 2026, fügen einen Schritt hinzu: „Run DCGM and Field diagnostics to confirm if the issue is related to hardware“; ist die Hardware in Ordnung, wird die Anwendung untersucht.

Der Untersuchungsablauf in der PDF-Ausgabe ordnet XID 13 nach Mustern:

1. Wiederholungen auf demselben TPC und GPC, auf verschiedenen SMs oder auf einem SM: DCGM-Diagnose als „possible HW issue“, und wenn sie besteht, NVIDIAs Felddiagnose.
2. Ein einzelnes Ereignis ohne Häufung, oder Wiederholungen, die nicht denselben TPC und GPC treffen: CHECK_APP/CUDA, ein Problem der Anwendung.
3. In einer Umgebung außerhalb der Produktion: CHECK_APP/CUDA.
4. Eine bewährte Anwendung und ein einzelnes Ereignis: REPORT_ISSUE.

NVIDIA definiert „solo“ und „burst“ im Katalog nicht. Wir lesen „solo“ als XID 13 ohne weitere XIDs in seiner Nähe und „burst“ als mehrere kurz hintereinander.

Für die Seite der Anwendung hat NVIDIAs Compute Sanitizer (Version 2026.3.0) das Werkzeug memcheck, das „can precisely detect and report out of bounds and misaligned memory accesses to global, local and shared memory“. Es ist standardmäßig aktiv und wird mit compute-sanitizer --tool memcheck vor den Programmaufruf gesetzt. Lassen Sie es auf einer Testinstanz mit der Eingabe laufen, die gescheitert ist, nicht im Produktivdienst, denn die Instrumentierung verlangsamt das Programm.

Auf Blackwell kann ein bekannter Treiberfehler dasselbe Bild erzeugen. Laut den Release Notes von Treiber 595.112.07 (22. Oktober 2026) können Anwendungen, die auf Blackwell-GPUs cuTensorMapEncodeTiled() oder cuTensorMapEncodeIm2col*() nutzen, „sporadic illegal memory accesses (IMA) or MMU faults (like XID 13)“ erleben, wenn der Speicher hinter dem Tensor kleiner als 128 KB ist und der Tensor nicht dicht und überlappungsfrei ist. Die Release Notes nennen einen Workaround im Anwendungscode und noch keine Treiberversion mit der Korrektur. Treten XID 13 oder 31 auf RTX-PRO-Blackwell-Karten mit Kernels auf, die solche Tensor Maps verwenden, prüfen Sie diesen Eintrag, bevor Sie die Karte verdächtigen.

XID 31: Seitenfehler im GPU-Speicher

XID 31 „is logged when a fault is reported by the MMU“, die Speicherverwaltung der GPU, wenn ein Prozess auf eine Adresse zugreift, für die er keine Zuordnung hat. Der Katalog hält fest: „Typically these are application-level bugs, but can also be driver bugs or hardware bugs.“ Sein Ablauf beginnt mit „Multiple runs needed to establish pattern“:

1. Wiederholte MMU-Fehler auf derselben GPU, erkannt an ihrer PCI-ID: DCGM-Diagnose als mögliches Hardwareproblem, danach die Felddiagnose, wenn sie besteht.
2. Wiederholte MMU-Fehler auf verschiedenen GPUs: CHECK_APP/CUDA.
3. Ein einzelner Fehler ohne Häufung: CHECK_APP/CUDA.
4. Ein Fehler einer bewährten Anwendung: REPORT_ISSUE.

NVIDIAs zwei Dokumente gewichten XID 31 unterschiedlich. Der Katalog nennt ihn typischerweise einen Fehler der Anwendung, während die Triage-Tabelle der GPU Debug Guidelines ihn als „Suspected Hardware Problems“ mit dem Schritt „Contact the hardware vendor“ führt. In der Praxis hilft die Musterregel des Katalogs mehr: Ein einzelner Fehler oder Fehler, die mit einer Anwendung zwischen GPUs wandern, gehören in die Verantwortung des Anwendungsteams; Fehler, die über verschiedene Jobs bei einer Karte bleiben, gehen an den Hersteller.

Der oben zitierte Forumsbericht folgt diesem zweiten Muster. Der Verfasser protokollierte 47 XID-Ereignisse auf einer von zwei baugleichen Karten, sah den Fehler mit der Karte in einen anderen PCIe-Steckplatz wandern und auf der zweiten Karte unter derselben vLLM-Last keinen; nach seinem Bericht löste auch NVIDIAs Diagnosewerkzeug nvvs auf der fehlerhaften Karte einen XID 31 aus. Stand 24. Oktober 2026 nennt der Thread weder eine bestätigte Ursache noch eine Lösung; er ist die Beobachtung eines einzelnen Nutzers. Den Tausch der Steckplätze beschreibt Schritt für Schritt unser Artikel zu XID 79, der GPU, die vom Bus gefallen ist.

XID 32: beschädigter Push Buffer, ein Hinweis auf PCIe

XID 32 hat dieselbe Sofortmaßnahme wie 13 und 31, einen Neustart der Anwendung, aber eine andere Ursache. Der Katalog schreibt: „These failures primarily involve quality issues on PCI, and are generally not caused by user application actions.“ Ein einzelner XID 32 nach einem Neustart des Jobs braucht nicht mehr als eine Notiz. Wiederholungen gehören zu den PCIe-Prüfungen: Linkgeneration und -breite unter Last, „Replays Since Reset“ in nvidia-smi -q, der Riser und sein Kabel und die AER-Zähler, in der Reihenfolge unseres Artikels zu XID 79.

XID 43 und 45: Codes zur Information

XID 43 „is logged when a user application hits a software induced fault and must terminate“, und NVIDIA ergänzt: „The GPU remains in a healthy state.“ Die Sofortmaßnahme ist IGNORE. CONTACT_SUPPORT ist die Maßnahme zur Untersuchung für den Fall, dass er ohne Erklärung in der Anwendung wiederkehrt.

XID 45 „is logged when the user application aborts and the kernel driver tears down the GPU application“. Der Katalog ergänzt, er sei „Most likely to see when running multiple cuda applications and hitting a DBE“, also einen Double-Bit-ECC-Fehler, und „In many cases, this is not indicative of a bug but rather a user or system action.“ Die GPU Debug Guidelines nennen ihn „informative only“. Der Ablauf lautet „Solo: RESTART_FM Not Solo: IGNORE (follow guidance in other Xid)“. RESTART_FM bezieht sich nach unserer Lesart auf NVIDIAs Fabric Manager, den die Debug Guidelines für Systeme mit NVSwitch behandeln; sie beschreiben einen alleinstehenden XID 45 auf der A100 nach einem unerwarteten Herunterfahren des Fabric Managers.

Auf PCIe-Servern zählt die zweite Hälfte dieser Regel mehr. Erscheint 45 zusammen mit 48, 94 oder 95, sagen die Einträge des Katalogs zu 94 und 95 „Xid 45 will be seen in relation to this error“, und der Speicherfehler bestimmt den nächsten Schritt, wie unser Leitfaden zu XID 94, 95, 48 und 63, ECC-Fehlern und Row Remapping beschreibt. Ein XID 45 neben einem 62 oder 154 gehört zu unserem Artikel zu XID 154 und 62, GPU-Reset oder Server-Neustart.

Wann ein Anwendungsfehler auf die Karte deutet

Die Tabelle verdichtet NVIDIAs Abläufe zu den Mustern, die ein Betreiber in einer Woche Logs sieht.

Abläufe WORKFLOW_XID_13, WORKFLOW_XID_31 und WORKFLOW_XID_45 im NVIDIA XID Catalog (Release 615, 9. September 2026) und NVIDIA GPU Debug Guidelines (4. Oktober 2026); die Einteilung nach Logmustern stammt von uns.

Nehmen Sie einen Server mit vier RTX PRO 6000 Server Edition, auf dem vLLM vier Kopien eines Modells betreibt, eine je Karte. GPU 2 meldet in einer Woche dreimal XID 31, jedes Mal unter einer anderen Modellversion, und die drei anderen Karten bleiben fehlerfrei. Der Fehler bleibt über verschiedene Jobs bei einer PCI-Adresse, also gilt der erste Zweig des Katalogs: Nehmen Sie die Kopie dieser Karte aus dem Betrieb, lassen Sie dcgmi diag -r 3 darauf laufen und fragen Sie, wenn sie besteht, den Hersteller nach der Felddiagnose. Melden dagegen alle vier Karten innerhalb einer Stunde nach dem Ausrollen eines neuen Container-Images XID 31, wandert der Fehler mit einer Anwendung zwischen GPUs, und das Image ist verdächtig.

DCGM führt nicht jede Diagnosestufe auf jeder Karte aus. Unser Leitfaden zum Abnahmetest erklärt, welche Stufen NVIDIAs Funktionstabelle den Rechenzentrumskarten gibt, warum sie keine RTX-PRO-Blackwell-Karte nennt und was DCGM 4.6.0 geändert hat. Alarme für diese Codes behandelt unser Leitfaden zum Monitoring von GPU-Servern mit DCGM.

Was Sie vor einem Supportfall sammeln

NVIDIAs GPU Debug Guidelines führen unter „Reporting a GPU Issue“ auf, was eine Meldung an den Hersteller enthalten sollte:

1. Die Grundkonfiguration des Systems, etwa Betriebssystem und Treiberversion.
2. Eine klare Beschreibung des Problems mit den wichtigsten Logmeldungen.
3. Die bereits unternommenen Schritte zur Fehlersuche.
4. Das vollständige Log, das diese Meldungen enthält.
5. Die Ausgabe von nvidia-bug-report.sh.
6. Die Logs der DCGM-Diagnose.
7. Angaben zur Anwendung, wenn der Fehler an eine gebunden ist.

Für Anwendungsfehler ergänzen Sie, wonach die Abläufe fragen: jede XID-Zeile mit Uhrzeit, PCI-Adresse, PID und Prozessname, die Seriennummer jeder Karte, die Versionen von Container-Image und Framework und ob eine zweite Karte denselben Job ohne Fehler ausgeführt hat. Die Guidelines enden mit „Submit a ticket to your system vendor“. NVIDIA nennt seine Felddiagnose „the authoritative and comprehensive NVIDIA tool for determining the health of GPUs“ und schreibt, sie sei „usually required before an RMA can be started“; wann und wie sie läuft, sagt der Systemhersteller.

Für GPUs, die Sie bei uns gekauft haben, wird die Herstellergarantie über uns abgewickelt, mit Support durch das Service-Team unseres Engineering-Partners. Schreiben Sie uns mit den XID-Zeilen, den Seriennummern und der Diagnoseausgabe, und wir antworten innerhalb eines Werktages mit dem nächsten Schritt für die Karte.

Was wir liefern

Wir bauen KI-Server nach Auftrag mit RTX PRO 6000 Server Edition, L40S, L4 und H200 NVL, vor der Lieferung montiert und getestet, mit Herstellergarantie auf jede Komponente und Ersatz bei DOA, auf einem EU-Vertrag und einer Rechnung. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch. Zu Speicherfehlern, GSP-Timeouts und Resets lesen Sie unsere Artikel zu XID 119 und 120, XID 94 und 95 sowie XID 154 und 62.

FAQ