共用方式為

MB 裝置型重設和復原

行動寬頻 （MB 或 MBB） 裝置型重設和復原是 Windows 10 版本 1809 和更新版本中的技術，為 MBB 裝置和驅動程式引進了強固的重設復原機制。 此機制可讓 MBB 裝置避免導致故障、連線中斷或作命令沒有回應的失敗，最終在發生錯誤時讓用戶體驗順暢，並減少必須重新啟動系統的機會。

可以在有或沒有韌體依賴的情況下實現裝置重設和復原。 IHV 或 OEM 合作夥伴可以擴充所有具有支援裝置或韌體層級重設機制的 Windows 電腦上可用的軟體型重設機制，以提高成功復原的速率。

MB 裝置型重設和復原架構概觀

Windows MBB 服務會使用標準 行動寬頻介面模型 （MBIM） 介面來初始化及控制行動數據裝置，其建置在擴充 NCM 規格的 USB 傳輸之上。 傳送至 IHV 裝置的每個命令都會透過收件匣 Windows MBB 類別驅動程式以 MBIM 命令的形式傳送。 在使用 MBIM 通訊協定交換初始化行動數據機之後，資料路徑即可在主機、行動數據機與網路之間啟動。 傳送至行動數據裝置的任何其他控制項會透過 MBIM 通訊協定交換平行繼續。

MBIM 控制路徑和數據路徑上都可能發生許多失敗。 在 Windows 10 版本 1809 之前的 Windows 版本中，內建簡單的錯誤處理機制。 每當傳送 MBIM 命令且裝置沒有回應時，機制就會傳送 MBIM 重設命令來嘗試重設裝置。 不過，由於失敗通常是因為 MBIM 介面本身無回應，因此重置不一定能夠生效。 此外，機制不會解決其他可能發生的失敗，例如因為數據路徑失敗而導致連線中斷。

MB 裝置型重設和復原引入了一個集中式架構，用於偵測更多種類的故障，並透過一系列逐步加強的重設來協調復原過程。 如果裝置支援裝置層級重設，MB 裝置型重設和復原會在所有軟體型重設用盡之後納入裝置層級重設。 重設和復原架構會重新定義並取代以 MBIM 命令回應性為基礎的現有重設機制。

MB 裝置型重設和復原會偵測並嘗試補救下列類型的失敗：

失敗區域 失敗描述
控制路徑
  • 在 MBIM 通訊協定路徑上偵測到當機條件。 如需當機偵測的詳細資訊，請參閱 MB 當機偵測。
  • 由於 MBB 回應的狀態不正確和/或資訊錯誤而導致失敗。
數據路徑
  • 裝置端失敗導致數據路徑失敗。 例如，端點不會響應數據流量、來自 PHY 的數據損毀等。
  • 數據機/網路端失敗。 例如，網路未回應IP流量、DNS 失敗、封包遺失等。

從恢復的角度來看，有些失敗是無法採取措施的，包括但不限於：

  • 配置或啟用相關問題，例如缺漏 COSA 設定或 MO 發起的服務拒絕
  • 因驅動程式初始化失敗（電源或硬體相關）或軟體錯誤而導致控制路徑問題

不過，偵測到可執行的故障後，MB 裝置型重設和復原將會嘗試下列重設機制。 重設選項會依 Windows 執行的順序列出，從最小到最具影響力。

下表中的軟體重設選項適用於所有 Windows 10 版本 1809 MBB 裝置，且可由 OEM 合作夥伴停用或設定。

重設順序 重設類型 重置機制
1 僅限軟體 停用並啟用 PDP 內容上下文
2 僅限於軟體 切換飛機模式 （APM） ON/OFF
3 僅限軟體 在隨插即用層級啟用/停用裝置

下列裝置型重設選項是由具有 MBB 裝置/韌體功能的 OEM 啟用。

重置序列 重設類型 重設機制
4 裝置型 功能層級裝置重設（FLDR）
5 裝置型 平台層級裝置重設 （PLDR）

復原順序會改變，且對於某些故障類型，在某些情況下，某些重設機制可能會被完全繞過。 例如，如果在切換飛行模式時發生命令逾時，作業系統不會切換飛行模式來修正這種情況。 如果 MBB 裝置未回應任何 MBIM 命令，則 OS 會直接與裝置型重設機制互動。

針對啟用 MBIM 函式的 UDE 用戶端驅動程式，Windows 10 版本 1809 包含新的 API，可在 UDECx 用戶端驅動程式偵測到錯誤時用來要求重設。 下一節說明這些新的裝置型重設機制，包括適用於PCI的FLDR、PLDR和UDECx重設。

裝置型重設

功能層級裝置重設（FLDR）

函式層級的裝置重設是系統影響方面最輕的裝置型重設。 它發生在裝置內，其他裝置看不到，而且裝置會在整個重設期間保持連線到總線，並在程序之後返回有效的狀態（換句話說，初始狀態）。 這可由總線驅動程式或韌體提供。 如果總線規格定義符合需求的頻內重設機制，則總線驅動程式會實作 FLDR 處理程式。 韌體開發者可能會使用自己的 FLDR 實作來覆蓋總線定義的 FLDR，該實作利用頻外訊號，例如重設線路或電源切換，同時仍遵循 FLDR 的要求。 

平台級裝置重設（PLDR）

平臺層級的裝置重設適用於無法使用 FLDR 的情況，或作為 FLDR 的最後補充。 此重設機制會導致裝置被回報為從總線上遺失（例如在電源循環時），或影響多個裝置（例如裝置共用的電源軌或重設線路）。 重設方法是在 ACPI 表中指定，這可實作為切換專用重設線路或重啟 D3 電源資源。 執行 PLDR 時，OS 會卸除並重建所有受影響裝置的堆疊，以確保一切都從原始狀態開始。

重設 UDE 裝置的復原功能

對於啟用 MBIM 函式的 UDE 用戶端驅動程式，Windows 10 版本 1809 包含 API，可在 UDECx 用戶端驅動程式偵測到錯誤時用來要求重設。 用戶端驅動程式會呼叫新的方法來要求重設，UdecxWdfDeviceNeedsReset，並指定它想要 UDECx 嘗試進行裝置的重設類型（如果支持的話）。 這些重設類型是 PlatformLevelDeviceReset 和 FunctionLevelDeviceReset，而且是 UDECX_WDF_DEVICE_RESET_TYPE 列舉的值。 一旦起始重設，UDECx 會叫用驅動程式的 EVT_UDECX_WDF_DEVICE_RESET 回呼函式，並確保在此程式期間不會叫用任何其他回呼。 用戶端驅動程式預期會執行任何重設相關作業，例如釋放任何資源，然後叫用 UdecxWdfDeviceResetComplete 來發出重設完成訊號。

下列流程圖說明 UDE 裝置重設程式。

顯示 UDECx 用戶端驅動程式重設復原流程的圖表。

RnR 觸發程式

WWAN 服務會將可採取動作的失敗整理為 RnR 觸發條件。

  1. 連接不良
  2. 無線電狀態設定/查詢失敗/逾時
  3. 連續 OID 請求逾時
  4. 初始化失敗

RnR 觸發程式 #1 - 連線不良

  • 連線不良
  • 有限的因特網連線能力
  • 因特網聯機中斷
  • 路由未正確接收
  • 無法連線到路由
  • 無效閘道
  • DNS 查詢失敗

WCM 會根據各種來源（NCSI 等）進行偵測。

WCM 會發佈WNF_WCM_INTERFACE_CONNECTION_STATE。

struct WCM_WNF_INTERFACE_CONNECTION_STATE_INFO
{
    GUID InterfaceGuid;
    WCM_MEDIA_TYPE MediaType = wcm_media_unknown;
    // ConnectionState is one of the WCM_WNF_INTERFACE_CONNECTIVITY_STATE_* values
    DWORD ConnectionState = 0;
    // TimeInBadStateMs tracks how long a connection is in a Bad state
    // It will reset back to zero when in a good state
    DWORD TimeInBadStateMs = 0;
    // ConnectivityTriggers is a bitmask of WCM_WNF_INTERFACE_CONNECTIVITY_TRIGGER_* flags
    DWORD ConnectivityTriggers = 0; 
    // fWasConnectedGood will be TRUE if a connection is ever in a good state over the lifetime of an L2 connection
    // Once it is set to TRUE, it will never go FALSE until the interface disconnects
    BOOLEAN fWasConnectedGood = FALSE;
    // When processing the WNF, walk the array of WCM_WNF_INTERFACE_CONNECTION_STATE_INFO structs
    // until you reach the struct with afLastArrayValues == TRUE
    BOOLEAN fLastArrayValue = TRUE;
};

復原程式：

  • 重設 PDP 內容最多三次 （請參閱 FSM 轉換圖表）
  • 切換 APM 一次
  • PnP 停用並啟用 MBB 裝置一次
  • 如果支援，請叫用 FLDR 一次
  • 如果支援，請叫用 PLDR 一次

一旦 L3 連線良好，程式就會停止。

結果的驗證：L3 連線能力良好。

RnR 觸發條件 #2 - 無線電狀態設定/查詢失敗或超時

  • 沒有設定或查詢無線電狀態的回應或失敗回應。
  • OID_WWAN_RADIO_STATE設定或查詢要求。
  • 不應該發生。
  • 一旦發生，OS 和數據機最終可能會處於不一致的狀態。
  • 表示數據機中的嚴重問題。
  • CWwanExecutor 會偵測到它，並在內部向 CWwanResetRecovery 報告。

復原程式：

  • 如果支援，請叫用 PLDR
  • 否則，叫用 PnP 停用/啟用

結果的驗證：傳送OID_WWAN_RADIO_STATE查詢並驗證回應。

RnR 觸發器 #3 - 連續 OID 請求的逾時

  • TXM 會計算所有未處理的 OID 要求的時間，並期望每個要求都能得到回應。
  • 如果「可設定」次數的連續 OID 要求未能及時收到回應，TXM 會偵測到此情況，並在內部程序中向 CWwanResetRecovery 報告。
  • OID 可以分組在高/中/低延遲群組中：
    • 與 MO 沒有互動的 OID 要求將會有較低的延遲。
    • 導致與MO互動的 OID 要求會有中等延遲。
    • OID_WWAN_CONNECT啟用/停用要求：~180 秒。

復原程式：

  • 如果支援，請叫用 PLDR
  • 否則，叫用 PnP 停用/啟用

結果的驗證：傳送OID_WWAN_RADIO_STATE查詢並驗證回應。

RnR 觸發程式 #4 - 初始化失敗

  • 在 MB 裝置抵達時初始化期間逾時裝置上限或裝置 capsEx 查詢
  • CWwanManager 會偵測並採取動作

復原程式：

  • 如果支援，請叫用 PLDR
  • 否則，叫用 PnP 停用/啟用

結果驗證：無

在 PLDR 或 PnP 停用/啟用之後，裝置會離開，然後重新抵達。 抵達後進行初始化。

主要流程

連接不良的 RnR

流程圖，說明連線不良的 RnR 流程。

無線電電源集故障的 PLDR

流程圖，說明無線電電力設定故障的 PLDR 流程。

PnP 無線電狀態設定失敗的停用/啟用

流程圖，說明無線電狀態集失敗的 PnP 程式。

針對連續 OID 請求的逾時 PLDR

流程圖，顯示連續 OID 要求的逾時 PLDR 程式。

PnP 停用/啟用因連續 OID 請求所導致的逾時

流程圖，描述連續 OID 要求的逾時 PnP 程式。

PLDR 初始化失敗

流程圖，展示初始化失敗時的 PLDR 程序。

初始化失敗時的 PnP 停用/啟用

流程圖，顯示初始化失敗的 PnP 程式。

MB 裝置型重設和復原的需求

FLDR 的需求規範

若要在裝置上支援 FLDR，必須在 Device（） 範圍內定義 _RST 方法。 執行時，方法必須只重設該裝置，而且不應該碰另一個裝置。 裝置必須保持連線並停留在總線上。 

Device(PCI0)  
{  
Device(USB0)  
{  
	Name(_ADR, 0x1d0000)  
	Name(_S4D, 0x2)  
	Name(_S3D, 0x2)  
	…  
	Method(_RST, 0x0, NotSerialized)  
	{  
			//  
			// Perform reset of the USB0 device  
			//  
	} 
} 
} 

PLDR 的需求要求

在 PLDR 中，若裝置受其他裝置的重設影響，則會以共享重設識別號 PowerResource 表示。 裝置會宣告其對 PowerResource 的重設相依性，並且 PowerResource 會實作 _RST 方法。 

Device(PCI0)  
{  
PowerResource(URST, 0x5, 0x0)  
{  
	//  
	// Dummy _ON and _OFF methods. All power resources must have these  
	// two defined.  
	// Method(_ON, 0x0, NotSerialized)  
	{  
	}  
	Method(_OFF, 0x0, NotSerialized)  
	{  
	}  
	Method(_RST, 0x0, NotSerialized)  
	{  
			//  
			// Perform reset of the USB0 and USB1 devices  
			//  
	} 
}  
Device(USB0)  
{  
	Name(_ADR, 0x1d0000)  
	Name(_S4D, 0x2)  
	Name(_S3D, 0x2)  
	…  
	Name(_PRR, Package(0x1) { ^URST })  
}  
Device(USB1)  
{  
	Name(_ADR, 0x1d0001)  
	Name(_S4D, 0x2)  
	Name(_S3D, 0x2)  
	…  
	Name(_PRR, Package(0x1) { ^URST })  
} 
} 

或者，通過將裝置置於 D3Cold 電源狀態然後再切換回 D0，基本上是重新啟動裝置來達成 PLDR。 在此情況下，在裝置範圍中宣告 _PR3 就足以支援 PLDR。 如果裝置範圍中未參考任何 _PRR，ACPI 會使用 _PR3 來判斷裝置之間的重設相依性。 如需詳細資訊，請參閱 重設和復原裝置。 

範例記錄檔

NTS]WWAN Service event: [Info] WwanTimerWrapper::StartTimer:  Timer (ID = 0) Start Completed
[0]0E98.34E4::11/27/2019-05:37:55.622 [Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] WwanTxmEvaluateArmTimer: TXM timer armed for 60 seconds Interface: {{8a664721-db25-4157-8395-5d21e0560fa4}}
[0]0E98.34E4::11/27/2019-05:37:55.622 [Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] _sendReq: ASYNC OID (pTx->handle: 00000000000000B0 Code: 1) sent
[0]0E98.34E4::11/27/2019-05:37:55.622 [Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] CWwanExecutor::RegWriteStoredRadioState: Try to set the subkey to 0x0 for ArrivalRadioState Interface: {{8a664721-db25-4157-8395-5d21e0560fa4}}
[0]0E98.34E4::11/27/2019-05:37:55.623 [Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] CWwanResetRecovery::EvaluateAndTryHighImpactRnRMethod:  Attempted to turn off radio via MBB (reqId 0x10c): request ID 0x1 prev stage 0 APMToggling 0; PnPDisabling 0; PLDR 0; FLDR 0 Interface: {{8a664721-db25-4157-8395-5d21e0560fa4}}
[0]0E98.34E4::11/27/2019-05:37:55.623 [Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] WwanTimerWrapper::StartTimer:  Timer (ID = 6) Start Completed
[0]0E98.34E4::11/27/2019-05:37:55.623 [Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] CWwanResetRecovery::fsmEventHandler:  exit with state: 7, event: 4, RnR stage: 2 Potent RnR: 0 Interface: {{8a664721-db25-4157-8395-5d21e0560fa4}}

MB 停止回應偵測

UDECX_WDF_DEVICE_RESET_TYPE

UdecxWdfDeviceNeedsReset

EVT_UDECX_WDF_DEVICE_RESET

UdecxWdfDeviceResetComplete