Hi,
To those having an issue double check if you
have an Optional Update in Windows Update.
There was a new .xxxx build that was supposed to
fix issues with the KB5101650.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I use my computer every day, I run jobs all night. KB5100998 KB5101650 have rendered my input device unusable, interrupted last nights job, rebooted without my permission. I cannot get the input to work , it was working perfectly. If I had my preferences it would be update every 3 months, and when I choose to so I can prepare. Random haphazard WITHOUT WARNING updates and reboots cause irreparable harm . It needs to end, stop. Send an email indicating a reboot and updates i necessary, maybe place a warning on the screen, but email is better. Random hijacking at night is vandalism.
Hi,
To those having an issue double check if you
have an Optional Update in Windows Update.
There was a new .xxxx build that was supposed to
fix issues with the KB5101650.
I experienced a repeatable issue while installing KB5101650 on Windows 11. The update consistently froze at around 70%. The mouse could still move, but Windows became unresponsive.
To investigate, I correlated the freeze times with Windows Update activity in Reliability Monitor and Event Viewer. I then collected dump files from:
C:\Windows\LiveKernelReports\ResourceTimeout\
I analyzed the dumps in WinDbg by reviewing the blocked threads, call stacks, synchronization objects, current processes, and loaded file-system filter drivers.
The dump analysis indicated that threads involved in servicing and file-system operations were repeatedly waiting for resources while Windows was creating, modifying, or deleting files. The system appeared to enter a deadlock-like or indefinite wait loop: one operation was waiting for a resource that could not be released because other dependent file-system operations were also blocked.
This explains why the computer did not immediately crash. Some parts of the system, such as mouse movement, were still functioning, while the servicing and file-system paths remained stuck in the wait loop.
Because the blocked activity involved NTFS file operations and resource accounting, I checked features that interact directly with NTFS. I found that NTFS Disk Quota was enabled on the C: drive.
I then performed a controlled comparison:
With Disk Quota enabled, KB5101650 repeatedly froze during installation.
I temporarily disabled Disk Quota on the C: drive.
I installed KB5101650 again.
The update completed successfully, and Windows restarted normally.
I re-enabled Disk Quota afterward, and the system remained stable.
The workaround in my case was:
Temporarily disable NTFS Disk Quota → install KB5101650 → restart Windows → enable Disk Quota again.
The dump did not conclusively prove the exact internal root cause, but it strongly suggested that the update triggered file-system resource contention that led to an indefinite wait or deadlock-like loop. The enabled/disabled Disk Quota comparison was reproducible on my machine.