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 设备的重置和恢复引入了一个集中式框架，用于检测一组较大的故障，并使用一组渐进式影响的重置协调恢复。 如果设备支持设备级重置，则所有基于软件的重置都用完后，基于设备的重置和恢复将合并设备级重置。 重置和恢复框架根据 MBIM 命令响应能力重新定义并替换现有的重置机制。
MB 基于设备的重置和恢复检测并尝试修复以下类型的故障：
| 故障区域 | 失败描述 |
|---|---|
| 控件路径 |
|
| 数据路径 |
|
从恢复的角度来看，某些故障不可操作，包括但不限于：
- 与预配或激活相关的问题，例如缺少 COSA 设置或 MO 发起的服务拒绝
- 由于驱动程序初始化失败 (与电源或硬件相关的) 或软件 bug 而导致的控制路径问题
但是，一旦检测到可操作的故障，基于 MB 设备的重置和恢复将尝试以下重置机制。 重置选项按 Windows 执行的顺序列出，从最低到影响最大。
下表中基于软件的重置选项适用于所有 Windows 10 版本 1809 MBB 设备，OEM patner 可以禁用或配置。
| 重置序列 | 重置类型 | 重置机制 |
|---|---|---|
| 1 | 仅限软件 | 停用并激活 PDP 上下文 |
| 2 | 仅限软件 | (APM) ON/OFF 切换飞行模式 |
| 3 | 仅限 Sofware | 在即插即用 (PnP) 级别启用/禁用设备 |
以下基于设备的重置选项由具有 MBB 设备/固件功能的 OEM 启用。
| 重置序列 | 重置类型 | 重置机制 |
|---|---|---|
| 4 | 基于设备 | 功能级别的设备重置 (FLDR) |
| 5 | 基于设备 | 平台级设备重置 (PLDR) |
对于某些类型的故障，恢复顺序会更改，在某些情况下，某些重置机制被完全绕过。 例如，如果在切换飞行模式时发生命令超时，操作系统不会切换飞行模式来修复它。 如果 MBB 设备不响应任何 MBIM 命令，则 OS 将直接使用基于设备的重置机制。
对于启用 MBIM 函数的 UDE 客户端驱动程序，Windows 10 版本 1809包含一个新的 API，每当 UDECx 客户端驱动程序检测到错误时，该 API 都可用于请求重置。 以下部分介绍这些新的基于设备的重置机制，包括适用于 PCI 的 FLDR、PLDR 和 UDECx 重置。
基于设备的重置
功能级设备重置 (FLDR)
功能级设备重置是系统影响最轻的基于设备的重置。 它发生在设备内部，对其他设备不可见，并且设备在整个重置过程中一直与总线保持连接，并返回到有效状态 (换句话说，初始状态在该过程后) 。 这可由总线驱动程序或固件提供。 如果总线规范定义了符合要求的带内重置机制，则总线驱动程序将实现 FLDR 处理程序。 固件编写器可以使用自己的 FLDR 实现替代总线定义的 FLDR，该实现使用带外信号（例如重置线路或电源切换），同时仍遵循 FLDR 的要求。
平台级设备重置 (PLDR)
平台级设备重置适用于无法使用 FLDR 的情况，或作为 FLDR 的最后补充。 这种重置机制会导致设备在电源周期内报告为总线 (缺失，例如，) 或影响多个设备 (，例如) 设备之间的共享电源轨或重置线路。 重置方法在 ACPI 表中指定，它可能实现为切换专用重置线路或对 D3 电源资源进行电源循环。 执行 PLDR 时，OS 会拆解并重新生成所有受影响设备的堆栈，以确保一切从原始状态开始。
重置 UDE 设备的恢复
对于启用 MBIM 函数的 UDE 客户端驱动程序，Windows 10 版本 1809包含一个 API，每当 UDECx 客户端驱动程序检测到错误时，该 API 可用于请求重置。 客户端驱动程序通过调用新方法 UdecxWdfDeviceNeedsReset 来请求重置，并指定它希望 UDECx 尝试 (设备（如果) 支持）的重置类型。 这些重置类型为 PlatformLevelDeviceReset 和 FunctionLevelDeviceReset ，是 UDECX_WDF_DEVICE_RESET_TYPE 枚举的值。 启动重置后，UDECx 会调用驱动程序的 EVT_UDECX_WDF_DEVICE_RESET 回调函数，并确保在此过程中不会调用其他回调。 客户端驱动程序应执行任何与重置相关的操作，例如释放任何资源，然后通过调用 UdecxWdfDeviceResetComplete 来发出重置完成信号。
以下流程图演示了 UDE 设备重置过程。
RnR 触发器
WWAN 服务将可操作的故障组织到 RnR 触发器中：
- 连接错误
- 单选状态集/查询失败/超时
- 连续 OID 请求超时
- 初始化失败
RnR 触发器 #1 - 连接错误
- 连接错误
- Internet 连接受限
- Internet 连接丢失
- 未正确接收路由
- 无法访问的路由
- 死网关
- 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 disable/enable
结果验证：发送OID_WWAN_RADIO_STATE查询并验证响应。
RnR 触发器 #3 - 连续 OID 请求超时
- TXM 将所有未完成的 OID 请求次数，并预期每个请求的响应。
- 如果“可配置”数量的连续 OID 请求未及时收到响应，TXM 会检测到它，并在内部向 CWwanResetRecovery 报告。
- OID 可以按高/中/低延迟组分组：
- 没有与 MO 交互的 OID 请求的延迟较低。
- 导致与 MO 交互的 OID 请求的延迟为中等。
- OID_WWAN_CONNECT激活/停用请求：约 180 秒。
恢复过程：
- 如果支持，则调用 PLDR
- 否则，请调用 PnP disable/enable
结果验证：发送OID_WWAN_RADIO_STATE查询并验证响应。
RnR 触发器 #4 - 初始化失败
- 在初始化期间超时设备上限或设备 capsEx 查询（在 MB 设备到达时）
- CWwanManager 检测并对其进行处理
恢复过程：
- 如果支持，则调用 PLDR
- 否则，请调用 PnP disable/enable
结果验证：无
PLDR 或 PnP 禁用/启用后，设备会离开，然后重新到达。 然后是到达时的初始化。
主要流
连接错误时为 RnR
针对无线电电源设置故障的 PLDR
PnP 禁用/启用单选状态集失败
连续 OID 请求超时的 PLDR
PnP 禁用/启用连续 OID 请求超时
初始化失败的 PLDR
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。 ACPI 将用于 _PR3 确定设备之间的重置依赖项（如果在设备范围内未 _PRR 引用）。 有关详细信息，请参阅 重置和恢复设备。
示例日志
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}}