TP-Link Archer TBE552E — mtkwecx.sys v5.4.0.3119 causes repeated overnight BSODs (0xD1 / 0xA) — background scan mitigation insufficient

System Configuration

This is a desktop PC — no sleep, no hibernate, no power management involved. Crashes occur while the system is completely idle.

Crash History

15+ unexpected system crashes since 2026-03-29. Full crash timeline attached (crash_timeline.txt).

Pre-Crash Signature (Consistent Across All Crashes)

Every crash follows the exact same sequence, visible in the event log:

1. mtkwecx Event ID 1003 "Scan Abort" fires repeatedly — approximately every 60 seconds
2. Adapter cycles: Connect → DisAssoc → Scan Abort → repeat
3. After several minutes of this loop, the system crashes with no warning
4. No ACPI shutdown sequence. No thermal or power events. Event log ends cleanly at the last Scan Abort.

The pre-crash Scan Abort bursts are attached (mtkwecx_scan_abort_events.json).

BugCheck Analysis (from March 31 Minidumps)

BugCheck 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL)
  Arg1: 0x000000000000001f  — memory address being accessed (near-NULL, likely null pointer dereference)
  Arg2: 0x0000000000000002  — IRQL at time of fault (DISPATCH_LEVEL)
  Arg3: 0x0000000000000001  — write operation
  Arg4: 0xfffff807xxxxxxxx  — faulting instruction address in mtkwecx.sys

Interpretation: The driver's background scan loop is writing to a NULL or stale pointer while running at DISPATCH_LEVEL. This is a use-after-free or uninitialized pointer in the scan/roaming subsystem.

Minidumps available from the March 31 cluster and April 9–11 (C:\Windows\Minidump\) — can be uploaded on request for WinDbg analysis.

Fix Attempts

Attempt 1 — Driver Reinstall (2026-04-13)

Downloaded the Sep 26 2025 TP-Link package and confirmed it contains the identical mtkwecx.sys binary (v5.4.0.3119, same hash). Installed anyway — system crashed on reboot. Rolled back. This package is not a fix.

Attempt 2 — Background Scan Mitigation (2026-04-15)

Applied the following to suppress Windows-triggered and driver-level background scanning:

# Disable Windows WiFi autoconfig (stops OS-triggered scans)
netsh wlan set autoconfig enabled=no interface="Wi-Fi"

Registry: HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0013
  BackgroundScan  = 0  (DWORD)
  ScanAssociated  = 0  (DWORD)
  LowPowerEnable  = 2  (DWORD)

Result: Scan Abort frequency dropped significantly. WiFi remained connected and stable. However, the system still crashed on 2026-04-17 at 23:27 — 2 days after the mitigation was applied.

The 2026-04-17 crash details:

• BugcheckCode: 0xA (IRQL_NOT_LESS_OR_EQUAL — same IRQL family as 0xD1, different code path)
• BugcheckInfoFromEFI: true — crash was so fast no minidump was written; info came from EFI
• No Scan Abort events logged in the 30 minutes before the crash (event log writer didn't flush before crash)
• Scan Abort bursts were observed earlier that same day at 17:27 (30+ events in ~1 minute)
• System was fully idle at time of crash

Current registry values confirmed in place at time of crash (attached: mediatek_registry.json).

Current State

Adapter fully disabled pending a driver fix:

• PnP device disabled via Device Manager (survives reboot)
• mtkwecx service set to Disabled (will not load on boot)
• Running on onboard Realtek 2.5GbE

The WiFi adapter is not needed for daily use. However, a kernel driver that crashes the OS even when supposedly suppressed is a serious reliability and safety issue regardless.

Questions

1. Is a new mtkwecx.sys binary (version > 5.4.0.3119) in development or available from MediaTek/TP-Link engineering?

2. Why do Scan Abort events continue firing with BackgroundScan=0 and ScanAssociated=0? Is there a roaming-triggered or AP-initiated scan path in the driver that bypasses these registry keys?

3. Is there any way to completely disable the background scan subsystem in mtkwecx.sys at the driver level — short of disabling the adapter entirely?

4. The 2026-04-17 crash produced 0xA instead of 0xD1 despite the same root behavior. Does this suggest the mitigation partially changed the code path that gets hit, or is this expected variation?

Attachments

Minidumps from C:\Windows\Minidump\ (5 files, Mar 31 and Apr 9–11) available on request.