Réinitialisation et récupération basées sur le périphérique MB - Pilotes Windows (2023)

La réinitialisation et la récupération basées sur le périphérique haut débit mobile (MB ou MBB) est une technologie de Windows 10, version 1809 et ultérieure qui introduit un mécanisme de récupération de réinitialisation robuste pour les périphériques et les pilotes MBB. Ce mécanisme permet aux appareils MBB d'éviter les pannes qui entraînent un dysfonctionnement, une perte de connectivité ou une absence de réponse aux commandes opérationnelles, ce qui rend finalement l'expérience utilisateur transparente si des erreurs se produisent et réduit le risque de devoir redémarrer le système.

La réinitialisation et la récupération basées sur l'appareil peuvent être mises en œuvre avec ou sans dépendances de micrologiciel. Les partenaires IHV ou OEM peuvent étendre les mécanismes de réinitialisation basés sur le logiciel disponibles sur tous les PC Windows avec des mécanismes de réinitialisation pris en charge au niveau de l'appareil ou du micrologiciel pour augmenter le taux de réussite de la récupération.

Présentation de l'architecture de réinitialisation et de récupération basée sur les périphériques MB

Le service Windows MBB initialise et contrôle les appareils cellulaires à l'aide de la normeModèle d'interface large bande mobile(MBIM), qui est construite au-dessus du transport USB étendant les spécifications NCM. Chaque commande envoyée au périphérique IHV est envoyée en tant que commande MBIM via le pilote de classe Windows MBB de la boîte de réception. Une fois que le modem cellulaire est initialisé à l'aide du protocole d'échange MBIM, le chemin de données peut commencer entre l'hôte, le modem et le réseau. Tous les contrôles supplémentaires envoyés au dispositif cellulaire continuent via l'échange de protocole MBIM en parallèle.

Un certain nombre d'échecs peuvent se produire à la fois sur le chemin de contrôle MBIM et sur le chemin de données. Dans les versions de Windows antérieures à Windows 10, version 1809, un mécanisme de gestion des erreurs simple est intégré. Chaque fois qu'une commande MBIM est envoyée et que l'appareil ne répond plus, le mécanisme tente de réinitialiser l'appareil en envoyant une commande de réinitialisation MBIM. Cependant, étant donné que l'échec est souvent dû à une interface MBIM qui ne répond pas, cette réinitialisation ne fonctionne pas toujours. De plus, le mécanisme ne résout pas les autres défaillances susceptibles de se produire, telles que la perte de connectivité due à des défaillances du chemin de données.

MB Device-based Reset and Recovery introduit un cadre centralisé pour détecter un plus grand nombre de pannes et coordonne la récupération avec un ensemble de réinitialisations à impact progressif. Si l'appareil prend en charge la réinitialisation au niveau de l'appareil, MB Device-based Reset and Recovery intégrera les réinitialisations au niveau de l'appareil une fois toutes les réinitialisations logicielles épuisées. Le cadre de réinitialisation et de récupération redéfinit et remplace le mécanisme de réinitialisation existant basé sur la réactivité des commandes MBIM.

MB Device-based Reset and Recovery détecte et tente de remédier aux types de pannes suivants :

Certaines défaillances ne sont pas exploitables du point de vue de la récupération, y compris, mais sans s'y limiter :

• Problèmes liés au provisionnement ou à l'activation, tels que des paramètres COSA manquants ou un refus de service initié par MO
• Problèmes de chemin de contrôle dus à un échec d'initialisation du pilote (lié à l'alimentation ou au matériel) ou à des bogues logiciels

Cependant, une fois qu'une défaillance actionnable est détectée, la réinitialisation et la récupération basées sur le périphérique MB tentent les mécanismes de réinitialisation suivants. Les options de réinitialisation sont répertoriées dans l'ordre d'exécution de Windows, du moins au plus impactant.

Les options de réinitialisation basées sur le logiciel, dans le tableau suivant, sont disponibles sur tous les appareils Windows 10, version 1809 MBB et peuvent être désactivées ou configurées par les partenaires OEM.

Les options de réinitialisation basées sur l'appareil suivantes sont activées par les OEM avec des capacités d'appareil/micrologiciel MBB.

L'ordre de récupération est modifié et, dans certains cas, certains mécanismes de réinitialisation sont complètement contournés, pour certains types de pannes. Par exemple, si un délai d'attente de commande se produit lors du basculement en mode avion, le système d'exploitation ne bascule pas en mode avion pour le réparer. Si le périphérique MBB ne répond à aucune commande MBIM, le système d'exploitation engagera directement les mécanismes de réinitialisation basés sur le périphérique.

Pour les pilotes clients UDE qui activent une fonction MBIM, Windows 10, version 1809 contient une nouvelle API qui peut être utilisée pour demander une réinitialisation chaque fois que le pilote client UDECx détecte une erreur. La section suivante décrit ces nouveaux mécanismes de réinitialisation basés sur les périphériques, notamment la réinitialisation FLDR, PLDR et UDECx pour PCI.

Réinitialisations basées sur l'appareil

Réinitialisation de l'appareil au niveau de la fonction (FLDR)

La réinitialisation de l'appareil au niveau des fonctions est la réinitialisation basée sur l'appareil la plus légère en termes d'impact sur le système. Cela se produit à l'intérieur de l'appareil et n'est pas visible pour les autres appareils, et l'appareil reste connecté au bus tout au long de la réinitialisation et revient à un état valide (en d'autres termes, un état initial) après le processus. Cela peut être fourni par le pilote de bus ou par le micrologiciel. Le pilote de bus implémente un gestionnaire FLDR si la spécification de bus définit un mécanisme de réinitialisation intrabande qui correspond à l'exigence. Les auteurs de micrologiciels peuvent remplacer un FLDR défini par le bus par leur propre implémentation de FLDR qui utilise des signaux hors bande, tels que la ligne de réinitialisation ou le basculement de l'alimentation, tout en respectant les exigences de FLDR.

Réinitialisation de l'appareil au niveau de la plate-forme (PLDR)

La réinitialisation de l'appareil au niveau de la plate-forme est destinée aux cas où FLDR ne peut pas être utilisé, ou en tant que complément de dernier recours à FLDR. Ce mécanisme de réinitialisation entraîne le signalement de l'appareil comme absent du bus (lors d'un cycle d'alimentation, par exemple) ou affecte plusieurs appareils (tels qu'un rail d'alimentation partagé ou une ligne de réinitialisation entre les appareils). La méthode de réinitialisation est spécifiée dans la table ACPI, qui peut être implémentée en basculant une ligne de réinitialisation dédiée ou en redémarrant la ressource d'alimentation D3. Lorsque PLDR est exécuté, le système d'exploitation démonte et reconstruit les piles de tous les appareils concernés pour s'assurer que tout démarre à partir d'un état vierge.

Réinitialiser la récupération pour les appareils UDE

Pour les pilotes clients UDE qui activent une fonction MBIM, Windows 10, version 1809 inclut une API qui peut être utilisée pour demander une réinitialisation chaque fois que le pilote client UDECx détecte une erreur. Le pilote client demande une réinitialisation en appelant une nouvelle méthode,UdecxWdfDeviceNeedsReset, en spécifiant le type de réinitialisation qu'il souhaite que l'UDECx tente pour le périphérique (si pris en charge). Ces types de réinitialisation sontPlatformLevelDeviceResetetFunctionLevelDeviceResetet sont des valeurs deUDECX_WDF_DEVICE_RESET_TYPEénumération. Une fois qu'une réinitialisation est initiée, UDECx appelle le piloteEVT_UDECX_WDF_DEVICE_RESETfonction de rappel et garantit qu'aucun autre rappel n'est invoqué pendant ce processus. Le pilote client est censé effectuer toutes les opérations liées à la réinitialisation, telles que la libération de toutes les ressources, puis signaler la fin de la réinitialisation en appelantUdecxWdfDeviceResetComplete.

L'organigramme suivant illustre le processus de réinitialisation de l'appareil UDE.

Déclencheurs RnR

Le service WWAN organise les défaillances exploitables en déclencheurs RnR :

1. Mauvaise connectivité
2. Ensemble d'état radio/échecs de requête/expirations de délai
3. Délais d'attente de requête OID consécutifs
4. Échecs d'initialisation

Déclencheur RnR #1 - Mauvaise connectivité

• Mauvaise connectivité
• Connectivité Internet limitée
• Connexion Internet perdue
• Itinéraires non reçus correctement
• Routes inaccessibles
• Passerelle morte
• Échec de la requête DNS

WCM détecte sur la base de diverses sources (NCSI, etc.).

WCM publie WNF_WCM_INTERFACE_CONNECTION_STATE.

struct WCM_WNF_INTERFACE_CONNECTION_STATE_INFO{ GUID InterfaceGuid ; WCM_MEDIA_TYPE MediaType = wcm_media_unknown ; // ConnectionState est l'une des valeurs WCM_WNF_INTERFACE_CONNECTIVITY_STATE_* DWORD ConnectionState = 0; // TimeInBadStateMs suit la durée pendant laquelle une connexion est dans un état incorrect // Elle sera réinitialisée à zéro lorsqu'elle est dans un état correct DWORD TimeInBadStateMs = 0 ; // ConnectivityTriggers est un masque binaire de drapeaux WCM_WNF_INTERFACE_CONNECTIVITY_TRIGGER_* DWORD ConnectivityTriggers = 0 ; // fWasConnectedGood sera TRUE si une connexion est en bon état pendant la durée de vie d'une connexion L2 // Une fois défini sur TRUE, il ne deviendra jamais FALSE jusqu'à ce que l'interface se déconnecte BOOLEAN fWasConnectedGood = FALSE; // Lors du traitement du WNF, parcourez le tableau des structures WCM_WNF_INTERFACE_CONNECTION_STATE_INFO // jusqu'à ce que vous atteigniez la structure avec afLastArrayValues ​​== TRUE BOOLEAN fLastArrayValue = TRUE;};

Processus de récupération:

• Réinitialiser le contexte PDP jusqu'à trois fois (voir le diagramme de transition FSM)
• Basculer APM une fois
• PnP désactiver et activer le périphérique MBB une fois
• Invoquer FLDR une fois si pris en charge
• Invoquer PLDR une fois si pris en charge

Le processus s'arrête dès que la connectivité L3 est bonne.

Vérification du résultat : la connectivité L3 est bonne.

Déclencheur RnR #2 - Échec de l'ensemble/de la requête de l'état radio ou expiration du délai

• Aucune réponse ou réponse d'échec pour le réglage ou l'interrogation de l'état de la radio.
• OID_WWAN_RADIO_STATE définit ou interroge les requêtes.
• Ne devrait jamais arriver.
• Une fois que cela se produit, le système d'exploitation et le modem peuvent se retrouver dans un état incohérent.
• Indique un ou des problèmes graves dans le modem.
• CWwanExecutor le détecte et signale en interne à CWwanResetRecovery.

Processus de récupération:

• Invoquer PLDR si pris en charge
• Sinon, appelez PnP désactiver/activer

Vérification du résultat : envoyez la requête OID_WWAN_RADIO_STATE et vérifiez la réponse.

Déclencheur RnR #3 - Délai d'expiration des requêtes OID consécutives

• TXM chronomètre toutes les requêtes OID en attente et attend des réponses pour chacune.
• Si un nombre « configurable » de requêtes OID consécutives ne reçoivent aucune réponse à temps, TXM le détecte et le signale en interne à CWwanResetRecovery.
• Les OID peuvent être regroupés en groupes de latence élevée/moyenne/faible :
  • Les requêtes OID qui n'ont aucune interaction avec MO auront une latence plus faible.
  • Les requêtes OID qui entraînent une interaction avec MO auront une latence moyenne.
  • Requête d'activation/désactivation OID_WWAN_CONNECT : ~180 secondes.

Processus de récupération:

• Invoquer PLDR si pris en charge
• Sinon, appelez PnP désactiver/activer

Vérification du résultat : envoyez la requête OID_WWAN_RADIO_STATE et vérifiez la réponse.

RnR Trigger #4 - Échecs d'initialisation

• Délai d'expiration des caps de l'appareil ou de la requête capsEx de l'appareil lors de l'initialisation à l'arrivée de l'appareil MB
• CWwanManager le détecte et agit en conséquence

Processus de récupération:

• Invoquer PLDR si pris en charge
• Sinon, appelez PnP désactiver/activer

Vérification du résultat : aucune

Après la désactivation/activation de PLDR ou PnP, l'appareil part puis revient. L'initialisation à l'arrivée suit.

Flux primaires

RnR pour mauvaise connectivité

PLDR pour panne de groupe d'alimentation radio

Désactiver/activer PnP pour l'échec de l'état de la radio

PLDR pour les délais d'expiration des requêtes OID consécutives

Désactiver/activer PnP pour les délais d'expiration des demandes OID consécutives

PLDR en cas d'échec d'initialisation

Désactiver/activer PnP en cas d'échec d'initialisation

Configuration requise pour la réinitialisation et la récupération basées sur un périphérique MB

Exigences pour FLDR

Pour prendre en charge FLDR sur un périphérique, à l'intérieur de la portée Device (), il doit y avoir un_RSTméthode définie. Lorsqu'elle est exécutée, la méthode doit réinitialiser uniquement cet appareil et ne doit pas toucher un autre appareil. L'appareil doit également rester sur le bus, connecté.

Device(PCI0){Device(USB0){Name(_ADR, 0x1d0000)Name(_S4D, 0x2)Name(_S3D, 0x2)…Method(_RST, 0x0, NotSerialized){/// Effectuez la réinitialisation du périphérique USB0// }}}

Conditions requises pour le PLDR

Dans PLDR, les appareils qui sont affectés par la réinitialisation d'un autre appareil sont exprimés comme partageant unPowerResourcepour la réinitialisation. Les appareils déclarent leur dépendance auPowerResourcepour la réinitialisation, et quePowerResourcemet en œuvre le_RSTméthode.

Device(PCI0){PowerResource(URST, 0x5, 0x0){//// Méthodes factices _ON et _OFF. Toutes les ressources d'alimentation doivent avoir ces // deux définis.// Method(_ON, 0x0, NotSerialized){}Method(_OFF, 0x0, NotSerialized){}Method(_RST, 0x0, NotSerialized){/// Effectuer la réinitialisation du Appareils USB0 et USB1//}}Appareil (USB0){Nom(_ADR, 0x1d0000)Nom(_S4D, 0x2)Nom(_S3D, 0x2)…Nom(_PRR, Package(0x1) { ^URST })}Appareil(USB1) {Nom(_ADR, 0x1d0001)Nom(_S4D, 0x2)Nom(_S3D, 0x2)…Nom(_PRR, Colis(0x1) { ^URST })}}

Alternativement, PLDR peut être réalisé en plaçant l'appareil dans l'état d'alimentation D3Cold et en le ramenant à D0, essentiellement en redémarrant l'appareil. Dans ce cas, ayant_PR3déclaré dans la portée de l'appareil est suffisant pour prendre en charge PLDR. ACPI utilisera_PR3pour déterminer les dépendances de réinitialisation entre les appareils si non_PRRest référencé dans la portée de l'appareil. Pour plus d'informations, voirRéinitialiser et récupérer un appareil.

Exemple de journal

NTS]Événement de service WWAN : [Info] WwanTimerWrapper::StartTimer : Minuterie (ID = 0) Début terminé[0]0E98.34E4::11/27/2019-05:37:55.622 [Microsoft-Windows-WWAN-SVC- ÉVÉNEMENTS]Événement de service WWAN : [Info] WwanTxmEvaluateArmTimer : temporisateur TXM armé pendant 60 secondes 55.622 [Microsoft-Windows-WWAN-SVC-EVENTS]Événement de service WWAN : [Info] _sendReq : ASYNC OID (pTx->handle : 00000000000000B0 Code : 1) envoyé[0]0E98.34E4::11/27/2019-05 :37:55.622 [Microsoft-Windows-WWAN-SVC-EVENTS]Événement de service WWAN : [Info] CWwanExecutor::RegWriteStoredRadioState : Essayez de définir la sous-clé sur 0x0 pour l'interface ArrivalRadioState : {{8a664721-db25-4157-8395-5d21e0560fa4} }[0]0E98.34E4::11/27/2019-05:37:55.623 [Microsoft-Windows-WWAN-SVC-EVENTS]Événement de service WWAN : [Info] CWwanResetRecovery::EvaluateAndTryHighImpactRnRMethod : Tentative d'éteindre la radio via MBB (reqId 0x10c) : ID de demande 0x1 étape précédente 0 APMToggling 0 ; PnPDésactivation 0 ; PLDR 0 ; Interface FLDR 0 : {{8a664721-db25-4157-8395-5d21e0560fa4}}[0]0E98.34E4::11/27/2019-05:37:55.623 [Microsoft-Windows-WWAN-SVC-EVENTS]Événement de service WWAN : [Info] WwanTimerWrapper::StartTimer : Minuterie (ID = 6) Début terminé[0]0E98.34E4::11/27/2019-05:37:55.623 [Microsoft-Windows-WWAN-SVC-EVENTS]Événement de service WWAN : [Info] CWwanResetRecovery::fsmEventHandler : sortie avec état : 7, événement : 4, étape RnR : 2 RnR puissant : 0 Interface : {{8a664721-db25-4157-8395-5d21e0560fa4}}

Détection de blocage MB

UDECX_WDF_DEVICE_RESET_TYPE

UdecxWdfDeviceNeedsReset

EVT_UDECX_WDF_DEVICE_RESET

UdecxWdfDeviceResetComplete