Verstehen und Beheben von Azure IoT Hub-Fehlern

In diesem Artikel werden die Ursachen und Lösungen für häufige Fehlercodes beschrieben, die bei der Verwendung von IoT Hub auftreten können.

400027 Verbindung bei neuer Verbindung zwangsweise geschlossen

Möglicherweise wird der Fehler 400027 ConnectionForcefullyClosedOnNewConnection angezeigt, wenn Ihr Gerät die Verbindung beendet und Communication_Error als ConnectionStatusChangeReason mittels .NET-SDK- und MQTT-Transporttyp meldet. Oder ihr Geräte-zu-Cloud-Twin-Vorgang (z. B. gemeldete Eigenschaften lesen oder patchen) oder der direkte Methodenaufruf schlägt mit dem Fehlercode 400027 fehl.

Dieser Fehler tritt auf, wenn ein anderer Client eine neue Verbindung mit IoT Hub mit derselben Identität erstellt, sodass IoT Hub die vorherige Verbindung schließt. IoT Hub lässt nicht zu, dass mehr als ein Client eine Verbindung mit derselben Identität herstellt.

Um diesen Fehler zu beheben, stellen Sie sicher, dass jeder Client mithilfe einer eigenen Identität eine Verbindung mit IoT Hub herstellt.

401003 IoT Hub nicht autorisiert

In den Protokollen sehen Sie möglicherweise ein Muster, bei dem die Geräteverbindungen mit 401003 IoTHubUnauthorized getrennt werden, gefolgt von 404104 DeviceConnectionClosedRemotely und kurz darauf wieder erfolgreich verbunden werden.

Oder Anforderungen an IoT Hub schlagen mit einer der folgenden Fehlermeldungen fehl:

• Autorisierungsheader fehlt
• IotHub '*' enthält nicht das angegebene Gerät '*'
• Autorisierungsregel '*' lässt keinen Zugriff für '*' zu
• Fehler bei der Authentifizierung für dieses Gerät, Erneuern des Tokens oder Zertifikats und erneute Verbindung
• Fingerabdruck stimmt nicht mit konfiguration überein: Fingerabdruck: SHA1Hash=*, SHA2Hash=*; Konfiguration: PrimaryThumbprint=*, SecondaryThumbprint=*
• Der Prinzipal user@example.com ist nicht für GET für /exampleOperation autorisiert, weil keine Berechtigungen zugewiesen wurden.

Dieser Fehler tritt auf, da einige SDKs für MQTT darauf angewiesen sind, dass das IoT Hub die Verbindung trennt, wenn das SAS-Token abläuft, um zu wissen, wann es aktualisiert werden muss. Also:

1. Das SAS-Token läuft ab
2. IoT Hub bemerkt den Ablauf und trennt die Geräteverbindung mit 401003 IoTHubUnauthorized
3. Das Gerät schließt die Trennung der Verbindung mit 404104 DeviceConnectionClosedRemotely ab.
4. Das IoT SDK generiert ein neues SAS-Token
5. Das Gerät verbindet sich erfolgreich erneut mit dem IoT Hub.

Oder IoT Hub konnte den Authentifizierungsheader, die Regel oder den Schlüssel nicht authentifizieren. Dieses Ergebnis könnte auf einen der Gründe zurückzuführen sein, die in den Symptomen zitiert werden.

Um diesen Fehler zu beheben, ist keine Aktion erforderlich, wenn IoT SDK für die Verbindung mit der Geräteverbindungszeichenfolge verwendet wird. Das IoT SDK generiert das neue Token, um die Verbindung bei Ablauf des SAS-Tokens wiederherzustellen.

Die Standardmäßige Tokenlebensdauer beträgt 60 Minuten über SDKs hinweg. Für einige SDKs ist jedoch die Tokenlebensdauer und der Schwellenwert für die Tokenerneuerung konfigurierbar. Darüber hinaus unterscheiden sich die Fehler, die generiert werden, wenn ein Gerät während der Tokenerneuerung die Verbindung trennt und erneut herstellt, für jedes SDK. Um mehr zu erfahren und Informationen darüber, wie Sie das verwendete SDK Ihres Geräts in Protokollen ermitteln können, finden Sie im Abschnitt "MQTT-Gerätetrennverhalten mit Azure IoT SDKs" im Abschnitt "Überwachung, Diagnose und Fehlerbehebung bei der Gerätekonnektivität von Azure IoT Hub".

Wenn die Anzahl der Fehler für Geräteentwickler ein Problem darstellt, wechseln Sie zum C SDK, das das SAS-Token vor dem Ablauf erneuert. Bei AMQP kann das SAS-Token ohne Unterbrechung der Verbindung aktualisiert werden.

Im Allgemeinen sollte die angezeigte Fehlermeldung erläutern, wie der Fehler behoben werden kann. Wenn Sie aus irgendeinem Grund keinen Zugriff auf die Fehlermeldungsdetails haben, stellen Sie folgendes sicher:

• Das von Ihnen verwendete SAS- oder andere Sicherheitstoken ist nicht abgelaufen.
• Für die X.509-Zertifikatauthentifizierung ist das Gerätezertifikat oder das dem Gerät zugeordnete Zertifizierungsstellenzertifikat nicht abgelaufen. Informationen zum Registrieren von X.509-Zertifizierungsstellenzertifikaten mit IoT Hub finden Sie im Lernprogramm: Erstellen und Hochladen von Zertifikaten für Tests.
• Bei der X.509-Zertifikatfingerabdruckauthentifizierung wird der Fingerabdruck des Gerätezertifikats bei IoT Hub registriert.
• Die Autorisierungsberechtigungen sind korrekt für das von Ihnen verwendete Protokoll formuliert. Weitere Informationen finden Sie unter Steuern des Zugriffs auf IoT Hub mithilfe der Microsoft Entra-ID.
• Die verwendete Autorisierungsregel verfügt über die Berechtigung für den angeforderten Vorgang.
• Für die letzten Fehlermeldungen, die mit "Prinzipal..." beginnen, kann dieser Fehler behoben werden, indem dem Benutzer die richtige Stufe der Azure RBAC-Berechtigung zugewiesen wird. Beispielsweise kann ein Besitzer im IoT Hub die Rolle "IoT Hub Data Owner" zuweisen, die alle Berechtigungen erteilt. Nutzen Sie diese Rolle, um das Problem der fehlenden Berechtigung zu beheben.

403002 IoT Hub-Kontingent überschritten

Möglicherweise schlagen Anforderungen an IoT Hub mit dem Fehler 403002 IoTHubQuotaExceeded fehl. Und im Azure-Portal wird die IoT-Hubgeräteliste nicht geladen.

Dieser Fehler tritt in der Regel auf, wenn das tägliche Nachrichtenkontingent für den IoT-Hub überschritten wird. So beheben Sie diesen Fehler:

• Aktualisieren oder erhöhen Sie die Anzahl der Einheiten auf dem IoT-Hub , oder warten Sie auf den nächsten UTC-Tag, bis das tägliche Kontingent aktualisiert wird.
• Informationen dazu, wie Vorgänge zum Kontingent gezählt werden, z. B. Zwillingsabfragen und Direkte Methoden, finden Sie im Abschnitt "Gebühren pro Vorgang" der Azure IoT Hub-Abrechnungsinformationen.
• Um die Überwachung für die tägliche Kontingentnutzung einzurichten, richten Sie eine Warnung mit der Metrik "Gesamtzahl der verwendeten Nachrichten" ein. Schrittweise Anleitungen finden Sie im Abschnitt "Einrichten von Metriken " des Lernprogramms: Einrichten und Verwenden von Metriken und Protokollen mit einem IoT-Hub.

Ein Massenimportauftrag gibt diesen Fehler möglicherweise auch zurück, wenn die Anzahl der Geräte, die bei Ihrem IoT-Hub registriert sind, das Kontingentlimit für einen IoT-Hub annähert oder überschreitet. Weitere Informationen finden Sie im Abschnitt Problembehandlung bei Importaufträgen im Bereich Importieren und Exportieren von IoT Hub-Geräteidentitäten als Massenauftrag.

403004 Maximale Warteschlangentiefe des Geräts überschritten

Wenn Sie versuchen, eine Cloud-to-Device-Nachricht zu senden, wird möglicherweise angezeigt, dass die Anforderung mit dem Fehler 403004 oder DeviceMaximumQueueDepthExceeded fehlschlägt.

Die zugrunde liegende Ursache dieses Fehlers besteht darin, dass die Anzahl der für das Gerät abgefragten Nachrichten den Warteschlangengrenzwert überschreitet.

Der wahrscheinlichste Grund, warum Sie auf dieses Limit stoßen, ist, dass Sie HTTPS verwenden, um die Nachricht zu empfangen, was zu einer kontinuierlichen Abfrage mithilfe von ReceiveAsync führt, wodurch IoT Hub die Anfrage drosselt.

Das unterstützte Muster für Cloud-zu-Gerät-Nachrichten mit HTTPS ist zeitweise verbundene Geräte, die selten nach Nachrichten suchen (weniger als alle 25 Minuten). Um die Wahrscheinlichkeit zu verringern, dass der Warteschlangengrenzwert erreicht wird, wechseln Sie für Nachrichten in der Cloud zu AMQP oder MQTT.

Alternativ können Sie die Logik auf der Geräteseite verbessern, um die Nachrichten in der Warteschlange schnell abzuschließen, abzulehnen oder aufzugeben, die Lebensdauer zu verkürzen oder weniger Nachrichten zu senden. Weitere Informationen finden Sie im Abschnitt "Nachrichtenablauf (Lebensdauer)" unter Grundlagen des Cloud-zu-Gerät-Messaging von einem IoT-Hub.

Schließlich sollten Sie regelmäßig die Purge Queue API verwenden, um ausstehende Nachrichten zu bereinigen, bevor der Grenzwert erreicht wird.

403006 Grenzwert für den maximalen aktiven Dateiupload des Geräts überschritten

Möglicherweise wird angezeigt, dass Ihre Dateiuploadanforderung mit dem Fehlercode 403006 DeviceMaximumActiveFileUploadLimitExceeded fehlschlägt und eine Meldung "Anzahl der aktiven Dateiuploadanforderungen darf 10 nicht überschreiten".

Dieser Fehler tritt auf, da jeder Geräteclient für gleichzeitige Dateiuploads eingeschränkt ist. Sie können den Grenzwert ganz einfach überschreiten, wenn Ihr Gerät IoT Hub nicht benachrichtigt, wenn Dateiuploads abgeschlossen sind. Ein unzuverlässiges geräteseitiges Netzwerk verursacht dieses Problem häufig.

Um diesen Fehler zu beheben, stellen Sie sicher, dass das Gerät die Vervollständigung des IoT Hub-Datei-Uploads umgehend melden kann. Versuchen Sie dann, die SAS-Token-TTL für die Konfiguration des Dateiuploads zu reduzieren.

404001 Gerät nicht gefunden

Während einer C2D-Kommunikation (Cloud-to-Device), z. B. C2D-Nachricht, Twin Update oder direct-Methode, können Sie feststellen, dass der Vorgang mit einem Fehler 404001 DeviceNotFound fehlschlägt.

Fehler beim Vorgang, da IoT Hub das Gerät nicht finden kann. Das Gerät ist entweder nicht registriert oder deaktiviert.

Um diesen Fehler zu beheben, registrieren Sie die verwendete Geräte-ID, und versuchen Sie es dann erneut.

404103 Gerät nicht online

Es kann sein, dass eine direkte Methode an ein Gerät mit dem Fehler 404103 DeviceNotOnline fehlschlägt, selbst wenn das Gerät online ist.

Wenn Sie wissen, dass das Gerät online ist und dennoch den Fehler erhält, ist der Fehler wahrscheinlich aufgetreten, da der direkte Methodenrückruf nicht auf dem Gerät registriert ist.

Weitere Informationen zum ordnungsgemäßen Konfigurieren Ihres Geräts für direkte Methodenrückrufe finden Sie im Abschnitt "Handle a direct method on a device" im Dokument Handle a direct method on a device.

404104 Geräteverbindung aus der Ferne geschlossen

Möglicherweise stellen Sie fest, dass Geräte in regelmäßigen Abständen (z. B. alle 65 Minuten) die Verbindung trennen, und in den IoT Hub-Ressourcenprotokollen wird die Meldung 404104 DeviceConnectionClosedRemotely angezeigt. Manchmal sehen Sie auch 401003 IoTHubUnauthorized und ein erfolgreiches Geräteverbindungsereignis weniger als eine Minute später.

Die Geräteverbindung wird nach dem Zufallsprinzip getrennt und in den IoT Hub-Ressourcenprotokollen wird die Meldung 404104 DeviceConnectionClosedRemotely angezeigt.

Die Verbindung vieler Geräte wird auf einmal getrennt, die Metrik Verbundene Geräte (connectedDeviceCount) fällt ab und in den Azure Monitor-Protokollen treten mehr Meldungen des Typs 404104 DeviceConnectionClosedRemotely und interne 500xxx-Fehler als üblich auf.

Dieser Fehler kann auftreten, da das SAS-Token, das zum Herstellen einer Verbindung mit IoT Hub verwendet wird , abgelaufen ist, wodurch IoT Hub das Gerät trennt. Die Verbindung wird erneut hergestellt, wenn das Gerät das Token aktualisiert. Beispielsweise läuft das SAS-Token standardmäßig jede Stunde für das C-SDK ab, was zu häufigen Unterbrechungen führen kann. Weitere Informationen finden Sie unter 401003 IoTHubUnauthorized.

Zu den anderen Möglichkeiten gehören:

• Das Gerät hat die zugrunde liegende Netzwerkkonnektivität länger als das MQTT keep-alive verloren, was zu einem Remote-Leerlauftimeout führt. Die Einstellung für das MQTT-Keep-Alive kann bei jedem Gerät unterschiedlich sein.
• Das Gerät hat eine Zurücksetzung auf TCP/IP-Ebene gesendet, aber keine Anwendungsebene MQTT DISCONNECT. Grundsätzlich hat das Gerät die zugrunde liegende Socketverbindung abrupt geschlossen. Manchmal können Fehler in älteren Versionen des Azure IoT SDK dieses Problem verursachen.
• Die geräteseitige Anwendung ist abgestürzt.

Oder ioT Hub hat möglicherweise ein vorübergehendes Problem. Weitere Informationen finden Sie unter 500xxx Interne Fehler.

So beheben Sie diesen Fehler:

• Lesen Sie die Anleitung für Fehler 401003 IoTHubUnauthorized.
• Stellen Sie sicher, dass das Gerät über eine gute Verbindung zum IoT Hub verfügt, indem Sie die Verbindung testen. Wenn das Netzwerk unzuverlässig oder zeitweise ist, wird nicht empfohlen, den Keep-Alive-Wert zu erhöhen, da die Erkennung (z. B. über Azure Monitor-Warnungen) länger dauern kann.
• Verwenden Sie die neuesten Versionen der Azure IoT Hub-SDKs.
• Sehen Sie sich die Anleitung für 500xxx interne Fehler an.

409001 Gerät ist bereits vorhanden.

Wenn Sie versuchen, ein Gerät im IoT Hub zu registrieren, wird möglicherweise angezeigt, dass die Anforderung mit dem Fehler 409001 DeviceAlreadyExists fehlschlägt.

Dieser Fehler tritt auf, da bereits ein Gerät mit derselben Geräte-ID im IoT-Hub vorhanden ist.

Verwenden Sie zum Beheben dieses Fehlers eine andere Geräte-ID, und versuchen Sie es erneut.

409002 Konflikt bei der Erstellung von Links

Möglicherweise wird der Fehler 409002 LinkCreationConflict in Protokollen zusammen mit einer Geräteverbindungstrennung oder einem Ausfall von Cloud-zu-Gerät-Nachrichten angezeigt.

Im Allgemeinen tritt dieser Fehler auf, wenn IoT Hub erkennt, dass ein Client mehr als eine Verbindung hat. Wenn eine neue Verbindungsanforderung für ein Gerät mit einer vorhandenen Verbindung eingeht, schließt IoT Hub die vorhandene Verbindung mit diesem Fehler.

Im häufigsten Fall führt ein separates Problem (z. B. 404104 DeviceConnectionClosedRemotely) dazu, dass die Verbindung des Geräts getrennt wird. Das Gerät versucht, die Verbindung sofort wiederherzustellen, aber IoT Hub hält das Gerät weiterhin für verbunden. IoT Hub schließt die vorherige Verbindung und protokolliert diesen Fehler.

Oder fehlerhafte geräteseitige Logik bewirkt, dass das Gerät die Verbindung herstellen kann, wenn bereits eine geöffnet ist.

Um diesen Fehler zu beheben, suchen Sie nach anderen Fehlern in den Protokollen, die Sie beheben können, da dieser Fehler in der Regel als Nebeneffekt eines anderen vorübergehenden Problems angezeigt wird. Stellen Sie andernfalls sicher, dass Sie nur dann eine neue Verbindungsanforderung ausgeben, wenn die Verbindung abfällt.

412002 Gerätenachrichtensperre verloren

Wenn Sie versuchen, eine Cloud-to-Device-Nachricht zu senden, wird möglicherweise angezeigt, dass die Anforderung mit dem Fehler 412002 DeviceMessageLockLost fehlschlägt.

Dieser Fehler tritt auf, da ein Gerät eine Cloud-zu-Gerät-Nachricht aus der Warteschlange empfängt (zum Beispiel mit ReceiveAsync()), IoT Hub die Nachricht für eine Sperrtimeoutdauer von einer Minute sperrt. Wenn das Gerät versucht, die Nachricht nach Ablauf des Sperrzeitlimits abzuschließen, löst IoT Hub diese Ausnahme aus.

Wenn IoT Hub die Benachrichtigung nicht innerhalb der einminütigen Sperrzeit erhält, wird die Nachricht wieder in den Status Enqueued zurückgesetzt. Das Gerät kann versuchen, die Nachricht erneut zu empfangen. Um zu verhindern, dass der Fehler in Zukunft auftritt, implementieren Sie geräteseitige Logik, um die Nachricht innerhalb einer Minute nach dem Empfang der Nachricht abzuschließen. Dieses einminütige Timeout kann nicht geändert werden.

429xxx-Drosselungsfehler

Möglicherweise sehen Sie, dass Ihre Anforderungen an IoT Hub mit einem Fehler fehlschlagen, der mit 429 beginnt, z. B.:

• 429000 – GenericTooManyRequests
• 429001 – ThrottlingException: Drosselungsgrenzwerte werden für den angeforderten Vorgang überschritten.
• 429002 - ThrottleBacklogLimitExceededed: Die Anzahl der Anforderungen, die sich aufgrund der Drosselung im Backlog befinden, hat den Backlog-Grenzwert überschritten.
• 429003 – ThrottlingBacklogTimeout: Anforderungen, die aufgrund von Drosselung zurückgestellt wurden, haben beim Warten in der Backlogwarteschlange ein Timeout erfahren.
• 429004 – ThrottlingMaxActiveJobCountExceeded
• 429005 – DeviceThrottlingLimitExceeded

Sie können 429001 nur über Azure Monitor unter der Metrik Anzahl der Drosselungsfehler überwachen. Derzeit verfügen die anderen Drosselungsfehler nicht über eine zugeordnete Metrik, werden aber in den Protokollen erfasst.

Um diese Fehler zu beheben, überprüfen Sie, ob Sie den Einschränkungsgrenzwert erreicht haben, indem Sie die Metrik "Senden von Telemetrienachrichten" mit den zuvor angegebenen Grenzwerten vergleichen. Sie können auch die Metrik "Anzahl der Drosselungsfehler " überprüfen. Informationen zu diesen Metriken finden Sie unter Geräte-Telemetriemetriken. Informationen zur Verwendung von Metriken zur Überwachung Ihres IoT-Hubs finden Sie unter "Überwachen von Azure IoT Hub".

IoT Hub gibt 429001 zurück – ThrottlingException erst, nachdem der Grenzwert für zu lange Zeit verletzt wurde. Diese Verzögerung erfolgt, damit Ihre Nachrichten nicht verworfen werden, wenn Ihr IoT-Hub Burstdatenverkehr erhält. In der Zwischenzeit verarbeitet IoT Hub die Nachrichten mit der Drosselungsrate, die langsam sein kann, wenn zu viel Datenverkehr im Backlog vorhanden ist. Weitere Informationen finden Sie im Abschnitt Traffic Shaping von IoT Hub-Kontingente und -Drosselung.

Erwägen Sie, Ihre IoT Hub-Instanz zentral hochzuskalieren, wenn Sie die Kontingent- oder Drosselungslimits erreichen.

500xxx Interne Fehler

Möglicherweise wird angezeigt, dass Ihre Anforderung an IoT Hub mit einem Fehler fehlschlägt, der mit 500 und/oder einer Art von "Serverfehler" beginnt. Einige Möglichkeiten sind:

• 500001 ServerError: IoT Hub ist ein serverseitiges Problem aufgetreten.

• 500008 GenericTimeout: IoT Hub konnte die Verbindungsanforderung vor dem Timeout nicht abschließen.

• ServiceUnavailable (kein Fehlercode):IoT Hub hat einen internen Fehler festgestellt.

• InternalServerError (kein Fehlercode):IoT Hub hat einen internen Fehler festgestellt.

Es kann viele Ursachen für eine 500xxx-Fehlerantwort geben. In allen Fällen ist das Problem wahrscheinlich vorübergehend. Während das IoT Hub-Team hart arbeitet, um die SLA aufrechtzuerhalten, können kleine Teilmengen von IoT Hub-Knoten gelegentlich vorübergehende Fehler auftreten. Wenn Ihr Gerät versucht, eine Verbindung mit einem Knoten herzustellen, der Probleme aufweist, wird dieser Fehler angezeigt.

Um 500xxx-Fehler zu beheben, versuchen Sie es erneut vom Gerät aus. Um Wiederholungen automatisch zu verwalten, stellen Sie sicher, dass Sie die neueste Version der Azure IoT Hub-SDKs verwenden. Weitere Informationen zu bewährten Methoden für die vorübergehende Fehlerbehandlung und Wiederholungen finden Sie unter Vorübergehende Fehlerbehandlung.

Wenn das Problem weiterhin besteht, überprüfen Sie den Ressourcenstatus und den Azure-Status , um festzustellen, ob ioT Hub ein bekanntes Problem aufweist. Sie können auch die manuelle Failoverfunktion verwenden.

Wenn keine bekannten Probleme auftreten und das Problem weiterhin besteht, wenden Sie sich an den Support , um weitere Untersuchungen zu erhalten.

503003 Partition nicht gefunden

Möglicherweise wird angezeigt, dass Anforderungen an IoT Hub mit dem Fehler 503003 PartitionNotFound fehlschlagen.

Dieser Fehler ist intern für IoT Hub und ist wahrscheinlich vorübergehend. Weitere Informationen finden Sie unter 500xxx Interne Fehler.

Informationen zum Beheben dieses Fehlers finden Sie unter 500xxx Interne Fehler.

504101 Gateway-Timeout

Wenn Sie versuchen, eine direkte Methode von IoT Hub auf ein Gerät aufzurufen, sehen Sie möglicherweise, dass die Anforderung mit dem Fehler 504101 GatewayTimeout fehlschlägt.

Dieser Fehler tritt auf, da bei IoT Hub ein Fehler aufgetreten ist und nicht bestätigt werden konnte, ob die direkte Methode vor dem Timeout abgeschlossen wurde. Oder bei Verwendung einer früheren Version des Azure IoT C#SDK (<1.19.0) kann die AMQP-Verbindung zwischen dem Gerät und dem IoT Hub aufgrund eines Fehlers im Hintergrund gelöscht werden.

Um diesen Fehler zu beheben, führen Sie einen Wiederholungs- oder Upgrade auf die neueste Version des Azure IOT C#-SDKs aus.