Почему Quick Settings и Settings могут показывать разные моменты соединения и какие события driver-host-UI нужны для воспроизводимого отчёта.
Определите, какие состояния сравниваются
Quick Settings может показывать пользовательское состояние выбранной сети, а Settings — данные другой поверхности и в другой момент. Запишите точный текст каждой метки, время появления и доступность передачи данных. Не сводите всё к булевому connected: для Wi-Fi отдельно существуют запуск connect, синхронизация, authentication, association, завершение task и при 802.1X последующая авторизация порта. Microsoft описывает эти этапы в OID_WDI_TASK_CONNECT. Один кадр до завершения и один после него закономерно различаются, поэтому нужен порядок событий, а не только итоговые скриншоты.
Свяжите driver indications с host timeline
Для одного подключения соберите монотонные отметки: получение connect task, попытка к BSS, association result, connect complete, authorization при необходимости и первый успешный пакет. WiFiCx требует сообщать результат каждой попытки association, включая успешные и неуспешные, а отдельная официальная структура association result несёт список этих результатов. Не включайте в публичный отчёт реальные BSSID, SSID, PMKID или кадры аутентификации; замените их стабильными метками BSS_A и PROFILE_A. Важны порядок, статус и интервал, а не идентификаторы сети.
Добавьте два наблюдателя Windows
Официальная схема беспроводной диагностики связывает WlanSvc с основной логикой Wi-Fi, а Wcmsvc — с taskbar UI и взаимодействием с Network List Manager. Запишите ETW или штатные журналы на короткое окно от начала подключения до стабилизации обеих поверхностей и отметьте, когда каждая получила новое состояние. Проведите три сценария отдельно: успешное подключение, контролируемый отказ с неверным тестовым профилем и disconnect. Не меняйте firmware, драйвер и точку доступа между ними. Если расхождение возникает только после определённой последовательности indication, это воспроизводимая граница для драйвера или host stack.
Проверьте завершение, abort и повторный connect
WiFiCx требует после abort завершить попытки и сообщить completion; тот же port должен поддерживать последующий connect. Поэтому отдельный тест — прервать попытку, дождаться completion и запустить новое соединение без перезагрузки адаптера. Если одна UI-поверхность остаётся в старом состоянии после корректной последовательности, передайте Microsoft или IHV минимальную timeline: версия Windows, версия драйвера, сценарий, статусы association/connect и интервалы обновления UI. Остановитесь до ручного вмешательства во внутренние состояния Windows. Не прикладывайте полный trace публично: сетевые идентификаторы и содержимое кадров требуют редактирования и безопасного канала.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; контракт WiFiCx и компоненты Windows connectivity вручную сверены с Microsoft Learn, ветка использована только как обезличенный сигнал.
Источники и проверка
- Microsoft Learn — OID_WDI_TASK_CONNECT проверено 2026-08-03
- Microsoft Learn — NDIS_STATUS_WDI_INDICATION_ASSOCIATION_RESULT проверено 2026-08-03
- Microsoft Learn — Wireless network connectivity issues troubleshooting проверено 2026-08-03
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.