Windows – Why does Windows/Microsoft Updates always take a long time to detect available updates

windowswindows updatewindows xp

TL;DR

When you initiate Windows Updates within Windows XP, you are directed to the Windows Updates website. (Assuming you already have the ActiveX, Installer plug-in installed in your browser,) the website displays a green, scrolling status bar and appears to just hang for a few minutes. Why does this step of the update process take such a long time to execute?

I'm not interested in speeding up the process. I just want to know what the updating software is doing since it's not installing software and it's not peaking CPU & network usage. What stalls the process?


It's a common task for many of us who work in any form of IT position using Windows. Eventually you have to install/re-install a version of Windows and what follows is a very long OS updating process.

For a long time I have accepted the fact that this is a slow process and that's all there is to it. There is a lot to download, and some updates require restarts followed by further updates… Ugh!

This morning I had to go through the process of installing Windows XP with SP3. I'm installing the OS on a VM on an SSD and I've been working on this thing for over 6 hours.

Although there are many ways to knit-pick this process for improvements, there is one step that is always particularly slow and I cannot figure out a good reason why.

That step is the update detection step on a manual update. Specifically, when navigating to the Windows (or Microsoft) Updates page, and then clicking the 'Custom' button to detect your updates. It appears that your PC just sits there for a painful amount of time. Check your Task Manager and it looks like your PC is, in fact, locked because your CPU isn't cooking, so something has stalled. I have no clue what's going on or what would cause this?

What is the updating software doing? If the registry was being searched, shouldn't my CPU usage peak?

Does anybody know what's happening? I can loosely justify why some of the steps in the update process take so long. However, this one doesn't seem to have any reasoning.

UPDATE

Just to clarify, I started with a Windows XP with SP3 iso. After the OS installed (which was actually quite fast,) I started the updates. My initial check found well over 100 critical updates and, if memory serves me correctly, over 40 suggested updates.

I had to do a restart-and-update process at least 4 times yesterday. Again, I'm not looking for a justification of the entire process. Instead, when I navigate to the update page (after the ActiveX component has been installed.) What takes the detection process so long, especially since my CPU is barely being used, memory isn't peaking and my network traffic doesn't tend to spike at all?

Best Answer

It seems that there is something broken in XP's update management interface (perhaps related to the use of ActiveX, perhaps related to the use of the cumbersome 5 part IE/ActiveX/WGA/WindowsInstaller/WindowsUpdate system -- compare to Vista & later's WindowsUpdate/WindowsInstaller system, perhaps the problem stems from both). Sadly, I doubt there is enough interest in this problem (or solving it) to get serious reverse engineering talent on it.

Here's what we know so far (thanks to RLH for pointing out the elephant in the room):

  • Installation from known good latest service pack XP media.
  • Issue noticed after installing ActiveX controls for WU -- Running custom update's detection step takes an inordinate amount of time with:
    • No appreciable CPU loading.
    • Minimal memory/IO loading.
    • Minimal bandwidth / network usage.
    • Insufficient disk activity to warrant the significant delay experienced.

One of the things I've taken to doing is installing IE8 & WI version 4.5 before installing the ActiveX controls and it seems to reduce the time that the detection step takes (also prevents potential problems of botched IE8 &/or WI install during automatic updates, which I have seen several times). The downloads can be found here (respectively):

Related Question