wuaueng.dll using 50% CPU for hours (Can't check for updates)

I think I fixed the issue by disabling "updates for other Microsoft products (microsoft update)". And I also disabled "updates from more than one place" for the heck of it even though that probably didn't make a difference.

Now I remember back in XP days of the same issues. Microsoft Update could kill certain computers and take forever using high CPU. After disabling that and enabling Windows Update those computers worked a lot better. I suppose that update process is still plaguing the current iteration of Windows.

EDIT: I just turned on another comp and was trying to do windows updates, and that had the same issue with Microsoft Update. It's an AMD E1-1200 AIO. The same as above was taking forever to run, but it was a lot quicker than hours on end as with the above computer. I think it's just a general Windows 10 issue and nothing related to my individual computers.

EDIT2: It's happening again on the 3rd computer. I may have to disable Microsoft Update. It has a Pentium dual core 2GHz w/4GB of RAM. One core is maxed out just "thinking" about windows updates. It says "Downloading updates 0%". What the heck, I thought Windows 8 & 10 were supposed to run better on slower computers? I see them for sale all the time with even 1GHz processors.

I just ran into this issue myself. I was updating a bunch of apps in the Windows Store and it said "Installing" for two apps and a third one was downloading when all updates got stuck. svchost.exe responsible for Windows Update kept eating CPU cycles and Process Explorer lists wuaueng.dll!WUCreateExpressionEvaluator in the call stack of the respective thread (but it's the wrong function since it lacks symbols I think).

I followed your steps to record with Windows Performance Analyzer and obtained a 60 sec trace. I don't think there's anything interesting apart from the stack trace with symbols but I can upload the trace if anyone wants to take a closer look. The stack trace is:

Line #, Process, Stack, Count, Weight (in view) (ms), TimeStamp (s), % Weight
1, svchost.exe (1064), [Root], 61085, 61.085,271996, , 15,12
2, ,   ntdll.dll!RtlUserThreadStart, 61085, 61.085,271996, , 15,12
3, ,   kernel32.dll!BaseThreadInitThunk, 61085, 61.085,271996, , 15,12
4, ,   wuaueng.dll!CWorkItemManager::ExecuteWorkItemWrapper, 61085, 61.085,271996, , 15,12
5, ,   wuaueng.dll!CWorkItemManager::ExecuteNonCallbackWorkItem, 61085, 61.085,271996, , 15,12
6, ,   wuaueng.dll!CAgentDownloadManager::ProcessWorkItem, 61085, 61.085,271996, , 15,12
7, ,   wuaueng.dll!CAgentDownloadManager::CheckAllCallDownloadStates, 61085, 61.085,271996, , 15,12
8, ,   wuaueng.dll!CAgentDownloadManager::GenerateAllDownloadRequests, 61085, 61.085,271996, , 15,12
9, ,   |- wuaueng.dll!CAgentDownloadManager::IsShuttingDown, 36753, 36.754,737587, , 9,10
10, ,   |- wuaueng.dll!CAgentDownloadManager::GenerateDownloadRequest, 17637, 17.635,754280, , 4,37
11, ,   |- wuaueng.dll!CDownloadRequestMapEntry::IsComplete, 4632, 4.631,865772, , 1,15
12, ,   |- wuaueng.dll!CAgentDownloadManager::GenerateAllDownloadRequests<itself>, 1489, 1.488,925767, , 0,37
13, ,   |- wuaueng.dll!CSusMap<DownloadManagerUpdateID,CDownloadRequestMapEntry * ptr64,CSusSortedArrayListOpsDownloadManagerUpdateID,CSusArrayListItemOpDelete<CDownloadRequestMapEntry * ptr64> >::get_ValueAt, 572, 571,976252, , 0,14
14, ,   |- ntoskrnl.exe!KiInterruptDispatchNoLockNoEtw, 2, 2,012338, , 0,00

wuaueng.dll!CAgentDownloadManager::GenerateAllDownloadRequests seems to be the culprit. I also created a full dump of svchost.exe just in case. Let me know if you need anything else.

I wonder if Microsoft is using our computers for bitcoin mining. ;)

Or trying to find aliens with Seti@Home or finding the cure for cancer with Folding@Home. ;)

I have been having  this problem on a laptop (celeron,  dual core) running Vista.   After reading these posts,

I turned off windows update and the problem "appears"  to have gone away.  I think it might have started with

the last Vista update which was last summer.   (could there be a problem with handling of Dual Core processors?)

Thanks to all for the comments and suggestion,

Carl

This has gotten worse and worse. On some computers it's a never ending Windows Update. Some I've left it sit for 8 hours and Windows Update process still uses all the CPU.

I've seen some reference to an update KB3145739 to try and fix the issue. For this one Vista computer Windows Update is running and running with no end.

I've received numerous computers in the shop within the last month with more and more customers complaining about slow computers. The only explanation I can give them is that it's Microsoft's fault and that they changed something in Windows Update to kill your computers.

I've also tried fixes for Win 7 from KB3083710 & KB3102810 in Win 7. But why did Microsoft go and fiddle with Windows Update? I'm getting tons of computers in the shop due to WU slowing down.

I, like others, am seeing this on only 32b Windows installations.  It occurs on Windows Vista, 8.1, 7, and 10.  It is the same dynamic link library, and the date stamp actually seems to be either 2016, or 2012 on this file.  It is always this file, running as a thread under svchost.exe and always using 46% to 50% CPU use on one of the cores.

The file seems to be doing a signature check for every single system fine on the system, but in some cases it never seems to progress to the next stage and actually start getting a list of updates.   There seems to be a bug in the file itself, that either runs into problems with other drivers, or virtual file access.  Perhaps this check should ONLY be done BEFORE the user logs into the account?  Like how a disk check, or system files install during a reboot.  I believe these are file access conflicts happening on these systems.

If someone else could look into this and do tests to see if we can narrow it down?

I have tried several tricks, including renaming the file, replacing it, taking ownership and manually turning it on and off, and it seem the update process itself is alright, but there is some sort of access issues with checking IF system files HAVE been updated or changed.  This seems to do some of the jobs the SFC tool does, but in a different way.  As we know, the SFC tool cannot be run while the user is logged on.  I have a suspicion this is a similar issue, and only certain systems with specific memory or north-bridge architecture are having this issue, and only on 32b systems.  This leads me to believe is has something to do with file access issues, and perhaps conflicts because some files are in use.

Anyone have any other ideas?


EDIT: A far more detailed thread, by people who have FAR more experience and skill than the average MVP is available on this forum:
https://www.dslreports.com/forum/r30535980-WIN7-MS-updates-taking-too-long~start=90

I have a suspicion this is a similar issue, and only certain systems with specific memory or north-bridge architecture are having this issue, and only on 32b systems.  This leads me to believe is has something to do with file access issues, and perhaps conflicts because some files are in use.

Anyone have any other ideas?


EDIT: A far more detailed thread, by people who have FAR more experience and skill than the average MVP is available on this forum:
https://www.dslreports.com/forum/r30535980-WIN7-MS-updates-taking-too-long~start=90

I've faced with this issue on a Win10 x64 system. So I don't think that it's a 32-bit issue.

I got fed up with waiting for the older Vista 32b workstation to update (two solid days it was supposedly searching for updates, lots of CPU activity, but NO I/O activity was a sure sign it had stalled), so I found a way that seems to work.

0) locate and download the latest kernel update for that month, save somewhere locally.
1) Attempting to install the kernel update will result in the "Search for Updates" annoyance

2) open services.msc
3) Restart: Windows Update service, Background Intelligent Transfer Service, and Cryptographic Services.  (the kernel patch you were running, will fail (you want this), with an event logged in the 'Setup' section of 'Windows Logs' mentioning "wusa.exe" with an ID of 3) 
4) Retry the kernel patch, and it should install now.

5) Reboot

6) Run Widows Update, and let it work.  It should find all the latest updates after a while, but not just run endlessly like it did before.

Restarting those three services will allow you to install one patch, then reboot, for anything critical, but the reboot will likely reset the endless searching.  You must still reboot as registry keys are only written on a shutdown cycle correctly.  The wait times and annoyance factor seems to vary WIDELY from system to system.  Some systems produce have various system errors, enormous stores of backups, in the C:\Windows\winsxs folder, or various other issues resulting in this highly annoying recursive searching.  I still have a feeling it has to do with locked files, but too busy to test on enough systems to state that for a fact.

You can always head over to https://technet.microsoft.com/en-us/library/security/dn631937.aspx and manually download the most important stuff, then use the restarting of the services to get them in if things become really annoying again.

Consider this a workaround, not a fix, not perfect, but it seems to work with the most annoying systems.  Doing things in the correct order seems important at times.  Oh, and disable the AV software before you set Windows searching for updates, it just makes the process all that much longer on anything less than a quad-core.

I hope this helps.

It appears Microsoft has finally fixed this issue a while back by updating the Windows Update Engine (July 2016). Check the version and date of file "wuaueng.dll" inside \windows\system32\ directory. If the date is 5/13/16 or newer or the version is 7.6.7601.23453 or newer you're good to go. If it's older than that you should update your Windows Update Engine before trying to check for updates.

At least for Windows 7, you'll need to download "Windows6.1-KB3172605-x64.msu". If the date of your WU is maybe 2015 or 2014, you may also need "Windows6.1-KB3020369-x64.msu" which is a prerequisite of the first update. You'll definitely need the prerequisite update if the first doesn't install and says it's not applicable to your installation.

https://support.microsoft.com/en-us/kb/3172605

https://support.microsoft.com/en-us/kb/3020369

I'd imagine for Windows 10 this is all automatic. For Windows 7, definitely if it's a new install or hasn't had updates in a long time, update the WU Engine first, then updates will process a lot faster.

I'm not sure how this works with Vista, but I'd imagine you'll need to update the WU Engine also, I'm just not sure the exact process to do that.

May want to try: https://support.microsoft.com/en-us/kb/3185319

Or read: http://www.bleepingcomputer.com/forums/t/611898/windows-vista-update-hangs-at-checking-for-updates/page-9