dencorso

That's why it's best to keep using Office 2003.

@all: I really think everybody has already made each POV very clear. So, at this point, I'll ask you all a favor: let's pause this thread here. Or, at the very least, give it a voluntary 24h respite. Thanks!

Maybe the reply bot got lazy... Then again maybe it's still on its to-do list, but with all those new IoT garden-sprinklers to spam, it wasn't able to do it just yet...

"Upbreak", perhaps?

Verschlimmbesserung, anyone?

It's not an easy task, it demands time and patience. And time-consuming hard work. I really doubt it's worth it, in this case. Just my 2 ¢, of course! Dependency Walker will show you the dependencies of an executable module (.dll, .exe or .sys). It's not capable of modifying a module, though.

Just for the record 49.0.2623.108 m is not the very last version for XP. I just got 49.0.2623.110 m a few minutes ago.

Here's further confimation of NoelC's findings:

@jaclaz: No, we ain't. xper already moved us to 4.1.9. BTW: @jaclaz & @submix8c: Stop going "OT" and keep "OT", will you?

That's because Win 10 actually *is* slower and more bloated than anything that has come before...

Change your password, just in case.

Thank you for the report, sdt! Your experience squares with mine, in that it seems that different hardware platforms need different update combinations to overcome the WU/MU slowness, while some machines need none. I interpret this as meaning there probably are more than one issue behind the same symptoms.

Disconnect the power cable from the wall. Wait until any lighted LEDs turn off. Wait for one minute more. Disconnect All SATA devices (SSD/HDD/CD/DVD/Blu-Ray). Reconnect the power cable to the wall outlet, start the machine, then enter BIOS. Does it still freeze within 15 sec?

Stanford TugBots - while not yet drones, looks like that's the next step (or maybe tug)... http://www.bbc.com/news/technology-35810224

No. I think it may have been superseded by one or more of the later WU/MU updates, despite MS declaring "this update doesn't replace a previously released update" for any of the subsequent "Windows Update Client for Windows 7 and Windows Server 2008 R2: Month Year", fact is KB3102810 is effectively the November 2015 version of that patch series (for which only the January 2016 wasn't released, AFAIK), although it's not named accordingly... So, reasoning in this line, I guess you probably have KB3138612, or it's predecessor on the system, and I suspect they are, in fact, cumulative. If so, try to remove the latest "Windows Update Client for Windows 7 and Windows Server 2008 R2: Month Year". and see whether the slowness returns. TIA.

Whether the problem returns. The KB is entitltled "Installing and searching for updates is slow and high CPU usage occurs..." but I have it blocked and never needed it ...

I'm in no hurry. Once you find it, then maybe you can test the importance, if any, that KB3102810 has upon this issue.

Please do remove just KB3102810 ("Installing and searching for updates is slow and high CPU usage occurs in Windows 7 and Windows Server 2008 R2") and test again.

You mean this reply at Woody's? March 18, 2016 at 7:25 pm by jwoods:

Your problem is that one of the files is a UNICODE .txt, while the other is a plain ASCII .txt, and, BTW, that vbs expects both to be plain ASCII.

Hope the beer is good and plentiful!

It is possible some update breaks WU/MU, then causing the fix to be required. I did not originally wish to imply that the x86 requires the fix, while the x64 does not. The information we have at the moment is still too scanty to draw any conclusions. Processor manufacturer, number of cores and or ammount of RAM present may all be factors, too...

Some people seem to need KB3102810 to be able to complete scans. My 7 SP1 x64 does not. What I posted above (but my post was truncated somehow) is: Do make a full backup. Add KB3102810. Do the scans complete now? If so, consider keeping it and report on the main thread. If not, redeploy the backup. No one knows whether it's really safe. But there's no report it carries any nag inside, and other types of payload are difficult to detect. So testing with care is required. Nota Bene: Those KBs in the list that have indication of nags and or telemetry are a definite no-no. Those that have almost no documentation (as is the case of those two mentioned by the OP) and refer to the WU/MU system may be tested with due care, but should be avoided unless slowness or malfuction appears.

KB3083710 - Windows Update Client for Windows 7 and Windows Server 2008 R2: October 2015 KB3102810 - Installing and searching for updates is slow and high CPU usage occurs in Windows 7 and Windows Server 2008 R2 So, the answer to: Is: no one really knows this, AFAIK.

.inf mods are always the 1st thing to try, when the driver refuses to just work: in a lot of cases this is just due to the lack of the proper device ID in the right place and nothing more. When that approach fails, then things can be difficult.