次の方法で共有

Bluetooth無線リセットと回復

  • [アーティクル]

Bluetooth無線のリセットと回復は、Windows 10 バージョン 1803 以降のテクノロジであり、Bluetooth 無線の堅牢なリセットと回復メカニズムが導入されています。 このメカニズムにより、Bluetooth 無線は、誤動作、接続の喪失、または操作コマンドへの応答不能につながるハードウェア障害から回復できます。 目標は、無線を自動的に回復し、ユーザー エクスペリエンスをシームレスにし、システムの再起動を必要とする可能性を減らすことです。

Bluetooth 無線のリセットと回復は、ファームウェアの依存関係の有無にかかわらず実装できます。 ハードウェア パートナーは、サポートされているデバイス レベルまたはファームウェア レベルのリセット メカニズムを備えたすべての Windows PC で使用できるソフトウェア ベースのリセット メカニズムを拡張して、回復が成功する可能性を高めることができます。

重要

このトピックは開発者向けです。 Bluetooth の問題が発生している場合は、次を参照してください Windows 10 の Bluetooth の問題を解決する.

Bluetoothリセットと回復のシナリオ

リセットと回復が開始される問題には、大きく分けて 3 つのカテゴリがあります。

  • バスの列挙の失敗: 無線は、基になるハードウェア エラーの症状である可能性がある、デバイス マネージャーで目に見える障害状態 (黄色のバン) によって示されるように、基になるバス (通常は USB または UART) による列挙または再列挙に失敗します。

  • ドライバーのリストエラー: Bluetooth 無線が障害のある状態です 後に 基礎となるバスによるリストが正常に完了しました。 この失敗状態は、通常、無線のドライバー スタックを構築するときに発生します。 たとえば、フィルターまたはファンクション ドライバーがBluetooth無線デバイス ノードにインストールされている場合などです。 エラーは、ドライバーが 1 つ以上の開始操作中にエラーを検出し、結果として PnP エラーを報告する場合に発生する可能性があります。 このような操作の例としては、デバイスへのファームウェアのダウンロードがあります。

  • 非列挙エラー: デバイスは失敗した状態ではありませんが、ドライバー スタックによって決定される動作ではありません。 これらの障害は列挙経路の外にあり、一般的な重大なトランスポート固有の障害や、致命的なファームウェア エラーなどのデバイス固有の障害である可能性があります。 このような場合は、次のBluetoothリセットと回復のメカニズムが使用されます。

リセットと回復のメカニズム

失敗した状態から回復するにはさまざまな方法がありますが、Bluetooth では標準化された ACPI ベースの回復メカニズムを使用して、無線を動作状態に復元しようとします。

GUID_DEVICE_RESET_INTERFACE_STANDARD リセットの 2 つの水準器を定義します。 リセット メカニズムは内部デバイスでのみ機能するため、ドングルなどの外部からプラグ可能なBluetooth無線はサポートされません。 リセット メカニズムでは、実際にリセットを実行するために、Windows (通常はファンクション ドライバー スタック) と基になるファームウェア (通常は ACPI BIOS) の両方のサポートが必要です。 実際のリセット メカニズムはシステム固有です。

水準器のリセット 実装
関数水準器のデバイス リセット (FLDR) リセット操作は特定のデバイスに制限され、他のデバイスには表示されません。 再列挙はありません。 ファンクション ドライバーは、操作後にハードウェアが元の状態に戻ったと想定する必要があります。 中間状態は保持されません。
プラットフォーム 水準器のデバイス リセット (PLDR) リセット操作は、特定のデバイスと、同じ電源レールまたはリセットラインを介して接続されている他のすべてのデバイスに影響します。 リセット操作により、デバイスがバスに不足していると報告され、再列挙されます。 この種類のリセットは、リソースを共有するすべてのデバイスが元の状態に戻るので、システムに最も影響します。

  • FLDRをサポートするために 詳細については、デバイス スコープ内に __RST メソッドが定義されている必要があります ACPI ファームウェア: 機能水準器のリセット.

  • PLDRをサポートするには で詳しく説明されているように、デバイス スコープの下で __RST または __PR3 メソッドが定義されている必要があります ACPIファームウェア:プラットフォーム水準器のリセット. PR3 メソッドを使用する場合、ACPI は D3Cold 電源サイクル メカニズムを使用してリセットします。D3Cold 電源サイクル メカニズムは、デバイスからの電力の取り外しと復元をエミュレートします。他のデバイスが同じ電源レールを共有している場合は、リセットも行われます。an__RSTメソッドが定義され、_PRR (PowerResource) によって参照されている場合、その PowerResource を使用するすべてのデバイスが影響を受けます。

    • PLDR は内部デバイスでのみ機能するため、ACPI ではそのように宣言する必要があります。 USB デバイスの場合、内部 (ユーザーに表示されない) で統合デバイスに接続できるポートを指定するには、 UPC.PortIsConnectable バイトから0xFFまでおよび the__PLD.UserVisible ビットを0にする。

    • もし_PR3 (D3Cold) メカニズムが PLDR に使用されており、SystemWake や DeviceWake などのシナリオが引き続き動作することを確認します。 名目上、これは、D2 用に定義された適切な電力リソースがあることを意味します。_PR2. 次のテーブルは便利なガイドです:

電源状態 ACPI リソース Behavior
D2 _PR2 この状態のクラス定義の機能低下に必要な電力またはクロック。
D3 ホット (必須) _PR2 サポートされている次の上位の状態 (D2、D1、または D0) と同じリソース。
D3Cold _PR3 デバイスがバスに表示され、バス固有のコマンドに応答するために必要な電源またはクロックのみ。