Windows update bugs with cam keyboard and fingerprint

Question

Windows update bugs with cam keyboard and fingerprint

Aadarsh Prakash 0

Bug Report: Intermittent Keyboard Ghosting and Webcam Disconnection (Code 45) Following Boot/Wake/Unlock Events — Windows 11

Summary

Since late July 2026, I have experienced two recurring, intermittent hardware-adjacent issues on my primary laptop (MSI Katana 15, model B12UDXK) running Windows 11. Extensive troubleshooting — including full BIOS/EC/CMOS resets, driver reinstalls, and cross-OS testing — has ruled out physical hardware failure as the cause. The evidence instead points to a Windows-level bug in device power-state re-initialization occurring around boot, sleep/wake, and screen-unlock transitions. I am also aware of similar symptom categories (different peripherals, different laptop brands) being reported by other users, suggesting this may not be isolated to one OEM or one device class.

Primary Affected Device

MSI Katana 15, Model B12UDXK

Chassis code: MS-1585

CPU: Intel Core i7-12450H

GPU: NVIDIA RTX 3050, 6GB VRAM, 96-bit memory bus

RAM: 16GB DDR5-4800 (2× 8GB, dual-channel, Samsung modules)

Storage: 1TB Micron 2400 NVMe SSD (PCIe Gen4)

OS: Windows 11 Home Single Language, clean-installed (custom unattended ISO, standard debloat tooling applied — see "Environment Notes" below)

Issue 1: Keyboard Input Ghosting / Stuck Keys

Description: Keys intermittently continue to register as "held" for several seconds after being physically released. Examples:

Holding a movement key (e.g., W) in-game, releasing it, and the character continues moving for multiple seconds afterward.

Modifier or regular keys appearing "stuck" during normal desktop use — typing, browsing, and Alt-Tabbing between windows (i.e., not exclusive to gaming or high input-rate scenarios).

Key diagnostic finding — reproduces on external keyboards: This issue occurs identically when using an external USB keyboard in place of the laptop's built-in keyboard. This rules out a physical/internal hardware cause (e.g., keyboard matrix, ribbon cable, or Embedded Controller fault), since an external, independently connected USB device cannot be affected by an internal hardware fault.

Trigger pattern: The issue reliably correlates with specific system transition events rather than sustained use duration:

Shortly after a full system boot/restart

Shortly after waking from sleep (Modern Standby / S0 Low Power Idle)

Shortly after unlocking the screen (from lock screen)

It does not show a consistent correlation with continuous keyboard use duration, gaming load, or any specific application.

Temporary recovery methods (no permanent fix identified):

Ctrl+Alt+Del → Cancel (fastest; forces a session/input resync without a full restart)

Toggling the On-Screen Keyboard on then off

Win+Ctrl+Shift+B (forces a display/graphics driver reset)

Full system restart (slowest, most reliable)

Ruled out as causes:

RGB/lighting software (Mystic Light) — updated to latest version; issue persisted afterward (though frequency temporarily decreased following the update and an EC/BIOS/CMOS reset, it recurred days later)

Valorant / Riot Vanguard anti-cheat — confirmed the issue occurs with no game or anti-cheat process running at all (reproduced during plain browser/text typing)

inpoutx64.sys (the driver associated with Microsoft's confirmed KB5121003 game-crash bug) — confirmed via driverquery and full filesystem search to be absent from this system entirely

Optional preview update KB5120998 (build 26200.9278) — confirmed the issue predates installation of this update

Physical/hardware fault — ruled out via external keyboard reproduction (see above) and via full BIOS/EC/CMOS/battery drain reset, which produced no lasting change

Issue 2: Webcam Intermittent Disconnection (Device Manager Code 45)

Description: The internal webcam intermittently becomes undetected by Windows, showing the following in Device Manager (under hidden devices):

"Currently, this hardware device is not connected to the computer. (Code 45)"

Key diagnostic findings:

Reproduces in a non-Windows environment. The same failure (camera undetected) was reproduced while running a Linux distribution (Zorin OS) from a live USB session. Since webcams almost universally use the standards-based UVC (USB Video Class) protocol — supported natively by the Linux kernel without vendor-specific drivers — a failure appearing identically under a completely separate OS and driver stack strongly suggests the fault is not with the physical camera module or its cable, but with something in the shared USB/power-management hardware path or firmware-level behavior.

Recovers multiple times within a single boot session with no physical interaction. On separate occasions, the camera has gone from "not detected" to "working" to "not detected" again multiple times within one continuous power-on session, without the laptop being moved, the lid being touched, or any physical interaction with the device. A physically damaged or fractured cable could not exhibit this pattern, as such a fault would not spontaneously self-correct and re-fail repeatedly without mechanical disturbance.

Correlates with power-state and mode-switching events, specifically:

After the system wakes from sleep

After switching GPU mode (iGPU/Hybrid/Discrete) via vendor software (which triggers one or more automatic reboots)

 After extended idle periods

 

 **Most common recovery method: a display power-cycle.** Closing and reopening the laptop lid (which triggers a display sleep/wake power event, not physical cable flex) has, in the large majority of attempts (well over 20 instances), restored camera function within seconds. On rare occasions (e.g., while away from the usual home environment, possibly at a different ambient temperature), this specific method did not restore function immediately; a full restart or Device Manager disable/re-enable was required instead.

Ruled out as causes:

Physical cable damage — the cross-OS reproduction and multiple recoveries within a single session (see above) are inconsistent with a purely mechanical fault

BIOS-level camera disable toggle — verified enabled/correctly configured

Missing or corrupted camera driver — verified present and up to date; full driver reinstall attempted with no change in recurrence

Third-party privacy/security software blocking camera access — none installed

Environment Notes

A one-time optional preview update (KB5120998, build 26200.9278) was installed partway through this troubleshooting process in the hope it would resolve the issues. It did not; both issues were already present before this update was installed, and persisted after.

The system uses a customized, debloated Windows 11 installation (a commonly used community debloat/telemetry-reduction script, applied via a custom unattended answer file at install time). This exact same tooling and process has been used successfully on this same physical machine in the past (prior Windows installations) without these symptoms occurring, suggesting the debloat process itself is not the root cause, though a specific service or component it manages cannot be fully ruled out without a fully stock comparison install.

A complete hardware-level reset was performed (CMOS battery removal, Embedded Controller drain via pinhole reset, full power drain with all components disconnected) partway through troubleshooting. This produced no lasting resolution to either issue, which is consistent with a software/OS-level cause rather than a hardware/firmware state corruption.

Broader Pattern Observed (Anecdotal, Different Devices)

While not formally diagnosed to the same degree, I am aware of similar symptom categories — device enumeration/initialization flakiness tied to power-state transitions — being reported on different peripherral types and different laptop brands:

ASUS Vivobook (OLED variant, exact model pending): Intermittent fingerprint reader failures, recoverable via Device Manager disable/re-enable or driver reinstall — same general symptom category (peripheral silently failing, recoverable via re-enumeration) on a different OEM's hardware.

HP Victus (exact model pending, reported by a third party): Intermittent webcam glitches reported independently, on different hardware entirely.

I raise these only as anecdotal context suggesting this may reflect a broader Windows 11 device-initialization issue rather than something specific to one OEM's drivers or firmware, not as formally verified duplicates of my own issue.

Request

Given that:

Both issues correlate specifically with boot, sleep/wake, and unlock transitions rather than sustained use,

The keyboard issue has been confirmed to affect external, independently connected USB devices (ruling out internal hardware),

The camera issue reproduces cross-OS and self-recovers multiple times without physical interaction (ruling out cable/connector damage),

I'd ask that Microsoft's engineering teams investigate potential regressions in Windows' Plug-and-Play (PnP) device re-initialization and/or power-state (D0/D3, ACPI wake) handling during these specific transition events, as this appears to be an OS-level issue rather than a hardware or OEM-driver-specific fault.

I'm happy to provide additional diagnostic logs (Event Viewer exports, driverquery output, HWiNFO reports) if useful for investigation.

0 comments

1 answer

Your answer

Answer 1

Hendrix-V 18,515 Microsoft External Staff Moderator

Hi Aadarsh Prakash,

Based on the information you've gathered, the issues appear to be consistently associated with system state transitions such as boot, sleep/wake, and unlock events, rather than a specific application or normal usage pattern. The fact that the keyboard behavior also occurs with an external USB keyboard and that the camera issue is intermittent across multiple recovery cycles provides useful diagnostic context.

As additional troubleshooting, you may want to try the following:

1, Check for device-related warnings around the time the issue occurs:

Open Event Viewer
Review Windows Logs > System
Look for Plug and Play, USB, HID, camera, or power-management events

2, Test with power-saving features disabled for affected devices:

Open Device Manager
Open the device properties
Under Power Management, clear Allow the computer to turn off this device to save power (if available)

3, Generate a power diagnostics report:

Open Command Prompt (Admin)
Run: powercfg /energy
Review the generated report for device or power-state warnings

Since the system is using a customized Windows installation, it may also be worthwhile, if practical, to compare the behavior against a standard Microsoft Windows installation to determine whether any modified components are contributing to the symptoms.

Let me know if you need further assistance, feel free to ask me by clicking "Add Comment" or "Add Answer" if you cannot add comment so your response will be visible. Thanks for your effort.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Aadarsh Prakash 0 Reputation points

2026-09-02T13:15:36.31+00:00
Follow-up Reply Draft — Microsoft Community Forum

Hi Hendrix-V,

Thanks for the detailed suggestions. I worked through all three diagnostic steps you recommended, and I think I've found something concrete on the first one. Full details and reasoning below, with all raw diagnostic output attached.

1. powercfg /energy — USB Selective Suspend Failure (Camera)

I ran powercfg /energy /duration 60 as Administrator. The report (attached as energy-report.html) flagged 6 errors, two of which are USB devices failing to enter the Selective Suspend power state:

USB Suspend: USB Device not Entering Selective Suspend This device did not enter the USB Selective Suspend state. Processor power management may be prevented when this USB device is not in the Selective Suspend state. Device Name: USB Composite Device Host Controller ID: PCI\VEN_8086&DEV_51ED Device ID: USB\VID_30C9&PID_0042

I cross-referenced this Device ID against my system's full device list using:

Get-PnpDevice | Where-Object {$_.InstanceId -like "*VID_30C9&PID_0042*"} | Format-List FriendlyName, InstanceId, Class

This confirmed the device is my Integrated Camera (manufactured by Sunplus IT Inc.), enumerating under both a "Camera" class entry and a "USB Composite Device" entry, both sharing this same VID/PID.

Why I think this is significant: USB Selective Suspend is the exact mechanism Windows uses to power a USB device down during idle and bring it back up on demand. A device that's failing this specific negotiation seems like a strong candidate for explaining:

Why the camera intermittently shows Code 45 ("Currently, this hardware device is not connected to the computer")

Why it reliably recovers via a display power-cycle (closing and reopening the laptop lid), rather than staying permanently disconnected — this looks like a failed power-state transition correcting itself on a subsequent power event, not a physical fault

2. Screen Recording of the Failure in Progress

I have a screen recording capturing the following sequence directly:

The Camera app (Windows Camera) was flickering/showing a broken feed.

I restarted the Camera app itself (not the PC) — flickering continued, unresolved.

I used MSI Center's camera privacy toggle to force-disable and re-enable the camera at the OS level.

Immediately after, Device Manager showed the camera with Code 45.

Approximately 5 seconds later, with no physical interaction with the laptop (lid untouched, no movement), the camera automatically recovered and began working normally.

I think this sequence is worth highlighting specifically because the recovery happened with zero physical interaction — this is difficult to reconcile with a physically damaged cable or connector, since those don't self-correct without mechanical disturbance. It's much more consistent with a timing/race condition in how the camera is re-initialized after its power state is toggled.

Video (unlisted, camera bug): https://youtu.be/phUgcuqHOyU

3. Event Viewer — 3-Day Window, PnP/USB/Camera/Power Providers

Since I didn't have the exact timestamp of a specific occurrence readily available, I pulled a broader 3-day window instead:

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-3)} | Where-Object {$_.LevelDisplayName -in @('Error','Warning') -and ($_.ProviderName -match 'Kernel-PnP|usbhub|USB|Camera|WUDF|Kernel-Power')} | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List

Result (full output attached): The only recurring entries are Microsoft-Windows-Kernel-PnP Event ID 219 (The driver \Driver\WUDFRd failed to load), tied to an Intel Alder Lake thermal management/DPTF participant device (PCI\VEN_8086&DEV_461D). As far as I can tell, this is unrelated to the camera or keyboard issue — I haven't observed any symptom correlating with these specific timestamps, and this device is part of CPU thermal monitoring, not USB/HID/imaging.

Notably, nothing in this log correlates directly to the camera or keyboard failures. I think this is worth mentioning explicitly: it suggests the failure may not be throwing a catchable/logged error at all, which would explain why it's been difficult to pin down through conventional log analysis.

4. Power Management Checkbox

I unchecked "Allow the computer to turn off this device to save power" specifically on:

The Integrated Camera device (Device Manager → Cameras)

All USB Root Hub and Generic USB Hub entries (Device Manager → Universal Serial Bus controllers)

No change in recurrence observed so far, though I'll continue monitoring over the coming days.

4a. Video — Keyboard Ghosting While Typing

I also have a screen recording of the keyboard ghosting occurring during plain typing (no game, no anti-cheat running) — a key continues registering as pressed for a few seconds after being released.

Video (unlisted, keyboard bug): https://youtu.be/zJSI2lGoWnA

5. Cross-Device / Cross-Hardware Corroboration

A friend of mine owns an HP Victus laptop running a completely stock, non-customized Windows 11 installation (no debloat scripts, no third-party tweaks). They have independently reported similar camera glitches, though less frequent than what I'm experiencing. Since this is a different OEM, different hardware, and a fully stock OS configuration, I think this is meaningful evidence that the issue isn't specific to my particular software setup.

6. On the "Compare Against Stock Windows" Suggestion

I understand this would be the most conclusive test remaining on my end specifically. My system uses a customized Windows 11 installation (a widely-used, open-source community debloat/telemetry-reduction tool, applied via a custom unattended answer file at install time — screenshots of my exact tweak selections attached for transparency).

A few points on this:

I have used this exact same tool and process successfully on this same physical machine in previous Windows installations, without these symptoms occurring.

Reviewing my selected tweaks, none of them modify USB power management settings, PnP configuration, or camera/keyboard/HID drivers directly.

Combined with the HP Victus data point above (stock install, same general symptom), I currently lean toward this not being specific to my configuration — but I fully recognize that a controlled side-by-side test on my exact hardware would be more conclusive than reasoning from these two points alone, and I'm open to attempting that if it would meaningfully help the investigation.

Attachments

energy-report.html (full powercfg /energy output)

Event Viewer 3-day query output

Get-PnpDevice output confirming camera VID/PID match

CTT WinUtil tweak selection screenshots (Tweaks tab, AppX Removal tab)

Camera bug video (unlisted): https://youtu.be/phUgcuqHOyU

Keyboard ghosting video (unlisted): https://youtu.be/zJSI2lGoWnA

Happy to run any further diagnostics that would help narrow this down. Thanks again for the guidance so far.
PowerShell Commands & Output

PS C:\Users\Msi> powercfg /energy /duration 60 Enabling tracing for 60 seconds... Observing system behavior... Analyzing trace data... Analysis complete. Energy efficiency problems were found. 6 Errors 11 Warnings 43 Informational See C:\Users\Msi\energy-report.html for more details. PS C:\Users\Msi> Get-PnpDevice | Where-Object {$_.InstanceId -like "*VID_30C9&PID_0042*" -or $_.InstanceId -like "*VID_1EA7&PID_0064*"} | Format-List FriendlyName, InstanceId, Class FriendlyName : HID-compliant vendor-defined device InstanceId : HID\VID_1EA7&PID_0064&COL01\6&28ED4684&0&0000 Class : HIDClass FriendlyName : USB Input Device InstanceId : USB\VID_1EA7&PID_0064\5&129312F6&0&4 Class : HIDClass FriendlyName : USB Input Device InstanceId : USB\VID_1EA7&PID_0064\5&129312F6&0&5 Class : HIDClass FriendlyName : HID-compliant mouse InstanceId : HID\VID_1EA7&PID_0064&COL02\6&28ED4684&0&0001 Class : Mouse FriendlyName : HID-compliant vendor-defined device InstanceId : HID\VID_1EA7&PID_0064&COL01\6&163395DF&0&0000 Class : HIDClass FriendlyName : Integrated Camera InstanceId : USB\VID_30C9&PID_0042&MI_00\6&3A218140&0&0000 Class : Camera FriendlyName : HID-compliant mouse InstanceId : HID\VID_1EA7&PID_0064&COL02\6&163395DF&0&0001 Class : Mouse FriendlyName : USB Composite Device InstanceId : USB\VID_30C9&PID_0042\SUNPLUSIT_INC Class : USB PS C:\Users\Msi> Get-Service | Where-Object {$_.Name -match "FrameServer|SensrSvc|WiaRpc|stisvc"} | Format-Table Name, DisplayName, Status, StartType Name DisplayName Status StartType ---- ----------- ------ --------- FrameServer Windows Camera Frame Server Running Manual FrameServerMonitor Windows Camera Frame Server Monitor Stopped Manual SensrSvc Sensor Monitoring Service Stopped Manual StiSvc Windows Image Acquisition (WIA) Running Automatic WiaRpc Still Image Acquisition Events Stopped Manual PS C:\Users\Msi> Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-3)} | Where-Object {$_.LevelDisplayName -in @('Error','Warning') -and ($_.ProviderName -match 'Kernel-PnP|usbhub|USB|Camera|WUDF|Kernel-Power')} | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List [29 entries returned, all identical in pattern — alternating between two Device IDs, both under Microsoft-Windows-Kernel-PnP, Event ID 219, Warning level:] TimeCreated : 2-9-26 12:56:04 ProviderName : Microsoft-Windows-Kernel-PnP Id : 219 LevelDisplayName : Warning Message : The driver \Driver\WUDFRd failed to load. Device: {DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD}\DetectionVerification\5&4fe470&0&0 Status: 0xC0000365 TimeCreated : 2-9-26 12:56:03 ProviderName : Microsoft-Windows-Kernel-PnP Id : 219 LevelDisplayName : Warning Message : The driver \Driver\WUDFRd failed to load. Device: PCI\VEN_8086&DEV_461D&SUBSYS_13C71462&REV_02\3&11583659&0&20 Status: 0xC0000365 [... pattern repeats identically at: 2-9-26 03:28, 1-9-26 22:34, 1-9-26 20:50, 1-9-26 20:39, 1-9-26 13:49, 1-9-26 13:33, 31-8-26 23:25, 31-8-26 22:30, 31-8-26 16:06, 31-8-26 12:24, 30-8-26 20:38, 30-8-26 18:23, 30-8-26 16:13, 30-8-26 16:10 — same two Device IDs, same Event ID 219, same Status 0xC0000365, roughly every few hours across the 3-day window] Note: Device {DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD} is a generic detection-verification GUID; Device PCI\VEN_8086&DEV_461D is an Intel Alder Lake thermal/DPTF participant device (CPU thermal management) — unrelated to the camera or keyboard as far as I can determine. No Event Viewer entries in this window correlate directly to camera or keyboard failures.

powercfg /energy — Key Findings (energy-report.html)

System: MSI Katana 15 B12UDXK | BIOS E1585IMS.31A (08/26/2025) | OS Build 26200 | Plugged in

Errors (6 total) — most relevant:

USB Suspend: USB Device not Entering Selective Suspend This device did not enter the USB Selective Suspend state. Processor power management may be prevented when this USB device is not in the Selective Suspend state. Device Name: USB Composite Device Host Controller ID: PCI\VEN_8086&DEV_51ED Device ID: USB\VID_30C9&PID_0042 (confirmed = Integrated Camera via Get-PnpDevice above) Port Path: 6

USB Suspend: USB Device not Entering Selective Suspend Device Name: USB Input Device Host Controller ID: PCI\VEN_8086&DEV_51ED Device ID: USB\VID_1EA7&PID_0064 (confirmed = HID-compliant mouse/touchpad via Get-PnpDevice above, not the keyboard) Port Path: 5

Other errors flagged: Sleep timeout disabled (expected, deliberately configured), a browser execution-required request (Brave), high average CPU utilization during trace (9.26%), and PCIe ASPM disabled (flagged by the platform itself as a known hardware incompatibility, not something I configured).

Sleep state support:

S1/S2/S3 Sleep: Not supported

S4 (Hibernate): Supported (currently disabled by my own configuration)

Connected Standby (S0 Low Power Idle / Modern Standby): Supported and active

Battery: Design Capacity 52,007 mWh → Last Full Charge 33,459 mWh (~64% of original capacity, unrelated to this issue, just for reference)

Video Evidence (Unlisted YouTube)

Camera bug (flicker → Code 45 → auto-recovery): https://youtu.be/phUgcuqHOyU

Keyboard ghosting while typing: https://youtu.be/zJSI2lGoWnA

Attachments (screenshots referenced inline)

CTT WinUtil — Tweaks tab selections (Essential + Advanced tweaks)

CTT WinUtil — AppX Removal tab selections

energy-report.html (full report, summarized above)
PowerShell Commands & Output

PS C:\Users\Msi> powercfg /energy /duration 60

Enabling tracing for 60 seconds... Observing system behavior... Analyzing trace data... Analysis complete. Energy efficiency problems were found. 6 Errors 11 Warnings 43 Informational See C:\Users\Msi\energy-report.html for more details.

PS C:\Users\Msi> Get-PnpDevice | Where-Object {$.InstanceId -like "VID_30C9&PID_0042" -or $.InstanceId -like "VID_1EA7&PID_0064"} | Format-List FriendlyName, InstanceId, Class

FriendlyName : HID-compliant vendor-defined device InstanceId : HID\VID_1EA7&PID_0064&COL01\6&28ED4684&0&0000 Class : HIDClass

FriendlyName : USB Input Device InstanceId : USB\VID_1EA7&PID_0064\5&129312F6&0&4 Class : HIDClass

FriendlyName : USB Input Device InstanceId : USB\VID_1EA7&PID_0064\5&129312F6&0&5 Class : HIDClass

FriendlyName : HID-compliant mouse InstanceId : HID\VID_1EA7&PID_0064&COL02\6&28ED4684&0&0001 Class : Mouse

FriendlyName : HID-compliant vendor-defined device InstanceId : HID\VID_1EA7&PID_0064&COL01\6&163395DF&0&0000 Class : HIDClass

FriendlyName : Integrated Camera InstanceId : USB\VID_30C9&PID_0042&MI_00\6&3A218140&0&0000 Class : Camera

FriendlyName : HID-compliant mouse InstanceId : HID\VID_1EA7&PID_0064&COL02\6&163395DF&0&0001 Class : Mouse

FriendlyName : USB Composite Device InstanceId : USB\VID_30C9&PID_0042\SUNPLUSIT_INC Class : USB

PS C:\Users\Msi> Get-Service | Where-Object {$_.Name -match "FrameServer|SensrSvc|WiaRpc|stisvc"} | Format-Table Name, DisplayName, Status, StartType

Name DisplayName Status StartType

FrameServer Windows Camera Frame Server Running Manual FrameServerMonitor Windows Camera Frame Server Monitor Stopped Manual SensrSvc Sensor Monitoring Service Stopped Manual StiSvc Windows Image Acquisition (WIA) Running Automatic WiaRpc Still Image Acquisition Events Stopped Manual

PS C:\Users\Msi> Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-3)} | Where-Object {$.LevelDisplayName -in @('Error','Warning') -and ($.ProviderName -match 'Kernel-PnP|usbhub|USB|Camera|WUDF|Kernel-Power')} | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List

[29 entries returned, all identical in pattern — alternating between two Device IDs, both under Microsoft-Windows-Kernel-PnP, Event ID 219, Warning level:]

TimeCreated : 2-9-26 12:56:04 ProviderName : Microsoft-Windows-Kernel-PnP Id : 219 LevelDisplayName : Warning Message : The driver \Driver\WUDFRd failed to load.

Device: {DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD}\DetectionVerification\5&4fe470&0&0 Status: 0xC0000365 ```TimeCreated : 2-9-26 12:56:03 ProviderName : Microsoft-Windows-Kernel-PnP Id : 219 LevelDisplayName : Warning Message : The driver \Driver\WUDFRd failed to load. ```yaml Device: PCI\VEN_8086&DEV_461D&SUBSYS_13C71462&REV_02\3&11583659&0&20 Status: 0xC0000365 ```[... pattern repeats identically at: 2-9-26 03:28, 1-9-26 22:34, 1-9-26 20:50, 1-9-26 20:39, 1-9-26 13:49, 1-9-26 13:33, 31-8-26 23:25, 31-8-26 22:30, 31-8-26 16:06, 31-8-26 12:24, 30-8-26 20:38, 30-8-26 18:23, 30-8-26 16:13, 30-8-26 16:10 — same two Device IDs, same Event ID 219, same Status 0xC0000365, roughly every few hours across the 3-day window] Note: Device {DD8E82AE-334B-49A2-AEAE-AEB0FD5C40DD} is a generic detection-verification GUID; Device PCI\VEN_8086&DEV_461D is an Intel Alder Lake thermal/DPTF participant device (CPU thermal management) — unrelated to the camera or keyboard as far as I can determine. No Event Viewer entries in this window correlate directly to camera or keyboard failures. ```scala ## powercfg /energy — Key Findings (energy-report.html) **System:** MSI Katana 15 B12UDXK | BIOS E1585IMS.31A (08/26/2025) | OS Build 26200 | Plugged in **Errors (6 total) — most relevant:** > **USB Suspend: USB Device not Entering Selective Suspend** This device did not enter the USB Selective Suspend state. Processor power management may be prevented when this USB device is not in the Selective Suspend state. > Device Name: **USB Composite Device** Host Controller ID: PCI\VEN_8086&DEV_51ED Device ID: **USB\VID_30C9&PID_0042** *(confirmed = Integrated Camera via Get-PnpDevice above)* Port Path: 6 > **USB Suspend: USB Device not Entering Selective Suspend** Device Name: **USB Input Device** Host Controller ID: PCI\VEN_8086&DEV_51ED Device ID: **USB\VID_1EA7&PID_0064** *(confirmed = HID-compliant mouse/touchpad via Get-PnpDevice above, not the keyboard)* Port Path: 5 Other errors flagged: Sleep timeout disabled (expected, deliberately configured), a browser execution-required request (Brave), high average CPU utilization during trace (9.26%), and PCIe ASPM disabled (flagged by the platform itself as a known hardware incompatibility, not something I configured). **Sleep state support:** - S1/S2/S3 Sleep: **Not supported** - S4 (Hibernate): Supported (currently disabled by my own configuration) - Connected Standby (S0 Low Power Idle / Modern Standby): **Supported and active** **Battery:** Design Capacity 52,007 mWh → Last Full Charge 33,459 mWh (~64% of original capacity, unrelated to this issue, just for reference) ## Video Evidence (Unlisted YouTube) - **Camera bug (flicker → Code 45 → auto-recovery):** [https://youtu.be/phUgcuqHOyU](https://youtu.be/phUgcuqHOyU) - **Keyboard ghosting while typing:** [https://youtu.be/zJSI2lGoWnA](https://youtu.be/zJSI2lGoWnA) ## Attachments (screenshots referenced inline) - CTT WinUtil — Tweaks tab selections (Essential + Advanced tweaks) - CTT WinUtil — AppX Removal tab selections - `energy-report.html` (full report, summarized above)![Screenshot 2026-09-02 133823](/api/attachments/68ab32ff-f845-4e6e-92ea-62e7a9086751?platform=QnA) ![Screenshot 2026-09-02 133915](/api/attachments/06950f13-03da-4f68-863f-e1650d481b0c?platform=QnA) see i have provided whatever u want now pls report to mc abt the bug its just not me pls reply if u need any more info
Aadarsh Prakash 0 Reputation points

2026-09-02T13:35:36.3066667+00:00
Hi Hendrix-V,

Thanks for the detailed suggestions. I worked through all three diagnostic steps you recommended, and I think I've found something concrete. Full details and reasoning below — I have screen recordings of both issues in progress as well, but I'll hold off on linking them directly here and offer them at the end if useful, since my last reply containing external links appears to have been auto-flagged.

1. powercfg /energy — USB Selective Suspend Failure (Camera)

I ran powercfg /energy /duration 60 as Administrator. The report flagged 6 errors, two of which are USB devices failing to enter the Selective Suspend power state:

USB Suspend: USB Device not Entering Selective Suspend This device did not enter the USB Selective Suspend state. Processor power management may be prevented when this USB device is not in the Selective Suspend state. Device Name: USB Composite Device Host Controller ID: PCI\VEN_8086&DEV_51ED Device ID: USB\VID_30C9&PID_0042

I cross-referenced this Device ID against my system's full device list using:

Get-PnpDevice | Where-Object {$_.InstanceId -like "*VID_30C9&PID_0042*"} | Format-List FriendlyName, InstanceId, Class

This confirmed the device is my Integrated Camera (Sunplus IT Inc.), enumerating under both a "Camera" class entry and a "USB Composite Device" entry, both sharing this same VID/PID.

A second device flagged the same error under Device ID USB\VID_1EA7&PID_0064 — I cross-referenced this too and confirmed it's my touchpad/mouse (HID-compliant mouse), not the keyboard.

Why this seems significant: USB Selective Suspend is the exact mechanism Windows uses to power a USB device down during idle and bring it back up on demand. A device failing this negotiation seems like a strong candidate for explaining:

Why the camera intermittently shows Code 45 ("Currently, this hardware device is not connected to the computer")

Why it reliably recovers via a display power-cycle (closing and reopening the laptop lid) rather than staying permanently disconnected — this looks like a failed power-state transition correcting itself on a subsequent power event, not a physical fault

2. The Failure in Progress (Camera)

I have a screen recording capturing the following sequence directly:

The Camera app (Windows Camera) was flickering/showing a broken feed.

I restarted the Camera app itself (not the PC) — flickering continued, unresolved.

I used MSI Center's camera privacy toggle to force-disable and re-enable the camera at the OS level.

Immediately after, Device Manager showed the camera with Code 45.

Approximately 5 seconds later, with no physical interaction with the laptop (lid untouched, no movement), the camera automatically recovered and began working normally.

This sequence seems worth highlighting because the recovery happened with zero physical interaction — difficult to reconcile with a physically damaged cable or connector, since those don't self-correct without mechanical disturbance. It's much more consistent with a timing/race condition in how the camera is re-initialized after its power state is toggled.

3. Event Viewer — 3-Day Window, PnP/USB/Camera/Power Providers

Since I didn't have an exact occurrence timestamp handy, I pulled a broader window:

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-3)} | Where-Object {$_.LevelDisplayName -in @('Error','Warning') -and ($_.ProviderName -match 'Kernel-PnP|usbhub|USB|Camera|WUDF|Kernel-Power')} | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List

The only recurring entries are Microsoft-Windows-Kernel-PnP Event ID 219 (The driver \Driver\WUDFRd failed to load, Status 0xC0000365), occurring roughly every few hours across the 3-day window, alternating between two device references — a generic detection-verification GUID and an Intel Alder Lake thermal/DPTF participant device (PCI\VEN_8086&DEV_461D). As far as I can tell, this is unrelated to camera or keyboard — it's tied to CPU thermal monitoring, not USB/HID/imaging, and I haven't observed any symptom correlating with these specific timestamps.

Nothing in this log correlates directly to the camera or keyboard failures. Worth mentioning explicitly: this suggests the failure may not be throwing a catchable/logged error at all, which would explain why it's been hard to pin down through conventional log analysis.

4. Power Management Checkbox

Unchecked "Allow the computer to turn off this device to save power" on the Integrated Camera specifically, and on all USB Root Hub / Generic USB Hub entries. No change in recurrence observed so far.

5. Keyboard Ghosting — Additional Detail

Separately, I have a recording of the keyboard ghosting occurring during plain typing (no game, no anti-cheat running) — a key continues registering as pressed for a few seconds after being released. This also reproduces on an external USB keyboard, ruling out internal hardware (ribbon cable, EC, keyboard matrix) as the cause, and correlates specifically with boot, wake-from-sleep, and screen-unlock events rather than sustained use duration.

6. Additional Device Class Affected — NVIDIA GPU / Audio on Resume

Worth adding as further context: I've also experienced NVIDIA GPU-related resume issues for several months — audio stutter/glitching immediately after wake, occasional full freezes/crashes, and the display forcing a 60Hz refresh rate lock after lid-close/resume (my panel supports up to 144Hz) when running in Discrete GPU mode. These persist despite full Windows reinstalls and fresh NVIDIA driver installs, ruling out a corrupted driver install as the cause.

Notably, I do not see any of these symptoms (60Hz lock, audio stutter, freezes) when using the laptop's Intel iGPU instead of the discrete GPU — the issue appears specific to the dGPU's resume/power-state path, not a general display or audio driver problem.

Given this is a fourth distinct device class (audio and display, on top of camera and keyboard) showing similar power-state/resume-related symptoms, I think this supports the broader pattern of a systemic issue in Windows' sleep/wake device re-initialization on this platform, rather than several unrelated coincidental faults.

7. Cross-Device / Cross-Hardware Corroboration

A friend of mine owns an HP Victus laptop running a completely stock, non-customized Windows 11 installation. They have independently reported similar (though less frequent) camera glitches — different OEM, different hardware, fully stock OS. This makes me more confident the issue isn't specific to my particular software configuration.

8. On the "Compare Against Stock Windows" Suggestion

I understand this would be the most conclusive test remaining on my end specifically. My system uses a customized Windows 11 installation via CTT WinUtil (Chris Titus Tech's widely-used, open-source debloat/telemetry-reduction tool), applied via a custom unattended answer file at install time. I've attached screenshots of my exact selections (Tweaks tab and AppX Removal tab) for full transparency.

I have used this exact same tool and process successfully on this same physical machine in previous Windows installations, without these symptoms occurring. Reviewing my selections against what's shown in the attached screenshots, none of them modify USB power management, PnP configuration, or camera/keyboard/HID drivers directly. Combined with the HP Victus data point above (fully stock, no CTT or any debloat tool involved, same general symptom category), I currently lean toward this not being specific to my configuration, though I recognize a controlled side-by-side test on a fully stock install would be more conclusive, and I'm open to attempting that if it would help.

Attached: CTT WinUtil Tweaks tab selections, CTT WinUtil AppX Removal tab selections.

Summary

Across camera, keyboard, touchpad-adjacent USB device, display, and audio, I'm seeing symptoms that consistently correlate with boot, sleep/wake, and unlock transitions rather than sustained use, hardware damage, or a specific application. Devices recover on their own (camera, within seconds; keyboard/audio, via simple resync actions like Ctrl+Alt+Del or a device disable/re-enable) without physical intervention, which points away from physical hardware faults. I've ruled out third-party RGB software, anti-cheat software, a specific optional preview update, and corrupted drivers/OS install through direct testing.

I have screen recordings of both the camera failure/recovery sequence and the keyboard ghosting in progress — essentially physical proof of both issues occurring in real time. I held off on including the links in this post since my previous reply containing external links appears to have been automatically removed. If physical proof of the camera and keyboard issues would help the investigation, please let me know and I'll share the video links directly.

Happy to run any further diagnostics that would help narrow this down. Thanks again for the guidance so far.
Neil D 34,200 Reputation points Volunteer Moderator

2026-09-02T18:52:09.8933333+00:00

If you need to give Microsoft feedback on a problem use the Feedback Hub in windows. You can copy a link to the feedback from this thread.

The Feedback Hub is where the development team are. Microsoft don't visit here.
Hendrix-V 18,515 Reputation points Microsoft External Staff Moderator

2026-09-03T03:27:29.1933333+00:00
Hi Aadarsh Prakash,

Thank you for taking the time to perform such detailed testing and for sharing the results. The additional diagnostics provide much more context and help narrow the focus of the investigation.

The findings from the powercfg /energy report are particularly interesting. Identifying the affected USB devices as the integrated camera and a HID-related device helps establish that multiple devices are experiencing power-management-related behavior. At the same time, the report alone does not conclusively identify the root cause, but it does provide a useful direction for further analysis.

Since the camera behavior was also observed outside of Windows, it may be worthwhile to continue investigating components that are shared across operating systems, such as firmware, platform power management, embedded controller behavior, or device initialization sequences.

As possible next steps, you can try:

1, Generate a Sleep Study report (if supported): powercfg /sleepstudy

Review whether any devices show unusual behavior around resume events.

2, Test in both graphics modes separately:

Intel iGPU mode only

Hybrid mode

Discrete GPU mode

3, Ensure the latest MSI-specific packages are installed:

BIOS

Embedded Controller (EC) firmware

Intel Chipset / DPTF

Camera drivers

Graphics drivers

If practical, compare the behavior with a standard Microsoft Windows installation to determine whether the issue can be reproduced in a fully default environment.
Aadarsh Prakash 0 Reputation points

2026-09-10T11:09:16.59+00:00
Hi Hendrix-V,

Thanks again for the detailed next steps. I've worked through all three, plus found something additional I think is worth flagging separately. Full details below.

1. Sleep Study — Session 328 (Confirmed Failed Sleep Entry)

I ran powercfg /sleepstudy and found one session with a clear, isolated anomaly compared to every other sleep session in the same 7-day report.

Session 328 — 2026-09-02 20:29:58, duration 27:54, on battery Reported state: Sleep | Entry reason: Transition To Sleep | Exit reason: Lid Battery drain during session: 1,175 mWh (4% of battery) while supposedly asleep

DRIPS Histogram (platform deep-idle residency) — every single bucket reads 0, from 100 microseconds up through 16 minutes. The system spent zero time in any low-power platform state for the entire 27:54 duration. This isn't a low percentage — it's a complete absence of low-power residency.

Blocker hierarchy (ranked by active time):

USB xHCI Compliant Host Controller — 97% active (27:14 of 27:54) └─ USB Root Hub (USB 3.0) — 97% active (same duration) └─ USB Input Device (HS07) — 0% active time of its own Intel(R) PEG10 (PCIe root port to dGPU) — 3% active └─ NVIDIA GeForce RTX 3050 Laptop GPU — 2% active └─ System — D0 Total Lag Time: 10,152ms, Count of D3 wake ups: 1 Intel Wi-Fi 6 AX201 — 1% active Intel Smart Sound Technology BUS — 0% active

The key detail: the USB Input Device child attached to the Root Hub shows 0% active time of its own — it wasn't doing anything. Its parent Root Hub and the xHCI Host Controller stayed active for 97% of the session regardless. This points to the host controller itself failing to enter a low-power state independent of actual device workload, not a specific peripheral driver keeping it awake. The camera doesn't appear in this session's blocker tree at all.

Also notable: the NVIDIA dGPU's PCIe root port shows a ~10 second D0 lag and one D3 wake-up during this same session — on the same GPU I've reported separate resume issues for (below).

For comparison, every other sleep session in the same 7-day window shows the USB xHCI controller active only 0–4% of the time, with 93–99% low-power state achieved normally. Session 328 is the sole extreme outlier (one secondary, less severe outlier also exists: Session 118, 13% active, 75% low-power state achieved).

2. Graphics Mode Testing (Camera)

Tested the camera across all three graphics modes (Discrete, Hybrid, Intel iGPU) — no Code 45 reproduced in any mode during this test session. I also physically shook the laptop while the camera was active to rule out a loose connector — no interruption.

I want to be upfront that this is a negative result, not a resolution: given the issue's historically intermittent nature (sometimes days between occurrences), a clean test session doesn't rule anything out — the Session 328 sleep-study data above already confirms the underlying USB controller fault occurred concretely and independent of GPU mode or physical handling.

3. Driver/Firmware Currency

NVIDIA driver: currently 32.0.16.1088, already newer than MSI's own OEM-listed package for this model (610.78, dated 2026-08-21).

Camera: MSI's support page lists no dedicated camera driver for this model at all — it runs on Windows' generic inbox camera class driver.

BIOS: E1585IMS.31A, confirmed current against MSI's listing.

I have not installed MSI's older bundled Chipset/DTT packages in roughly 3 years across multiple reinstalls on this machine, and general system behavior (thermal management, Dynamic Boost, etc.) has remained stable throughout, so I don't believe this is a contributing factor, though I'm open to revisiting it if there's a specific reason to suspect it.

4. New/Escalating Symptom — Full System Hang on Wake

I want to flag this as a distinct, more severe symptom that I've been experiencing for over a month, separate from the recoverable issues above: on some lid-close/sleep cycles, the system fails to wake at all — sometimes the display stays off while the keyboard backlight remains on, sometimes both are off — and the machine is fully unresponsive in either state. This requires a forced hard shutdown to recover; there is no soft recovery method that works once it happens.

This is a different severity tier from the camera/keyboard issues, which self-recover or recover via a simple resync. This does not.

Notably, this also does not occur in Hybrid or Intel iGPU mode — only when the Discrete GPU is active — consistent with the dGPU resume issues I described previously (60Hz refresh lock, audio stutter). The outcomes on a dGPU-mode wake appear to vary randomly between: correct wake at full refresh rate, degraded wake (60Hz fallback), or full hang — from what looks like the same trigger (lid open). This inconsistency across identical trigger conditions seems more consistent with a timing-dependent race condition during the wake sequence than a fixed hardware fault, since a physical/firmware wiring issue would be expected to fail the same way consistently.

I don't yet have a Minidump captured from one of these hangs (checking C:\Windows\Minidump after the fact has not turned one up so far, possibly because the hang is total enough that Windows doesn't get to write one) — I'll keep checking after future occurrences.

5. Possible Compounding Factor — MsIo64.sys

While investigating separately, I found that my system has MsIo64.sys currently loaded and running:

PS C:\Users\Msi> driverquery /v | findstr /i "msi" MSIO MSIO MSIO Kernel System Running OK TRUE FALSE ... \??\C:\WINDOWS\system32\drivers\MsIo64.sys

This driver (used by MSI Center/Mystic Light for low-level port I/O and EC-adjacent hardware access) has multiple publicly documented kernel vulnerabilities — CVE-2020-17382, CVE-2021-27965 (stack buffer overflows allowing privilege escalation to SYSTEM), and CVE-2019-18845 (arbitrary physical memory mapping). It's listed on public vulnerable-driver-tracking resources (LOLDrivers) as a known kernel exploitation vector.

I raise this because Microsoft's Vulnerable Driver Blocklist enforcement (active by default on Windows 11 22H2+ when HVCI/Memory Integrity is on) has documented inconsistencies in how certain block rules are applied depending on system state (I found reference to CVE-2025-59033 describing exactly this kind of inconsistent enforcement). Given MSI Center's low-level driver may be involved in EC-adjacent power signaling, I wonder whether inconsistent blocklist enforcement of this specific driver across boots could be a contributing or compounding factor to the inconsistent camera/keyboard/wake behavior — separate from, or in addition to, the USB controller suspend issue already confirmed above. I have not yet confirmed this directly (e.g., via CodeIntegrity Operational log entries) but wanted to flag it as a possible lead.

Summary

Across camera, a HID-related USB device, the NVIDIA dGPU, audio, and now full system wake reliability, I'm seeing symptoms that consistently correlate with boot, sleep/wake, and unlock transitions, with outcomes that vary between full recovery, degraded recovery, and (in the dGPU case) complete hang — rather than a fixed, consistent failure. This pattern, combined with the confirmed Session 328 data, continues to point toward a timing/power-state-negotiation issue during resume rather than physical hardware, application software, or a specific outdated driver.

Happy to run further diagnostics, including checking CodeIntegrity logs for the MsIo64.sys angle, or anything else that would help narrow this down.

Windows update bugs with cam keyboard and fingerprint

Bug Report: Intermittent Keyboard Ghosting and Webcam Disconnection (Code 45) Following Boot/Wake/Unlock Events — Windows 11

Summary

Primary Affected Device

Issue 1: Keyboard Input Ghosting / Stuck Keys

Issue 2: Webcam Intermittent Disconnection (Device Manager Code 45)

Environment Notes

Broader Pattern Observed (Anecdotal, Different Devices)

Request

1 answer

Follow-up Reply Draft — Microsoft Community Forum

1. `powercfg /energy` — USB Selective Suspend Failure (Camera)

2. Screen Recording of the Failure in Progress

3. Event Viewer — 3-Day Window, PnP/USB/Camera/Power Providers

4. Power Management Checkbox

4a. Video — Keyboard Ghosting While Typing

5. Cross-Device / Cross-Hardware Corroboration

6. On the "Compare Against Stock Windows" Suggestion

Attachments

powercfg /energy — Key Findings (energy-report.html)

Video Evidence (Unlisted YouTube)

Attachments (screenshots referenced inline)

PowerShell Commands & Output

1. `powercfg /energy` — USB Selective Suspend Failure (Camera)

2. The Failure in Progress (Camera)

3. Event Viewer — 3-Day Window, PnP/USB/Camera/Power Providers

4. Power Management Checkbox

5. Keyboard Ghosting — Additional Detail

6. Additional Device Class Affected — NVIDIA GPU / Audio on Resume

7. Cross-Device / Cross-Hardware Corroboration

8. On the "Compare Against Stock Windows" Suggestion

Summary

1. Sleep Study — Session 328 (Confirmed Failed Sleep Entry)

2. Graphics Mode Testing (Camera)

3. Driver/Firmware Currency

4. New/Escalating Symptom — Full System Hang on Wake

5. Possible Compounding Factor — MsIo64.sys

Summary

Your answer

Windows update bugs with cam keyboard and fingerprint

Bug Report: Intermittent Keyboard Ghosting and Webcam Disconnection (Code 45) Following Boot/Wake/Unlock Events — Windows 11

Summary

Primary Affected Device

Issue 1: Keyboard Input Ghosting / Stuck Keys

Issue 2: Webcam Intermittent Disconnection (Device Manager Code 45)

Environment Notes

Broader Pattern Observed (Anecdotal, Different Devices)

Request

1 answer

Follow-up Reply Draft — Microsoft Community Forum

1. powercfg /energy — USB Selective Suspend Failure (Camera)

2. Screen Recording of the Failure in Progress

3. Event Viewer — 3-Day Window, PnP/USB/Camera/Power Providers

4. Power Management Checkbox

4a. Video — Keyboard Ghosting While Typing

5. Cross-Device / Cross-Hardware Corroboration

6. On the "Compare Against Stock Windows" Suggestion

Attachments

powercfg /energy — Key Findings (energy-report.html)

Video Evidence (Unlisted YouTube)

Attachments (screenshots referenced inline)

PowerShell Commands & Output

1. powercfg /energy — USB Selective Suspend Failure (Camera)

2. The Failure in Progress (Camera)

3. Event Viewer — 3-Day Window, PnP/USB/Camera/Power Providers

4. Power Management Checkbox

5. Keyboard Ghosting — Additional Detail

6. Additional Device Class Affected — NVIDIA GPU / Audio on Resume

7. Cross-Device / Cross-Hardware Corroboration

8. On the "Compare Against Stock Windows" Suggestion

Summary

1. Sleep Study — Session 328 (Confirmed Failed Sleep Entry)

2. Graphics Mode Testing (Camera)

3. Driver/Firmware Currency

4. New/Escalating Symptom — Full System Hang on Wake

5. Possible Compounding Factor — MsIo64.sys

Summary

Your answer

1. `powercfg /energy` — USB Selective Suspend Failure (Camera)

1. `powercfg /energy` — USB Selective Suspend Failure (Camera)