XPost: alt.comp.os.windows-11
From: nospam@needed.invalid
On Mon, 1/26/2026 10:11 AM, Frank Slootweg wrote:
> chrisv wrote:
>> Frank Slootweg wrote:
>>
>>> CrudeSausage wrote:
>>>>
>>>> You're going to tell me that you've never had an update take hours to
>>>> complete?
>>>
>>> Indeed, I never had that. We're talking Windows 11 here, which mostly
>>> uses modern hardware (because of TPM and stuff) and probably SSDs.
>>
>> I've not seen it on Win11, but I know that earlier versions (can't
>> remember if it was 7 or 10 or both) had a problem that could cause
>> updates to take hours. There were a couple of individual updates that
>> could be done first, to "fix" this problem.
>
> Yes, a few hours (two?) in the *past*, on older hardware ('small' RAM,
> no SSD), but most of that was *online* time, i.e. the system was still
> up, but 'just' busy'. But a quick perusal of the video transcript, talks
> about 7 hours of *offline* time (i.e. restarting/rebooting). *If* that
> ever happened on a modern, sufficiently specced system, then something
> was seriously wrong and that's by no means typical. Trying to spread it
> as typical/common is just FUD, click-bait, etc..
>
Typically when that happens, it's because the offline update
phase is "parked". I find that the only stimulus that makes any
difference, is unplugging the network cable. And it doesn't
happen instantly either. It might take 30 seconds before
you notice a few blinks of the disk light.
And while this is happening, you have the juggling balls on the screen.
Whether it is a deadlock in some code, or an intentional
timer-based activity, I don't really know of good ways to check.
While you can start collecting a trace with Process Monitor,
and collect a shutdown trace and a boot trace, I don't know
what you could expect to find in there. The ETW subsystem could
be shut down, at the point where the machine is not making
forward progress on the Update queued.
Paul
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
