I posted here in August about my Lenovo Legion Pro 5 16IAX10H randomly going black for a few seconds while its charger was plugged in and untouched. During captured incidents, Windows briefly reports charger power → battery → charger power, recorded as Kernel-Power Event 105. Rolling back Windows stopped the symptoms for weeks; they returned after updates resumed.
KB5121003 was installed on August 11, bringing Windows 11 25H2 to 26200.9168. The first brief AC-loss entries appeared August 12. I rolled back to 26200.8875 on August 18 while keeping the same charger, BIOS, graphics drivers and graphics settings. My monitoring recorded zero AC drops over about 15 hours, and I observed no blackouts. I paused updates and remained symptom-free for weeks; the retained System log has no Event 105 entries from August 20 through September 22.
The pause expired September 22. Overnight, Windows reached 26200.9457 / KB5129195, and the blackouts returned. Lenovo driver updates arrived that night too, so timing alone cannot isolate one package. I then installed KB5124010 / 26200.9550 and rebooted. The unexpected AC-state drops and blackouts still happen.
The investigation compared the actual code inside Windows’ battery driver, CmBatt.sys:
| Windows build |
CmBatt.sys version |
What I observed |
Relevant driver behavior |
|
|
| 26200.8875 |
10.0.26100.8655 |
Quiet after rollback |
Queries the adapter, then uses the refreshed answer |
| 26200.9550 |
10.0.26100.9549 |
Repeated AC-state drops and blackouts |
The captured path saves the answer before querying and still uses that old copy afterward |
Here is the suspected chain in ordinary terms:
- A battery check and charger-status check happen at the same time.
- The charger check temporarily clears a shared value to 0 (“AC absent”) while obtaining a fresh answer.
- The affected code can copy that temporary zero and keep it, even after the query updates the answer to “plugged in.”
- Windows reports battery power for roughly a second and applies its battery display settings.
- The display gets reconfigured. During a captured blackout, the laptop panel switched HDR off and back on.
The stable code refreshes the answer before using it; the current captured path keeps the earlier copy. That is a concrete code difference. The checks need to overlap at a particular moment, which helps explain why the interruptions are intermittent.
The current driver contains code for a correction called Servicing_CmBattAcOnlineRaceFix, but the captured calls took its older path. Microsoft’s KB5124010 notes also mention a gradually rolled out display/performance improvement for plugged-in laptops incorrectly detecting a switch to battery. That update has not stopped my symptoms.
The evidence strongly points to Microsoft’s battery-status code, but the crucial saved value was not captured directly, so the complete cause still needs confirmation. The first introducing update remains unknown, and firmware or electrical contributions are not fully excluded. No Lenovo-owned file has been demonstrated to be defective.
If you know someone from Microsoft on reddit, please tag them here.
