WinRT/CPP应用访问断开后的BLE设备时意外退出的问题求助

我之前也踩过Win10 BLE栈的这个坑——系统的ConnectionStatus()确实会有10-15秒的同步延迟，尤其是设备意外断开时，这段时间里发起GATT操作会直接导致应用静默退出，还找不到崩溃报告，本质是因为没捕获异步操作中的异常。下面给你梳理几个实用的优化方案：

1. 必须捕获GATT操作的异常，阻止应用静默崩溃 #

WinRT的异步GATT操作（比如GetGattServicesAsync、特征读写）在设备实际断开时会抛出hresult_error，但如果没捕获这个异常，应用会直接终止，而且这种终止通常不会生成标准崩溃报告（因为是异步协程里的未处理异常）。

你需要在所有GATT操作的代码块外层添加异常捕获，针对BLE相关错误码做针对性处理：

try {
    if (leDevice.ConnectionStatus() == BluetoothConnectionStatus::Connected) { 
        auto servicesResult = co_await leDevice.GetGattServicesAsync(); 
        // 后续的特征读写操作也务必放在try块内
        auto targetCharacteristic = servicesResult.Services().GetAt(0).GetCharacteristics().GetAt(0);
        auto readResult = co_await targetCharacteristic.ReadValueAsync();
        // 处理读取结果
    }
} catch (const winrt::hresult_error& ex) {
    // 针对BLE断开或无效状态的常见错误码做处理
    auto errorCode = ex.code();
    if (errorCode == HRESULT_FROM_WIN32(ERROR_BLUETOOTH_DISCONNECTED) ||
        errorCode == HRESULT_FROM_WIN32(ERROR_BLUETOOTH_ATT_INVALID_STATE)) {
        // 更新UI提示用户设备断开，或重置本地连接状态
        std::wcout << L"设备已断开连接\n";
    } else {
        // 处理其他GATT错误，比如权限问题、特征不存在等
        std::wcout << L"GATT操作失败: " << ex.message() << L"\n";
    }
}

2. 不要单独依赖系统ConnectionStatus，维护本地状态标记 #

系统的ConnectionStatus()依赖BLE栈的超时检测，延迟是固有特性。你可以结合已注册的连接状态回调，自己维护一个本地的连接状态变量，同时在GATT操作失败时主动更新这个变量（因为回调可能滞后）：

// 用原子变量保证线程安全，因为回调可能在后台线程触发
std::atomic<bool> m_localConnectedState = false;

// 连接状态变更回调的实现
void OnConnectionStatusChanged(BluetoothLEDevice const& sender, IInspectable const&) {
    m_localConnectedState = (sender.ConnectionStatus() == BluetoothConnectionStatus::Connected);
}

// 读写前的检查逻辑：优先用本地状态，再结合系统状态做双重校验
if (m_localConnectedState && leDevice.ConnectionStatus() == BluetoothConnectionStatus::Connected) {
    try {
        auto servicesResult = co_await leDevice.GetGattServicesAsync();
        // ... 后续操作
    } catch (const winrt::hresult_error& ex) {
        // 操作失败，主动将本地状态标记为断开，避免后续无效操作
        m_localConnectedState = false;
        // 处理错误
    }
}

这样做的好处是：当系统回调还没更新状态时，GATT操作失败会立即修正本地状态，避免重复发起无效请求。

3. 可选：主动验证连接状态（适合实时性要求高的场景） #

如果你的应用需要更实时的连接状态判断，可以发起一个轻量的GATT操作（比如读取一个固定的、无副作用的特征值）来验证连接，而不是只依赖状态检查：

winrt::IAsyncOperation<bool> IsDeviceReallyConnected(BluetoothLEDevice const& device) {
    try {
        // 替换成你设备中存在的服务和特征UUID
        auto services = co_await device.GetGattServicesAsync();
        auto targetService = services.Services().First([](auto& s) { 
            return s.Uuid() == winrt::guid{L"你的服务UUID"}; 
        }).Current();
        auto pingCharacteristic = targetService.GetCharacteristics().First([](auto& c) { 
            return c.Uuid() == winrt::guid{L"你的Ping特征UUID"}; 
        }).Current();
        auto result = co_await pingCharacteristic.ReadValueAsync();
        co_return result.Status() == GattCommunicationStatus::Success;
    } catch (...) {
        co_return false;
    }
}

// 使用示例
if (co_await IsDeviceReallyConnected(leDevice)) {
    // 执行读写操作
}

注意不要频繁调用这个验证方法，避免占用BLE带宽影响正常通信。

关于崩溃报告的补充 #

应用静默退出但没有崩溃报告，是因为WinRT协程中的未处理异常会触发应用快速终止，这种情况不会生成Windows错误报告（WER）。只要你捕获了所有异步操作中的异常，就能避免这种情况，同时可以自己实现日志记录，方便后续排查问题。

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