PairAsync首次配对返回RequiredHandlerNotRegistered问题咨询

现象复现 #

• 基于WPF开发BLE设备通信应用，调用Windows.Devices.Enumeration.DeviceInformationCustomPairing.PairAsync实现自定义配对流程，通过自有UI收集用户输入的PIN码完成配对
• 首次对未配对设备发起请求时，返回状态码RequiredHandlerNotRegistered，同时弹出Windows系统自带配对弹窗，不符合自定义配对不触发系统UI的预期
• 手动关闭系统弹窗后，再次对同一设备发起配对，流程正常走自定义处理逻辑，返回Paired状态
• 已按官方文档要求注册PairingRequested事件处理程序，且验证目标设备确实支持ProvidePin配对模式，不符合文档列出的该错误码的两种已知触发场景

问题代码 #

private async Task PairingAsync(DeviceInformation devInfo)
{
    var pairingInformation = devInfo.Pairing;
    if (pairingInformation.CanPair)
    {
        pairingInformation.Custom.PairingRequested += this.OnPair;
        var result = await pairingInformation.Custom.PairAsync(DevicePairingKinds.ProvidePin, DevicePairingProtectionLevel.None);
        pairingInformation.Custom.PairingRequested -= this.OnPair;

        if (result.Status == DevicePairingResultStatus.Paired ||
            result.Status == DevicePairingResultStatus.AlreadyPaired)
            Logger.Info("Device is paired successfully");
        else
        {
            Logger.Info($"Error occured while pairing with device: {result.Status.ToString()}");
            throw new InvalidOperationException("Pairing with device is not under control, connecting cancelled.\n Try to pair manually");
        }
    }
    else 
    {
        throw new InvalidOperationException($"Pairing with device is forbidden");
    }
}

private void OnPair(DeviceInformationCustomPairing sender, DevicePairingRequestedEventArgs args)
{
    Logger.Info("Pairing requested...");
    switch (args.PairingKind)
    {
        case DevicePairingKinds.ConfirmOnly:
            // Windows itself will pop the confirmation dialog as part of "consent" if this is running on Desktop or Mobile
            // If this is an App for 'Windows IoT Core' or a Desktop and Console application
            // where there is no Windows Consent UX, you may want to provide your own confirmation.
            args.Accept();
            break;

        case DevicePairingKinds.ProvidePin:
            // A PIN may be shown on the target device and the user needs to enter the matching PIN on 
            // this Windows device. Get a deferral so we can perform the async request to the user.
            args.Accept(this.pin);
            break;
    }
}

1. 核心问题：PairAsync传入的支持配对类型不全
   官方文档未明确说明RequiredHandlerNotRegistered的第三个触发条件：配对流程中Windows蓝牙栈实际发起的配对请求类型，不在调用PairAsync时传入的DevicePairingKinds枚举集合内时，无论事件处理函数中是否写了对应类型的处理逻辑，系统都会判定没有注册对应处理程序，直接回退到系统默认配对UI，返回该错误码。
   首次配对时，Windows蓝牙栈需要先和目标设备完成能力协商，第一步会触发ConfirmOnly类型的用户授权请求（桌面端默认触发系统确认弹窗的步骤）。现有代码调用PairAsync时仅传入DevicePairingKinds.ProvidePin，未包含ConfirmOnly，系统直接判定无对应处理程序，弹出系统窗、返回错误。
   第二次配对成功的原因是：第一次配对流程（哪怕最终手动关闭弹窗未完成）已经让Windows把目标设备的配对能力缓存到本地枚举栈，第二次发起请求时会跳过初始的ConfirmOnly授权步骤，直接进入ProvidePin流程，刚好匹配代码中传入的支持类型，因此能正常走自定义逻辑。
2. 时序隐患：临时注册事件存在订阅未完成的概率
   现有代码在调用PairAsync前紧挨着注册PairingRequested事件，配对完成后马上注销。在WPF的STA线程模型下，存在事件订阅同步未完成、配对流程已经启动的概率，会导致第一次配对请求未被自定义处理程序捕获。
3. 逻辑缺陷：未按规范使用Deferral
   ProvidePin分支的注释明确提到需要获取Deferral支撑异步用户交互，但实际代码未调用args.GetDeferral()。如果后续把PIN码收集逻辑调整为配对请求触发后再弹自有UI获取，会因为处理函数提前返回，导致系统判定请求未被处理，再次触发系统UI回退。

• 调整PairAsync入参，把流程中所有可能触发的配对类型都加入支持集合，不要仅传入ProvidePin：
  将原调用代码
  var result = await pairingInformation.Custom.PairAsync(DevicePairingKinds.ProvidePin, DevicePairingProtectionLevel.None);
  修改为
  var result = await pairingInformation.Custom.PairAsync(DevicePairingKinds.ConfirmOnly | DevicePairingKinds.ProvidePin, DevicePairingProtectionLevel.None);
• 按规范补全Deferral逻辑，兼容后续异步PIN收集场景，修改后的事件处理函数如下：

private void OnPair(DeviceInformationCustomPairing sender, DevicePairingRequestedEventArgs args)
{
    Logger.Info("Pairing requested...");
    var deferral = args.GetDeferral();
    try
    {
        switch (args.PairingKind)
        {
            case DevicePairingKinds.ConfirmOnly:
                // 自定义配对场景下直接确认，拦截系统弹窗
                args.Accept();
                break;
            case DevicePairingKinds.ProvidePin:
                // 如果改为触发后弹自定义UI收集PIN，此处await UI加载逻辑拿到PIN值再传入Accept
                args.Accept(this.pin);
                break;
            default:
                throw new NotSupportedException($"Unsupported pairing type: {args.PairingKind}");
        }
    }
    finally
    {
        // 所有逻辑处理完成后标记deferral完成
        deferral.Complete();
    }
}

• 优化事件注册时机：不要每次配对才临时注册/注销PairingRequested事件，改为在自定义配对模块初始化、或BLE设备列表加载完成时统一注册，应用退出或设备资源释放时再注销，规避首次调用的时序问题。

修改完成后首次发起配对即可正常走自定义逻辑，不会弹出系统配对弹窗，直接返回Paired状态。

内容的提问来源于stack exchange，提问作者Muhammad Ali