- May 19, 2011
- 20,983
- 16,229
- 136
I couldn't find the thread(s) where the issue has been discussed here so I started a new one.
I've encountered it for the second time on different setups and I notice that there are a fair few threads on the Internet about it.
I tried some ideas on it which didn't help:
1 - Downloaded and force-installed the latest Windows Update Agent
2 - Nuked SoftwareDistribution folder
3 - Installed latest Windows Installer (an old WU bug cited it as a cause)
4 - Replaced the SD folder with a known-working one*
5 - Nuked the SD folder on a believed-to-be-working XP setup I had**
6 - Switched from Windows Update to Microsoft Update.
7 - Restarted the service several times.
* - out of curiosity to see what would happen
** - my XP VM setup had the problem initially but I hadn't see it since and I hadn't had any problems installing updates since. After nuking the SD folder the issue re-surfaced.
On my XP VM setup (using one core of my Ph2X4) it took about half an hour I think. On an Athlon 64 3200+ machine that was the main one I had problems with, I first updated to XP SP3 with the standalone installer then tried Windows Update and experienced the issue.
I monitored both setups with filemon while the problem was in effect and there were occasional writes to an edb file in the SD folder (Datastore.edb IIRC). In windowsupdate.log the last thing mentioned after the saturation started was the http retrieval/processing of a file from the Windows Update site.
One idea I had that I didn't follow up with was the installation of all the .net frameworks that a fully patched XP SP3 usually ends up with, but I wanted to see whether 'wait and see' really did the trick.
Another idea (which I think is unlikely to help) was to feed it the package update by hand to begin with. Unfortunately I didn't take a note of the KB number, but since I experienced the issue before and after this update was installed, I doubt it will help.
I honestly think it is a case of wait and see. On the A64 3200+, if I had to guess I'd say it took 3-5 hours with the CPU at 100% (hard to say as I restarted the service a few times and I didn't take notes of exactly when I nuked the SD folder).
After getting the initial ~130 updates I haven't noticed the CPU saturation problem.
My feeling is that after the initial load of updates the problem won't happen any more and that it is a data issue inside the SoftwareDistribution folder.
I've encountered it for the second time on different setups and I notice that there are a fair few threads on the Internet about it.
I tried some ideas on it which didn't help:
1 - Downloaded and force-installed the latest Windows Update Agent
2 - Nuked SoftwareDistribution folder
3 - Installed latest Windows Installer (an old WU bug cited it as a cause)
4 - Replaced the SD folder with a known-working one*
5 - Nuked the SD folder on a believed-to-be-working XP setup I had**
6 - Switched from Windows Update to Microsoft Update.
7 - Restarted the service several times.
* - out of curiosity to see what would happen
** - my XP VM setup had the problem initially but I hadn't see it since and I hadn't had any problems installing updates since. After nuking the SD folder the issue re-surfaced.
On my XP VM setup (using one core of my Ph2X4) it took about half an hour I think. On an Athlon 64 3200+ machine that was the main one I had problems with, I first updated to XP SP3 with the standalone installer then tried Windows Update and experienced the issue.
I monitored both setups with filemon while the problem was in effect and there were occasional writes to an edb file in the SD folder (Datastore.edb IIRC). In windowsupdate.log the last thing mentioned after the saturation started was the http retrieval/processing of a file from the Windows Update site.
One idea I had that I didn't follow up with was the installation of all the .net frameworks that a fully patched XP SP3 usually ends up with, but I wanted to see whether 'wait and see' really did the trick.
Another idea (which I think is unlikely to help) was to feed it the package update by hand to begin with. Unfortunately I didn't take a note of the KB number, but since I experienced the issue before and after this update was installed, I doubt it will help.
I honestly think it is a case of wait and see. On the A64 3200+, if I had to guess I'd say it took 3-5 hours with the CPU at 100% (hard to say as I restarted the service a few times and I didn't take notes of exactly when I nuked the SD folder).
After getting the initial ~130 updates I haven't noticed the CPU saturation problem.
My feeling is that after the initial load of updates the problem won't happen any more and that it is a data issue inside the SoftwareDistribution folder.