Windows 11 KB5121003 Power Reports: What We Know

The source concentration matters from the outset. The prevalence evidence consists of anonymous, self-reported Reddit posts and comments, with some accounts cross-referencing the same discussion, rather than independently verified incident reports. These accounts are not independent corroboration. Official Microsoft material verifies the update versions and the issues Microsoft has documented publicly, but it does not verify the reported AC-state incidents.

That distinction is practical, not merely semantic. A Windows event can record a change in the operating system’s view of external power without proving that electricity stopped flowing from the charger. Likewise, a symptom noticed after an update is a reason to investigate timing and compatibility; it is not a completed root-cause analysis.

What KB5121003 includes​

Microsoft released KB5121003 on August 11, 2026, for Windows 11 versions 24H2 and 25H2. It advanced those versions to OS builds 26100.9168 and 26200.9168, respectively.

The package is cumulative. It includes changes from the July 28 preview update, KB5101684. This matters when interpreting rollback tests. Microsoft’s public release material for the preview described a Power and Battery improvement intended to make power-setting changes more reliable by applying Settings changes to all power plans.

That note does not mention AC-adapter disconnects, black screens, Lenovo Legion systems, or HP Victus laptops. It does, however, show that power-related work was already part of the cumulative update’s inherited code. Therefore, rolling back from build 26200.9168 to an earlier build does not isolate an August-only change. If software is involved, the relevant change could have arrived with the earlier preview, another included change, or an interaction with device-specific software or firmware.

None of that proves the preview is responsible. It sets a limit on what can fairly be inferred from the available before-and-after reports.

What the user accounts describe​

The central Lenovo Legion account describes repeated Windows transitions from AC to battery and then back to AC, Kernel-Power Event ID 105 entries, and brief black screens after KB5121003 was installed. The user also reported that the laptop’s charging LED could remain lit when Windows logged the apparent AC loss.

The same user later rolled back from build 26200.9168 to build 26200.8875 and reported roughly 15 hours with no AC_LOST events and no black screens. That observation is useful: during the user’s reported test period, reverting to an earlier build coincided with the disappearance of the symptom.

It is not proof that KB5121003 caused the problem. The rollback removed more than the update’s August-specific changes, and the test was not an independently controlled reproduction. The reporter also acknowledged plausible alternatives, including Lenovo firmware, embedded-controller behavior, and a hardware power issue.

Other anonymous posts describe superficially similar transient AC-state behavior on additional Lenovo Legion machines and on at least one HP Victus laptop. The HP account describes Event ID 105 with AcOnline: false and says that an Nvidia discrete GPU sometimes briefly reinitialized. If a laptop believes that it has crossed a power boundary, a short display blanking or graphics reconfiguration could be a plausible consequence.

But symptom similarity is not evidence of one shared cause. The Lenovo and HP reports have not been independently verified, and cross-brand accounts cannot establish a common Windows root cause.

An Event ID 105 does not prove adapter power was lost​

Event Viewer can help create a timeline, but its records need careful interpretation. A power event reflects a state that Windows observed or was told by lower layers of the system. It is not a direct measurement of every part of the charging chain: the adapter, cable, connector, battery-management circuitry, motherboard power path, embedded controller, firmware, drivers, and Windows power stack.

An AcOnline: false entry is evidence that Windows registered itself as not on AC at that time. On its own, it does not demonstrate that the adapter stopped delivering power. Equally, an unchanged charging LED does not settle the question in the other direction. Neither Event ID 105 nor a still-illuminated LED independently distinguishes a firmware or hardware sensing problem from a Windows-layer reporting problem.

The apparent disagreement between Windows and a charge LED is therefore important evidence to preserve, not a diagnosis. It could be consistent with a brief physical interruption that the indicator did not visibly reflect. It could also be consistent with an embedded-controller, firmware, driver, or operating-system reporting path that briefly exposed the wrong state to Windows while power remained available.

The HP material provides an important counterweight to a Windows-only theory. A separate HP Victus investigation described a repeatable, state-dependent battery and power anomaly under both Windows and Fedora. The owner also said an HP battery diagnostic changed from a normal result to a recommendation to replace the primary battery.

That does not rule out a Windows interaction on another device. It does mean that at least some outwardly similar reports may have a battery, charging, embedded-controller, firmware, or hardware explanation. A behavior that also occurs under another operating system cannot be cleanly attributed to a Windows cumulative update.

The component explanation remains unproven​

The Lenovo reporter said a manifest comparison identified updates in battery, ACPI, charge-arbitration, platform-power, and Intel power-management areas between the earlier build and build 26200.9168. Those are logically relevant parts of the software environment for a reported AC-to-battery transition.

Still, this is a user-reported comparison, not independently reproduced component analysis. No available evidence identifies a faulty Windows battery driver, ACPI component, embedded-controller-to-ACPI path, or Intel component. The person who performed the comparison did not claim that a named component had been confirmed as defective.

Modern laptop power handling crosses several layers. Windows, device drivers, BIOS or UEFI firmware, OEM utilities, embedded-controller logic, battery condition, charger capability, and the physical connector all influence what the user sees. A Windows update could conceivably alter timing or communication that exposes a pre-existing firmware or hardware weakness. A marginal charger, battery, or controller could also become noticeable after a software change alters a power policy or device state.

For that reason, statements that KB5121003 “cuts power” on Lenovo laptops go beyond the evidence. The established observation is narrower: Windows reported transient changes in AC state on the systems described by the posters.

Microsoft’s documented status​

Microsoft’s KB5121003 material lists other documented known issues, including an RGB-related game issue involving inpoutx64 and a Teams and Outlook issue on certain ARM devices. It does not list the reported Lenovo or HP AC-transition pattern.

The absence of this symptom from a known-issues list does not prove that the reports are mistaken. Public issue documentation is not an exhaustive, real-time record of every incoming customer report. It does mean there is no basis in the available evidence for describing this as a Microsoft-confirmed regression, a Lenovo-wide problem, or an officially acknowledged compatibility issue.

Microsoft released KB5124008 on September 8, 2026, moving Windows 11 24H2 and 25H2 to builds 26100.9445 and 26200.9445. There is no verified evidence that this update fixes the reported AC-state behavior. One user in the Lenovo-focused discussion later said the symptom returned after installing KB5124008, but that is another unverified, anecdotal follow-up rather than proof that the September package causes or reintroduces anything.

Users should not assume that installing the next cumulative update is a confirmed repair, nor that it will necessarily reproduce the behavior.

A practical troubleshooting checklist​

If a laptop seems to flip between AC and battery after a recent update, document the condition before assigning blame to Windows or assuming a failed adapter.

1. Record the exact Windows version, OS build, and update history. This separates 24H2 from 25H2 and identifies whether the PC is on build 26100.9168, 26200.9168, a later build, or an earlier baseline.
2. Create an incident timeline in Event Viewer. Record the time of Kernel-Power entries, especially Event ID 105 and any AcOnline value. Note black screens, GPU reinitialization, sleep or wake activity, workload, and docking or peripheral changes. The log is diagnostic evidence, not proof of physical adapter failure.
3. Check physical indicators separately. Observe the charging LED, battery percentage, connector fit, and adapter behavior. If possible, test with a known-good, compatible charger. Record any mismatch between the LED and Windows’ reported state, while recognizing that neither indicator alone identifies the responsible layer.
4. Treat display blanking as related, but not conclusive. A brief black screen may follow graphics reinitialization after a perceived power transition. It does not independently show whether the charger, display, GPU, firmware, or Windows update is at fault.
5. Run OEM diagnostics and check firmware. Apply vendor-recommended BIOS or UEFI, embedded-controller, battery, and power-management updates where appropriate. Use the manufacturer’s battery and adapter diagnostics. This is especially important because the available HP account leaves a hardware or firmware path plausible.
6. Use uninstalling or pausing updates only as a temporary diagnostic step. Removing or delaying a cumulative security update carries security and support risk and should not be treated as a proven repair. If a rollback appears to stop the symptom, preserve the build numbers and timestamps, report the result promptly to both the PC maker and Microsoft, and reapply supported updates when feasible.
7. Submit a detailed vendor report. Include the laptop model, firmware version, Windows build, charger model and wattage, incident timestamps, relevant event entries, charging-LED observations, battery diagnostic results, and whether the problem occurs under another operating system. That evidence gives Microsoft and the OEM a better chance of separating a software interaction from an isolated device fault.

The bottom line​

The available reports justify further troubleshooting and vendor investigation. The strongest observation is a temporal pattern reported by one Lenovo owner: Windows AC-state transitions and black screens after KB5121003, followed by a symptom-free period after rollback. A small number of anonymous accounts describe similar symptoms elsewhere, but they are self-reported Reddit material, not independently verified incident evidence.

What remains unestablished is just as important. The accounts do not prove physical loss of adapter power, identify a defective Windows component, demonstrate a widespread Lenovo issue, show that HP cases share the same cause, or confirm recognition of the problem by Microsoft or Lenovo. Until those gaps are closed, the sensible response is disciplined troubleshooting: preserve logs, check charger, battery, firmware, and OEM diagnostics, and report reproducible evidence rather than turning a plausible post-update association into a definitive diagnosis.