Zuverlässigkeit erweiterter Fehlerinformationen
Erweiterte Fehlerinformationen sind nicht zuverlässig. Erweiterte Fehlerinformationen können nicht zum Erstellen von Codelogik verwendet werden. Es ist sinnvoll, das Vorhandensein erweiterter Fehlerinformationen zu überprüfen und diese Informationen zu sichern, zu speichern oder zu protokollieren. Verlassen Sie sich jedoch nicht auf die Informationen oder deren Inhalt.
Die folgenden Gründe erläutern, warum erweiterte Fehlerinformationen nicht zuverlässig sind:
- Die Sequenz und der Inhalt der erweiterten Fehlerdatensätze hängen von der internen Architektur des Systems ab, die sich ändern kann. Ein bestimmter Vorgang kann NPFS auf aktuellen Systemen durchgehen, aber morgen könnte tcp durchgehen. Diese verschiedenen Komponenten generieren sehr unterschiedliche Fehlercodes, und Codeprüfungen sind daher grundsätzlich unzuverlässig und werden nicht empfohlen.
- Die Weitergabe erweiterter Fehlerinformationen kann wie zuvor erläutert deaktiviert werden. Wenn Erkennungscode enthalten ist, funktioniert die Anwendung wahrscheinlich in bestimmten Umgebungen nicht mehr.
- Die Weitergabe erweiterter Fehlerinformationen erfolgt auf bestmögliche Weise. Die Weitergabe oder Generierung erweiterter Fehlerinformationen kann fehlschlagen, wenn nicht genügend Arbeitsspeicher auf dem Computer vorhanden ist, um die Kette zu verarbeiten oder zu propagieren. Unter diesen Umständen wird die Kette gelöscht. Einige Protokolle haben eine begrenzte Länge für Fehlerpakete, da sie in der Regel nicht viele Informationen enthalten. Wenn die Länge der Kette die zulässige Länge des Pakets überschreitet, beginnt die RPC-Laufzeit damit, Informationen aus der Kette zu löschen, um die Kette in das Paket zu passen. Die Laufzeit löscht zuerst Datensätze, beginnend mit dem vorletzten Datensatz, die rückwärts gehen, bis nur die ersten und letzten Datensätze verbleiben. Wenn die Kette immer noch nicht in ein Paket passt, löscht die Laufzeit Zeichenfolgenparameter und Computernamen. Wenn ein Zeichenfolgenparameter gelöscht wird, wird der Typ des Parameters auf none festgelegt. Wenn ein Datensatz gelöscht wird, wird das Flag EEInfoNextRecordsMissing im nächsten Datensatz und EEInfoPreviousRecordsMissing im vorherigen Datensatz festgelegt.