We have Windows 7 SP1 (x86 and x64) deployed across our domain, running on hardware that ranges from very old to very new.  A common problem that has started occurring (since the deployment of Windows 7) is that machines with 2 GB of memory will run very slowly during various times of day.

Through process monitoring and live captures, we have narrowed it down to the wuaserv.exe service running inside a svchost.exe process.  The service will consume as much memory as it can, until the machine is unusable.  Stopping the windows update service immediately releases the memory and the box will run in a normal state again.  

There seems to be several others out there who have come across this problem, and all have come up with a couple common answers.  Repair the windows update service (has not worked), or stop using Microsoft Update in favor of Windows Update (not applicable since we use SCCM 2012 SP1 for update management.)  

I can't just change the SCCM setting to stop scanning so frequently, I need to ensure my systems have the updates we've applied, and enforcement is critical.  Even if I reduce the scans, the problem still occurs when the scan kicks off.  This is having a negative impact on our business, and I'm not looking for a workaround.  I need a solution to this problem so we can move forward.

If this is not the right forum for this post, please let me know where this would better fit.  Thanks in advance.

Latest update (4/30/15):  A patch is apparently in development that will address this issue.  There is information here regarding the update:

http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

The post title is a bit misleading, as the patch should apply to the Windows Update client.

I have posted several questions to the blog, none of which have appeared.  I'm not sure why since questions/comments after my submission have been approved. :(

tags:  SCCM high memory svchost.exe wuaserv windows 7 

• Edited by steelie Tuesday, May 19, 2015 8:00 PM

Hi,

Please check the following links :

FIX: When you run Windows Update to scan for updates that use Windows Installer, including Office updates, you may experience a memory leak, or you may receive an error message for the Svchost process

http://support2.microsoft.com/kb/916089/en-us

When you use Automatic Updates to scan for updates or to apply updates to applications that use Windows Installer, you experience issues that involve the Svchost.exe process

http://support.microsoft.com/kb/932494

According to the two links ,this issu seems to be related to the Windows Update Agent.Have you tried to update the Windows Update Agent?

Best regards

• Edited by MeipoXuMicrosoft contingent staff, Moderator Thursday, November 20, 2014 1:01 AM

Hi steelie,

"it could be the machines are just being pushed too hard (with only 2 GBs of memory) "

Considering this issue only occurs in the machines with 2 GBs of memory. This issue is understandable. If it is available,you may need to extend the memory to solve this issue.

Best regards

• Edited by MeipoXuMicrosoft contingent staff, Moderator Monday, December 01, 2014 12:25 PM

hi.

 i know about the CPU issue at windows updates, but you can try this solotions :

the level of use on the CPU svchost process. exe the  WMI comes to 100 percent. In addition, extensive use was made in relation to the size of the largest memory buffer of the WMI.
For example - The computer's boot process takes too long. , and it's slow the user's login

 

The solution that I Recommend to you - is to delete the contents of the folder C:\ WINDOWS system32 \wbem \Repository
But unfortunately you can not delete this folder contents while the system is working without pause the WMI service, so first you have to pause the WMI service and then deleted the folder contents.

 http://answers.microsoft.com/en-us/windows/forum/windows_7-performance/svchostexe-netsvcs-using-a-ton-of-cpu/5f6bb576-219f-4565-b241-96cab321bad3

Thanks,

Israel Chemo

• Proposed as answer by Happy Town Tech Tuesday, April 07, 2015 4:02 PM
• Unproposed as answer by steelie Tuesday, April 07, 2015 5:31 PM

Interesting workaround MeipoXu... I'll give this a shot on some test clients and see if that works.  

Edit:  Rescheduling the task has not been successful.  It still scans during business hours, and the machines are still exhibiting the same behavior.

• Edited by steelie Tuesday, April 21, 2015 12:48 PM

The workaround provided by the marked answer hasn't proved useful for our situation.    

I do agree with you that Microsoft shouldn't ignore the complaints of users who are operating within the specified hardware recommendations.

• Edited by steelie Tuesday, April 21, 2015 12:49 PM

The workaround does not move the scheduled scan to an anticipated window.. and we have also been upping the total ram in boxes with the issue.  We have not had the problem with systems using 4 GBs, so maybe you guys are pushing your systems harder than we do.  Kind of crazy that we've had to add memory just to accommodate an update scan...

• Edited by steelie Tuesday, April 21, 2015 12:50 PM

FYI, in case this helps someone else, my problem was that we had printer shares for our digital copiers out on some servers, but forgot to add the latest x64 driver to one of the shares when upgrading. Windows Update was trying (really really hard!) to download the missing printer driver itself, causing a surprisingly massive memory load on wuauserv.

The thing that tipped me off was entries like "Synchronizing Applicable Printers" in the WindowsUpdate.log on a troubled machine. Deleting all of the local printers and restarting the Windows Update service brought things back to normal immediately, which led me to discover the server that was missing the new x64 driver. (Also, even with the WU service stopped and disabled, the WindowsUpdate.log was getting a lot of activity from the spooler, looking to update the printer.)

Probably not the same thing that happened to you, Steelie, but perhaps it will help someone. :)

Best,
John

• Proposed as answer by Anonymous6185 Thursday, March 26, 2015 1:43 PM
• Unproposed as answer by steelie Friday, April 17, 2015 3:21 PM

EDIT: Ignore this solution. It does not work.

--------------------------------------------------------

I have a possible solution, as it is working so far (two days) on my computer (Windows 7 64 bit).

Go to Control Panel - Windows Update - Change Settings (on left):

Under the section "Who can install updates":

UNCHECK "Allow all users to install updates on this computer"

OK out of that window, then x out of the next window.

Restart your computer. Good luck.

Why this apparently works?

I had a previous problem where windows was trying to find software that was on a user account I had deleted. That problem caused a lot of delays until I figured out what was happening and stopped it from searching for a non-existant user account. After reading all the attempts at solutions here and elsewhere, and then looking at all the settings for windows update, I took a guess that the update program may have been slowed down in a similar manner do to some error in looking for other users that were not in use (default guest account would be my guess).

For whatever actual reason, turning off allowing other users in the update has stopped the runaway ram usage on my computer for the past two days now. I hope this simple solution works for others here.

• Edited by spatrama Saturday, March 28, 2015 7:43 PM Proposed solution does not work

I have a possible solution, as it is working so far (two days) on my computer (Windows 7 64 bit).

Go to Control Panel - Windows Update - Change Settings (on left):

Under the section "Who can install updates":

UNCHECK "Allow all users to install updates on this computer"

OK out of that window, then x out of the next window.

Restart your computer. Good luck.

EDIT: These further setting changes do not work either. Ignore the advice in this post (both the above quote and the below suggestions).

-------------------------------------------------------------------

Sorry for all those that this did not work for. After seeing everyone with no results, I went back and checked on what I did. I forgot that I also had previously changed the update settings to "Check for updates but let me choose whether to download and install them" in that same settings window. When I combine these two changes, my ram usage does not spike when restarted. When I do only one of these two changes, my ram usage spikes on restart again. So for my case at least, it seems to be these TWO settings combined that have, for now, stopped the ram usage problem. There are other changes I made to my computer before this, including disabling AeLookupSvc (Application Experience) in the services area. So I am not sure if additional changes are needed beyond the two in the windows update area. That's all I have for now. If I get some time, I will do additional testing to see if any previous changes are also helping with the ram issue.

• Edited by spatrama Saturday, March 28, 2015 7:49 PM Further setting changes do not work
• Proposed as answer by abcluberer Tuesday, March 31, 2015 1:23 PM
• Unproposed as answer by abcluberer Tuesday, March 31, 2015 1:23 PM

I can just confirm that big number of computers (standalone and centrally managed, laptops, netbooks, workstations) do have similar issues. The only solution is to disable Windows Update (Hello, Security breaches and Virus Epidemics). Very good motive for non-literate users to replace their "outdated" PCs, by the way :)

Hi,

We are seeing the same issue with Windows 7 machines running 2GB of RAM/memory. On startup the SVCHOST.exe process will consume a high amount of memory (upwards of 1GB at times) and cause the machine to page thus grinding it to a halt. This lasts between 20 - 30mins after bootup whilst (I presume) Windows finishes scanning the local datastore for currently installed updates and then the SVCHOST.exe process drops back to using just 60 - 80MB.

If we then run a manual check for Windows updates, can see the same process consume memory again just like it does on startup and causes the machine to slow down.

As a TEMPORARY workaround, have disabled the Windows Update service so this doesnt run on startup. Like everyone here, eagerly awaiting a response for MS on a fix/update.

• Proposed as answer by valentinhd Wednesday, April 01, 2015 9:24 AM
• Edited by Saunds Wednesday, April 01, 2015 9:45 AM
• Unproposed as answer by steelie Thursday, April 02, 2015 12:10 PM

Can anyone confirm whether this issue is escalated to Microsoft tech support?

Could everone here please generate a ticket at Microsoft tech support for this problem?

• Edited by valentinhd Thursday, April 02, 2015 7:45 AM

We have SCCM 2012 and Windows 7 machines with 2GB with exactly the same problem, I have found a workaround but it lacks a little finesse.

What we have done currently is to create a scheduled task to disable windows updates on startup by running sc config "wuauserv" start= disabled this will disable the windows update services so it won't scan/check/do anything windows update related.

If you then create another scheduled task to start the windows update services, you may want to set the triggers for the task for a specific time or if the computer is idle for any length of time and then get the task to run the following actions so the computer starts to perform any update actions :-

Action 1 - sc config "wuauserv" start= auto
Action 2 - net start "Windows Update"

Obviously this won't improve the performance lag when windows update is running but at least you can control when this performance lag happens so it can be done when the computer is not likely to be in use.

Same problem on more than 600 "Windows 7*" machines. Temporary we disabled WU, because this work impossible  :(

Please do not 'propose as answer' any workarounds for this problem.  I do not want others to think disabling windows update or altering the schedule time is an actual solution to the problem.  Thanks

• Edited by steelie Thursday, April 02, 2015 11:53 AM

Steelie, I 100% agree.

Trying to get to the root of the problem, the common thread in these threads over the last 5 months has been that this is Windows 7, the wuaueng.dll file running, (most likely) version 7.6.7600.320.  It affects Windows Home Premium Edition and also the large client Windows Enterprise users.  It affects the SCCM updaters and the Windows Update Agent.   It affects 32 bit and 64 bit machines, X86 and X64. 

I have gone through my entire update log from March 1, 2014 through March 1, 2015, 90 entries, looking at every KB article at MS support and I can not find the update where it listed wuaueng.dll is being installed, much less, version 320.  Windows support says that KB2887535 is the correct, most recent update, but that article shows version 256 being the "current" correct version.  I do not have KB2887535 listed as installed on my machine.

Please respond, is there anyone out there with this memory hog problem that has KB2887535 installed (it would be in the window between May 1, 2014-March 25, 2015)?  Or is it just my machine?  Can anyone find out what update or program installed V320?

So, Microsoft, 1) how did you install V.320 in my machine?;

2) How do I roll the version back to V.256 if I can't find how you put it on my machine?,

3) If you do make a fix, it appears V.320 is operating like a ghost.  Will your future version be able to detect it and overwrite it since according to your latest write-up should only be looking for V 256?, and

4) I am not willing to work with a once a week midnight scheduler, I want a proper fix.

HELLO MICROSOFT!! ARE YOU LISTENING??? THOUSANDS AND THOUSANDS OF YOUR CUSTOMERS ARE HAVING SEVERE PROBLEMS, CAN YOU PLEASE HAVE SOMEONE TO POST HERE TO ADVISE US?

People, sorry for the yelling, but it seems nobody's home.

• Edited by jjjrrr1000 Friday, April 03, 2015 6:15 AM Misspell fixes

Don't blame you for yelling. My sentiments exactly !

• Edited by ZeitB Friday, April 03, 2015 5:52 AM

I have raised a ticket yesterday about this issue with Microsoft. Usually they contact us within 4 hrs but I'm still waiting for an answer/contact. It might be because of Easter but as soon as I get a reply I will keep you all posted. I will also direct them to this thread because I tried almost everything stated above...

The same here on win 7 pro sp1 x64 with 2gb ram using wsus. Apparently this is affecting thousands of computers running windows. Why would microsoft assume that everyone would just run to the stores to buy memory upgrades?

A friend of mine experienced exactly the same issue on his Windows 7 Home Premium laptop with 2 GB RAM. The svchost.exe process takes sometimes well over 1 GB leaving nothing for other processes and thus grinding everything to a halt. Stopping the wuactl service (version 7.6.7600.320) releases the memory. For the moment the only workaround is to disable Windows Update, I don't like this but the alternative is a unusable laptop.

I found this possible "fix" but am not computer savvy or brave enough to try it.

Any takers or comments ?

https://gist.github.com/SpokedVictor/7572097

"it fixes a lot more problems", I would not try that.

Could everone here please generate a ticket at Microsoft tech support for this problem?

@ZeitB.. that's sort of a scorched earth approach.  I wouldn't be too quick to unregister and reinstall every windows system service.  That's pretty much running a Windows repair, which I would much rather do by running an actual Windows repair.  Also, this isn't a memory leak per se, the application appears to be written to allow it to use as much memory as it possibly can until it's finished.  It does release the memory when it's complete.. usually an application leaking memory will not be able to release used memory unless it is forcefully killed.

I have raised a ticket yesterday about this issue with Microsoft. Usually they contact us within 4 hrs but I'm still waiting for an answer/contact. It might be because of Easter but as soon as I get a reply I will keep you all posted. I will also direct them to this thread because I tried almost everything stated above...

any progress on your ticket?

This worked for all of our workstations that were having this issue.  All we did was reboot in diagnostic mode, delete the contents of the Repository directory and then restart Windows normally.  The issue has not returned after 48 hours so far.  Thanks for the info, Israel!

This worked for us.  All we had to do is reboot in "Diagnostic Mode", delete the contents of the Repository directory and then restart Windows normally.  The issue has not returned in over 48 hours so far.

Thanks for the info, Israel!

Isreal pointed out a solution for a very different issue.  He was experiencing high CPU usage.. not the memory issue everyone else is having (the original issue I posted about.)  I unmarked the proposed answer.  

I am experiencing the same issue (Memory usage on wuauserv up to 1,5 GB until the system starts saving on disk and freezes) for several weeks now. I even reinstalled Win7 and installed all Updates for no success (which should have been clear to me before doing so). Deploying manual updates is - despite the security issue - not a satisfying option, since starting the manual update search freezes the machine and a complete search takes more than 3 hours. This is definitly not acceptable. If anyone has new information or a possible solution on this issue, please let us know!

• Edited by fabi.mv Tuesday, April 07, 2015 7:02 PM

I was having same issue with high memory usage with Windows Update. It was consuming extra 1.5GB RAM. I have solved the problem by following this link.

https://gallery.technet.microsoft.com/scriptcenter/Dos-Command-Line-Batch-to-fb07b159

This has worked for me.

• Edited by Su 966 Wednesday, April 08, 2015 11:16 AM

This seems very similar to the other proposed fixes.. I'm suspecting this may help for a little while, but over time as the distribution folder grows in size, the problem will come back.  I'll try this again and see if there's any improvement.  Thanks for posting the link.

My only hesitation would be the following part of the script:

netsh winsock reset 
proxycfg.exe -d 
netsh winhttp reset proxy

I would be careful running this against a domain joined machine, since proxies and winsock providers (AV likes to add itself to the stack) could be impacted by this.

• Edited by steelie Wednesday, April 08, 2015 12:12 PM

That script page has a reference to "How do I reset Windows Update components?" that has Microsoft FixIt.

Yeah the windows update reset hasn't solved the issue.. it was literally the first thing we tried.

I have raised a ticket yesterday about this issue with Microsoft. Usually they contact us within 4 hrs but I'm still waiting for an answer/contact. It might be because of Easter but as soon as I get a reply I will keep you all posted. I will also direct them to this thread because I tried almost everything stated above...

Predrag, any luck on your ticket? How do you raise a ticket with Microsoft, by the way?

Really, with so many people having the same problem, won't Microsoft address this? If there's no answer on this problem I will have to consider other options, like installing Linux on the laptop.

Same problem here, it's my own machine, I'm glad I'm not the only one. Every day I'm afraid one of my customers will communicatie this problem without solution. Hope there will be news from MS/ticket. It started also end of 2014 (I think around november).

I haven't been able to find any real fix for this either, just work-arounds...

Really? No news from Microsoft?

I'm beginning to suspect KB2952664 as the culprit for this problem. The description is -"This update helps Microsoft make improvements to the current operating system in order to ease the upgrade experience to the latest version of Windows".  It seems to have been updated/re-issued every month since June 2014 (apart from January). I suspect it's scanning and modifying W7 systems in preparation for a straight upgrade to W10. I also suspect that it was the November release which triggered the problem.

Similarly, check out KB3035583 (last month) which installs GWXUXWorker.exe in Windows\WinSxS and has the product name of  "Get Windows 10" in the Properties Details. Is this a solution we are going to be hit with later this year?

I may be a pessimist, but things could get worse before they get any better if MS continues to issue more updates like this in the run-up to W10 release.

My desktop (2Gb) is affected by the problem but my 4Gb laptop copes with Windows Update growing to almost 1Gb.

 

• Proposed as answer by valentinhd Tuesday, April 14, 2015 6:50 AM
• Unproposed as answer by valentinhd Tuesday, April 14, 2015 4:15 PM

I'm beginning to suspect KB2952664 as the culprit for this problem. The description is -"This update helps Microsoft make improvements to the current operating system in order to ease the upgrade experience to the latest version of Windows".  It seems to have been updated/re-issued every month since June 2014 (apart from January). I suspect it's scanning and modifying W7 systems in preparation for a straight upgrade to W10. I also suspect that it was the November release which triggered the problem.

Similarly, check out KB3035583 (last month) which installs GWXUXWorker.exe in Windows\WinSxS and has the product name of  "Get Windows 10" in the Properties Details. Is this a solution we are going to be hit with later this year?

I may be a pessimist, but things could get worse before they get any better if MS continues to issue more updates like this in the run-up to W10 release.

My desktop (2Gb) is affected by the problem but my 4Gb laptop copes with Windows Update growing to almost 1Gb.

 

I am not sure why would someone propose this post as answer. I do not see anything in here that resolves the issue in question and it is really disappointing that Microsoft has not come up with any solution for this yet.

I have been following this thread in hopes of finding a solution. Just to let everyone know we have some machines with Windows 7 enterprise version with 4GB of RAM with the same issue. The wuaueng.dll on one machine I checked is the latest ( 256) and not 320 so don't think that is an issue. Hoping there will be a solution soon.

POSSIBLE ANSWER????

My computer just received an update from Windows, article number KB2990214, described as "Update for Windows 7"  in it, they have updated the file wuaueng.dll with a version 7.6.7601.18804, which would be a change from the 7.6.7600.320 that was on my machine.  There are also other wuXXXX type updates.

It is dated 3/15/2015.

Does anyone else now have this update?  Is this MS's answer to our problem?  I have not tried checking if the Update Manager sucks the memory now, but will and repost.

OK-  Just reran Windows Update; one had been run 30 minutes before so I don't know if it affected things.  When I timed it 2-1/2 weeks ago, it took 18 minutes and used 600-750 MB for almost every one of those minutes.  With this new version 7601.18804, it took 15 minutes, but the memory usage dropped to 400 MB for 10 of the minutes and went up to 600 MB for 3 minutes.  I could do some stuff in the foreground, somewhat better than before.

So directionally it is going the right direction, (3 minutes faster, 30-40% less memory for the time).

Anyone else seeing a change, or is it just me?

UPDATE 5/2/15-  This update doesn't help anything, it's back to the high memory consumption to the extended period.  The one sample listed above was a fluke.

• Edited by brucefal Saturday, May 02, 2015 3:26 PM Update on new wuaueng version

KB2990214 did not have any effect on our systems (Windows 7 SP1 64bit). It takes same unbearable amount of time consuming up to 1,4 GB memory at the end of the scan.

Just to be clear: KB2952664 ist NOT the cause and uninstalling does _not_ solve anything. Don't waste your time on this, and I would really suggest not marking that as a answer (there can only be one answer and that's a PATCH - now)

Right now I installed a Windows 7 SP1 64bit again and between the huge amount of memory used by Windows Update service, the Trustedinstaller also sucks up more than 1,2GB and CPU. It takes ages to finish the update procedure of a fresh SP1 install.

What the heck is Microsoft doing? Do they really REALLY think we are going to get Windows 10 when they aren't even capable of fixing this piece of .... of a massive problem? They are letting - well - millions of users ? alone with this.

I simply can't understand that.

I'm beginning to suspect KB2952664 as the culprit for this problem. The description is -"This update helps Microsoft make improvements to the current operating system in order to ease the upgrade experience to the latest version of Windows".  It seems to have been updated/re-issued every month since June 2014 (apart from January). I suspect it's scanning and modifying W7 systems in preparation for a straight upgrade to W10. I also suspect that it was the November release which triggered the problem.

Similarly, check out KB3035583 (last month) which installs GWXUXWorker.exe in Windows\WinSxS and has the product name of  "Get Windows 10" in the Properties Details. Is this a solution we are going to be hit with later this year?

I may be a pessimist, but things could get worse before they get any better if MS continues to issue more updates like this in the run-up to W10 release.

My desktop (2Gb) is affected by the problem but my 4Gb laptop copes with Windows Update growing to almost 1Gb.

 

I am not sure why would someone propose this post as answer. I do not see anything in here that resolves the issue in question and it is really disappointing that Microsoft has not come up with any solution for this yet.

If you haven't noticed this before, it is happening in these forums at epidemic level . You have posted a question here and an answer has appeared. Whether the answer is helpful or not, before you were able to finish reading it, someone is rushing in frantically to propose it as answer. I think there are some who are specially appointed for this noble task; to rush through the forums proposing answ

I do residential/business pc repair, I can testify that this problem is basically ruining my life. I realize that systems with 4GB of memory aren't as affected but they still are. The last 7 computers I have reinstalled windows on have experienced svchost mem usage from 540mb to 1.5gb, systems with 2gb/3gb are barely responsive during the updates. This is honestly a major time killer & as you know Microsoft updates need to be refreshed 4 times after the first 160+ updates are installed, that is 4 times I must wait for the sluggish update check. This is also crippling machines with 4GB of memory if the processor is week. MS needs to understand that we technicians can't be waiting 8hrs on windows updates. The worst is, I am not sure if this will continue to happen to the customer, during a windows update query. I am telling you Microsoft.. this is bad for my business and your own. This should have major news coverage by now. I really hope that this problem will work itself out after the Windows 10 upgrade checking is done, please release a patch for technicians so we can at least update windows 100% before giving the systems back to clients. Please have a press conference about this matter to inform the people, because this falls directly back on me, I can't explain to a customer that this is Microsoft's problem.. they wouldn't understand nor believe it.

I should add that I didn't have this problem before march 25th 2015, updates were always slow before then but this a time crippler. I've never seen svchost use over 1gb during a windows update. It is definitely wuauserv because simply stopping service drops down svchost mem usage from 1.2gb to 130mb... this problem is always after clean install of windows or on a system that hasn't received the updates that cause this.. In my case all computer I have worked on since march 25 have done this. 7 clean installs & 4 laptops that just needed to be updated after a cleanup have done experienced this ridiculous high memory usage. Please fix & don't tell me to try anything. This problem is all over the web and my phone has been ringing off the hook with slow computer complaints. Remoting into these systems, I have verified that it is wuauserv when update check is progress. Again please patch this correctly.

I'm not sure if this is relevant but this is a post from a couple of days ago that mentions that a hotfix is in development for what appears to be a similar issue. It also suggests possible workarounds. 

The author is Larry Mosley | Senior Escalation Engineer | Microsoft GBS Management and Security Division

http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

Quote:

At its core this is a memory allocation issue, thus 64-bit Windows 7 computers will not see this error because the address space is effectively unlimited. They will, however, exhibit high memory and high CPU usage, possibly affecting performance. Note that x86 clients will also exhibit high memory usage (around 1.2-1.4GB).

We have also had reports of this affecting System Center Endpoint Protection updates deployed by Configuration Manager as well as a few reports of Windows 8 x86 clients being affected.

A hotfix for the Windows Update Agent is currently in development. The update will change how the update metadata is loaded into memory. Pending the results of final testing, this fix should be available late in the 2nd quarter of CY2015. This post will be updated with more information as it becomes available.

Thoughts ? Comments ? A glimmer of hope maybe ?

• Edited by ZeitB Sunday, April 19, 2015 4:21 AM

Wow, maybe a fix is inbound!  It would be nice to get an actual official response from MS in this thread, but from your post it looks like it is on their radar.

Also, an anonymous user marked a reply as a proposed answer, which I have 'unproposed.'  I will continue to do so until the problem is resolved..  Once we have an official, documented answer to this problem (via hotfix or otherwise) I will post the relevant information and mark the question answered.

It is really disheartening, and quite frankly, infuriating that we have to "hang out" here on this thread to see if we can fix our computers and Microsoft does not have anyone to post here to at least advise us on the issue.

I can tell you this for sure: this issue, and the lack of response from Microsoft, has changed the way I see the company and their products. I can understand that problems can happen, but disrespect, no.

Hi, I just wanted to add my name to the list..

This problem is exasperated by mobile users , who are off the network past SCCM scan/update deployment deadlines.

When they bring the mobile computer back on the network, They get hammered with the updates scan. Even with 4GB of RAM this will make the computer pretty much useless for 15- 30 minutes. The laptop could also be getting hit with antivirus def updates and scans at the same time, in most enterprises this is a reality for mobile users. In my case it is, and the laptops, although quite powerful cannot handle doing both of these at the same time. Come on MS , help us out here!

Guess who uses mobile computers...VIP's in most companies.I have hundreds of angry customers to deal with.

I hope Microsoft gets on this, as this is a major problem!

The users are desperate and all they can do is hold the power button down. Of course the problem comes back later, in the day to haunt them when they are re-connecting to wireless to run a powerpoint presentation in front of 20 other execs.... "ah sorry folks, my computer is frozen again, You will all have to wait" and then followed by the ever popular comment "I'm throwing this in the garbage, and getting a MAC"

Which is happening more and more to the shigrin of our team.

• Edited by Barryt_jam Wednesday, April 22, 2015 9:46 PM

Hey, I just wanted also to add my name to the list.

We use SCCM and SCEP... seeing the same behavior.

MICROSOFT - PLEASE do something. (I have opened a case @MS-support)

Mike

Hey, same issue here.

we use SCCM 2012R2 CU4 + no SCEP. same problem.
We created a package in SCCM and disabled Windows Update Service unless this is fixed.

We have the same situation (over 30K clients with a decent size SCCM infrastructure). Our clients performance during update scans crazy bad, like not usable. We started a support ticket and MSFT immediately worked with us on cleaning up with WSUS... are you guys doing any WSUS maintenance with your SCCM SUP environments? We were not really, I was mistaken in thinking that SCCM would take care of that, but it seems that like the stand alone WSUS infrastructure there is some care and feeding that these WSUS servers need even if you are not hitting them directly. SCCM will not do ANY WSUS DB maintenance. The first place the MSFT tech went was to was the WSUS console (the one that your not suppose to touch if you have a SUP / SCCM) lol

I guess the theory is that the catalog that the clients are scanning against is getting "too large" which is the cause of the performance problems when they are trying to see what updates they need.

We are going to see what happens with our clients performance now but I just wanted to update the thread so that others can check on this as well... I guess I would try to run your WSUS cleanup wizard at a minimum on all your SUP's to limit the size of the catalog these clients are trying to scan against and see if it helps.

I would be grateful if we could see an official KB article how to clean up WSUS when using SCCM? These blog articles stating "don't try this in production" are too risky to try in real world.

We did that WSUS maintenance in the early stages of troubleshooting this.  (We are guilty of 'using' the WSUS console in an SCCM environment, lol)  The part that didn't make sense for me was that the catalog of updates I'm carrying is far less than the full catalog Microsoft has.. wouldn't all the home users using Microsoft update still be screwed?  

FWIW, all the cleanup did was make the scan complete faster (slightly) but during the scan the machine was still unusable.  

• Edited by steelie Wednesday, April 22, 2015 12:16 PM

Yeah I agree. It doesn't make sense and yes the scan does eat a ton of memory still but its seems like it's only for about 30 seconds compared to about 10 min before. I think there is still some underlying problem that seems to be with the local machine's wuauclt eating max memory while it scans and that this sure seems like a "new" problem... since November-ish for us as well, but getting progressively worse since then.

As far as the catalog from MSFT I'm sure they actually remove their expired and superseded updates so home machines aren't actually scanning against all the "old" stuff that hangs around a WSUS (understandably for corporate admins to better control and manage).

update: I'm thinking this is not helping us to be honest. We are still having chronic slowness and performance issues. I'm still working with MSFT on it, I will update the thread with anything learned.

• Edited by JdoubleUs Wednesday, April 22, 2015 7:48 PM added more info

Hi Everyone , I was wondering if anyone has looked at this article, and tried the steps... Or if this rings a bell for anyone? This article is 5 days old and it actually mentions a hotfix is being built for the Windows update agent.

http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

I tried turning the Windows update service into its "OWN" process as the article suggests, and that doesn't help in my case, although it seems that the performance spike was not as long as usual, it still made the computer useless for 15 minutes instead of 20... The other things I haven't had a chance to try, plus I would have some red tape to go through before I can even attempt some of the suggestions.

I'm going to propose this as the answer just to get everyone looking at this, and attempting some of the suggestions.

• Proposed as answer by Barryt_jam Wednesday, April 22, 2015 9:36 PM
• Edited by Barryt_jam Wednesday, April 22, 2015 9:39 PM

This week I had the opportunity to install Vista on a laptop (from scratch) that had very similar specs as the other laptops that I have with windows 7, which present this crippling problem.

The result: the Vista computer installed a gazillion updates and never once spiked the memory usage over 70% (2gb total installed); also the computer was at all times totally usable. Therefore, this is a problem with Windows 7, the leader OS in the world that everyone loves (or used to). Hummmmm.....

Then probably by July Windows 10 will be out and Microsoft will probably allow a free upgrade  to most... Hummmmmm....

Probably just a coincidence.

@ barryt_jam

Thanks for the info.. looks like he's given us at least one more thing to try.  There may some benefit to breaking out the scan process, since memory fragmentation in the svchost could be an issue.  We are very proactive about keeping a clean update catalog, so I think the ultimate resolution will be Microsoft correcting the core problem of the memory usage of the scan.  I'll keep my eye on this blog post for more info regarding the yet unseen patch.  I don't like the title of his blog post though.. our clients are successfully completing the scan.

I'm glad they're addressing this within the scope of SCCM, but apparently this is also affecting regular windows update users.. hopefully this patch applies to all.

• Edited by steelie Thursday, April 23, 2015 12:07 PM

Just to confirm that this does affect regular Windows Update users, as we have 6 machines affected. Separating out the Windows Update service into its own process has only helped as far as being able to stop it and free up memory slightly more cleanly when the problem occurs. Watching this thread avidly for news of a patch!

I agree....

After separating the process to its own SVCHOST, the memory usage isn't quite as pinned the entire time like it used to be. It dips, and then comes back up a few times, where before making the change it using 100% of the available Memory the entire time. But the computer is still unusable for 20 minutes.

BTW this is on a Windows 7 with 2 GB or memory.

No foreground applications open and running .

Baseline, it runs at around 600 mb memory consumption.

If I trigger Windows update scan with the SCCM 2012 client it uses all available memory, and then start Paging, and the disk IO is very high.

We are running performance analyzers, and other tools to figure this out, plus trying some new antivirus exclusions on the client.

We have a call in with MS now as well.

Also, If my test computer is actually installing updates (not just running an update scan) it can be unusable for up to an hour due to the High disk IO/paging, and High memory.

• Edited by Barryt_jam Thursday, April 23, 2015 5:53 PM

@ barryt_jam

Thanks for the info.. looks like he's given us at least one more thing to try.  There may some benefit to breaking out the scan process, since memory fragmentation in the svchost could be an issue.  We are very proactive about keeping a clean update catalog, so I think the ultimate resolution will be Microsoft correcting the core problem of the memory usage of the scan.  I'll keep my eye on this blog post for more info regarding the yet unseen patch.  I don't like the title of his blog post though.. our clients are successfully completing the scan.

I'm glad they're addressing this within the scope of SCCM, but apparently this is also affecting regular windows update users.. hopefully this patch applies to all.

Hi Steelie, same here...our WSUS/SCCM team also keeps a clean WSUS catalogue. So we are patiently waiting for the hotfix patch,

We are checking our AV exclusions and testing them, in hope of optimizing performance until a hotfix arrives...

• Edited by Barryt_jam Thursday, April 23, 2015 5:52 PM

We are having this same issue in a non-SCCM environment using Kaseya to manage the updates instead. One thing we noticed today is that this only appears to be affecting our Lenovo laptops. We're still gathering information to confirm but I wanted to ask if anyone has noticed a similar pattern.

**update** We have now started seeing reports from HP machines also so this is not linked to a specific manufacturer. 

We have tried everything listed here so far and nothing appears to solve the issue. The sc command linked to from Barryt_jam did seem to provide a short respite to the problem but it returned after a short period during the update process.

• Edited by Chris at FI Friday, April 24, 2015 2:11 PM update

Another victim here,

I have a Windows 7 SP1 with 3 Gb RAM and my computer became unstable about a month ago because of this Windows update scan. I suspect Microsoft to broke voluntarilly their own product, as they want us to upgrade to Windows 8.

Also victim to this. Laptop is an i5 with 4gb memory and until now has been more than sufficient for Windows 7.

I don't actually think an upgrade to Windows 8 is what Microsoft want at all - maybe it's not because I'm cynical, but I don't see Windows 8 as being a usable and beneficial offering compared with Windows 7.

As someone who worked in a PC Support environment when we moved from Windows 3.1 to Windows 95 and saw the huge change in user experience (and IME it was a "nice" one, whereas Metro is "difficult" for non-touchscreen devices) I wouldn't want to be forcing this out right now and I don't think Microsoft expect us to.

I'm in the same situation. I have a system equipped with two 2GB of RAM and all I'm trying to do is make updates for a fresh setup of Windows7 SP1 x64. During the download the PC starts to became unusable because of CPU and memory usage, then during installation, at 176th update of over 180 it gives me an error because RAM is completely saturated and so it aborts the installation.

I have no solution to this, but since Group Policy in my organization requires that automatic updates are always enabled, I have devised a work-around.  I have created a service that stops wuauserv (the Windows Update service) whenever it starts.  It's annoying, because the dos window flashes each time this happens, but at least my laptop doesn't lockup with 90+% utilization.

Once per day I disable my service and run the updates.

• Edited by SAS in MD Tuesday, April 28, 2015 3:08 AM

In the German thread of this problem Teodora just posted the following links as solution for this problem. I've lost the overview if these where already mentioned here:

• Getting Started with SVCHOST.EXE Troubleshooting
• Troubleshooting problems with installing updates

Here is the deal, MS cant really help. I have changed the GPO to check for updates every 22hr and that solved my daily issues at least and after applying all mentioned below the memory spikes are smaller and shorter but they still exist. They told me to try the following:

On client side:

- separate wuauserv into own svchost

sc config wuauserv type= own

- delete swdist

net stop wuauserv

rmdir /s /q %systemroot%\SoftwareDistribution

net start wuauserv

- check AV exclusions:

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows

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

"...

Turn off scanning of Windows Update or Automatic Update related files

Turn off scanning of the Windows Update or Automatic Update database file (Datastore.edb). This file is located in the following folder:

%windir%\SoftwareDistribution\Datastore

Turn off scanning of the log files that are located in the following folder:

%windir%\SoftwareDistribution\Datastore\Logs

Specifically, exclude the following files:

Edb

*.jrs

Edb.chk

Tmp.edb

The wildcard character (*) indicates that there may be several files.

..."

on server side:

- update WSUS if running on W2K3

last hotfix is KB2938066

Update for Windows Server Update Services 3.0 SP2 (KB2938066)

http://www.microsoft.com/en-us/download/details.aspx?id=43633

Update for Windows Server 2012 (KB2938066)

http://www.microsoft.com/en-us/download/details.aspx?id=43491

Update for Windows Server 2012 R2 (KB2938066)

http://www.microsoft.com/en-us/download/details.aspx?id=43485

- do database maintenance

https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

- run cleanup wizard

- review synced products, categories, languages

"Here is the deal, MS cant really help."

That's not necessarily true.. MS should be delivering a patch soon for this issue.  If you've read through the 'proposed' answer there is a link to a blog where the problem is being addressed.  Several of us have already tried everything you have listed, and the problem persists.  At this point I think the majority of people are eagerly awaiting the official hotfix/update for this problem.

Add me to the list. It happens on my personal laptop at home.

Windows 7 Home Premium 64bit, Intel I7 2nd generation, 4GB RAM installed.

I have seen the svchost process which contains windows update consuming more than 1GB of RAM, for a long time (more than 5 minutes). My decision was to disable windows update and maybe reenabling it once a month, at a moment that would not disturb my computer usage.

I have to say though that I also manage a company's network and nobody has complained about this issue to me yet (fortunately). There are several units with Windows 7 32bit, some of them with 2GB of RAM. All windows 7 64bit run on computers with 4GB of RAM.

Ah, in my company we don't use neither WSUS nor SCCM (not sure if fortunately, or not).

Although it could just be that my users have just become used to crappy windows performance, or that they don't notice bad local performance very much because we use almost all applications via CITRIX xenapp.

In my opinion this could be caused by the stupid MS refusal to create baselines like they did in the past. A windows 7 service pack 2, even 3 could alleviate this problem. As we only have one baseline, service pack 1, which currently is over four years old, there are hundreds of patches to review and check and that may be causing the process to be so inefficient.

Again, I found MS refusal to release service packs stupid, but well, MS decisions are stupid so often that it does not surprise me anymore.

• Edited by Oscar Gil Tuesday, April 28, 2015 2:40 PM

 The PS script in the link below for declining  superseded updates in the WSUS DB makes a big difference,

http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

But It still doesn't solve the issue 100%. You see an initial spike in memory, then it drops after 1-3 minutes (much better than a 10- 15 minute initial spike that we saw before running the script.)...

Then svhost/wuauserv uses a steady 600 mB of ram until its completed the scan, which again is better than using 900 mb +..

But I still believe Microsoft needs another solution as the Memory usage is still way too high. On a PC with 2gb of ram, computer applications start freezing during the initialization of the scan... Plus if its actually installing updates (not just scanning), it  becomes unbearable for users for 45 minutes +.

I raised similar recently in the more public 'Answers' where more suited to my level of Windows management knowledge. A couple of well intentioned people tried to help but both seem to have given up following up on my feedback to their suggestions. So perhaps I can add one more voice here.

Briefly, in Win7-x86 always after startup and intermittently through the day svchost consumes all available memory with high hard faults, making the system effectively unusable for anything from about 10 minutes to about an hour each time. Manually stopping wuauserv quickly restores resources, sound familiar!

I was pleased to learn here a hotfix is in development, thank you steelie for flagging that. Frankly Im surprised as this issue dates way back into previous versions.

Pending the hotfix, for my purposes an ideal workaround would be to have buttons on my desktop to run scripts to stop wuauserv and restart it when OK to bloat away (apart from that keep it configured to run automatically).  Manually I may need to hit Stop service' multiple times getting the "This service cannot accept control messages at this time" message each time, so a confirmation it really has stopped would also be handy. If anyone has any ideas that would be great!

Just wanted to add that this has been affecting my personal Win7 x64 machine with 2gb of RAM for a while, and also my work laptop Win7 x64 which has 4Gb of RAM. My idle state for my work machine runs around 2.5Gb use though, I have quite a few things that are always running so when windows updates feel like checking, I might as well take a lunch break. If I do finally get the resource monitor running I can see the svchost chewing up 1.5 - 2gb of ram and the hard drive queue at 10+ all hitting the swap file as hard as it can to free up memory for windows update.

I have checked on a machine with 8Gb of ram, and it is also affected but it does not consume ALL the ram so the system does not become unresponsive when it happens.

I just disabled windows update on both machines for now and I will watch this thread for the hotfix and then I will update after getting that installed.

This is ridiculous how long this has been going on without a fix.

I have been google searching this topic on and off for a while and never found anything noteworthy until I found this thread today.

This situation is pretty insane.

Since 1 month, I'm in the situation you described before, with a x64 + 3Gb RAM system. 

My Windows 7 system is unusable 7/8mn after it boots up, 3/4 when I resume from hibernation. Even a Task Manager + kill Service is quite impossible to do cause the system is entirely frozen.

I'm killing again and again this wuauserv service, or I've to disable globally the updates.

MS please fix your shit.

On my work machine since even with windows updates disabled they force scans at random it seems like...

I have just put a batch file on my desktop with this in it:

net stop wuauserv
pause

It worked the one time I had to use it today. Actually the service is still stopped, so it might just work until my next reboot. I can't be having this happen while I am in meetings, especially if I am presenting!

Pending the hotfix, for my purposes an ideal workaround would be to have buttons on my desktop to run scripts to stop wuauserv and restart it when OK to bloat away (apart from that keep it configured to run automatically).

I tried jtp10181's two line batch but as expected it failed for UAC admin. However I found this UAC admin script I Rem'd the last "cmd /k" line and added these 4 lines at the bottom of Matt's UAC script

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

I saved as Stop-WU.bat on my desktop, with a similar batch file to restart with the stop's replaced with start's. Both worked. I rebooted, waited for wuauserv to kick in watching the performance graphs. I ran the stop script, it took a few moments but it worked and saw the graphs drop dramatically :)

I had no idea what cryptSvc, bits, & msiserver are but AIUI- BITS, Cryptographic, MSI Installer in addition to the Windows Update Services. In the other thread I mentioned it was suggested to me I should rename my SoftwareDistribution and Catroot2 folders to cure the problem, but would need to stop and restart these particular services to do that. In a light search it seems deleting these folders may work for some but make things worse for others, so I'm hesitant to try (any comments?). However in the meantime I think I can live with this pair of scripts.

Originally I set up a bat file as a service which is triggered whenever the wuauserv service starts.  That works very well, but if your group policy continually restarts windows update, you keep getting interrupted by a dos popup window.  I searched online and found that if I embed my batch file in a vbs file, I no longer see the dos window.  This workaround is almost as good as a solution, in that I no longer have any memory issues.  I simply disable my Stop Windows Update service once per day and run the updates.

Here's the vbs file:

Set WshShell = CreateObject("WScript.Shell" ) 
WshShell.Run chr(34) & "C:\Users\username\Desktop\Stop Windows Update.bat" & Chr(34), 0 
Set WshShell = Nothing 

and here's the bat file:

net stop wuauserv

Steelie-

Thanks for the update.  I suggest that you update (your updated original) posting from 30 minutes ago (4/30/15) and please put a date and time in the bold section above it in capital letters.  That way others will see that this is the latest info and won't just scroll down to the bottom and miss it.  I almost missed it.

Thanks!

That's not going to resolve the issue for most people. That problem is tied to Windows 7 32bit. Many people have issues with 64bit as well. Unless they are going to port the fix over to both architectures. And the time frame still seems like some time out from now. That sucks.

good luck with that , I've been having a similar issue but apparently is more complicated 

i got machines hitting 1.5GB memory using Microsoft online update the old fasion traditional way control panel windows update check for update , it wont even check!   win7pro 32bit 4GB RAM 500GB hard drive 

windows update process svchost.exe  crashes and i keep getting Error 0x8007000E " i dont have any freaking language packs installed"

my application log is filled with error reporting fault bucket windows automatic update  bla bla bla , so far 10 machines , and i dont want to check for more! 

been trying to figure what is going on for about 2 days and im stuck

only thing worked so far for me is uninstalling office 2013 then updates seems to be working fine.

Finally activity in a thread revealing the severity of this problem.  I have been dealing with and searching for solutions to this problem for nearly a year now!

My company manages hundreds of business machines, and services thousands of residential machines.

This problem is pervasive. It started with our business users complaining their computers were "freezing" up at specific times of the day, day after day.  Luckily, we manage that process and changed it from a random, every day scan to a once per week night scan.   However, there is no solution for our residential customers who want to know why their perfectly healthy computer is 100%, completely unusable.

This problem is noticed without fail on nearly every Windows 7 machine running with only 2GB of RAM.  The svchost.exe process chews upwards of 1.5GB - 2GB of RAM during an update scan causing severe faults and effectively "locking" the computer up.

This is not a "few instances" as the hotfix article suggests.  This is a pervasive problem impacting every Windows 7 computer on the planet, and for nearly a year now!  It is a debilitating problem that we have no answer for, because the only effective solution is to disable windows update.  We can't even control when the automatic update scans occur.  But, we always know it is this problem we are dealing with when someone calls and tells me their computer is locking up at the same time every day!

I am fighting this problem a few months, already. Windows 7 Home Premium SP1 on Lenovo i3 3GB system memory.
I never had enough time to identify the cause, so I was googling wrong terms. I'd finally isolate wuausrv  as a main problem and found this thread.
My version of wuaueng.dll is  7.6.7601.18804 and still having problems. Already tried every proposed solution repairing WAU, reregistering files  and MS FixIt ...with no visible success. The only way  if you really need to work on the machine is to stop WAU service.
I am hoping for a solution too.

 

So, Monday morning. As soon as log into the VPN it starts scanning. I stopped the service right away when I noticed sluggishness. It started itself back up again. So I decided to let it run its course. About an hour later its finally done, and all it did was install a dozen or so Office 2007 updates.

I've had enough of this. I went in and marked the "Windows Update" service as DISABLED.

Hopefully that will stop the automatic scans from the company servers.

You would think Microsoft would make this high priority. Think about how many lost work hours there are across the country (world?) from this. 1hr a week X even a mere 1000 people X a year = 52000 hours X low ball $15 / hr = $780,000 in wasted wages a year paid to people pounding their keyboards or wondering around the office waiting for their computer to become usable again.

I have seen this in my Organization as well since we moved to SCCM 2012 earlier this year.  We run Windows 7 64Bit and all PCs have 4GB of RAM.  We do not have it to will the PC will not budge but enough of a RAM hog to irritate the users.  I have ran through all of the aobve suggestions with no help.  He also removed any back logged "Expired" or "Superseeded" Patches on our WUA server/location.  

The odd thing is none of these PCs had this issue when we were using SCCM 2007 on a 2003 Server.  Now we are on 2012 Server and SCCM 2012.  

Our company has got to the point to where we need to call MS Premiere to see what they can do.  I'll post any updates here.

• Edited by richard keel Tuesday, May 05, 2015 12:55 PM

Good morning,

Had same symptoms, and I've tried following steps:

1. Ran Windows Update Client reset script (as mentioned in another post above)
2. Installed all updates available
3. Ran sfc /scannow
4. Restarted computer

Currently svchost is using approx 150MB in my system, can anyone else try same steps to see if it is solved?

@Prodastur

There has been some actions that temporarily decrease the memory usage (such as the ones you've tried)... but the problem returns before long.  It would be crazy if we had to reset the update client before every single scan attempt.

Also, you mention svchost, which is merely the hosting process for the windows update scan.  You need to use a program like process explorer to see what's running inside the svchost in real-time, and wait for the wuaserv.exe to start doing it's scan.  That is the actual process that is consuming the memory.

• Edited by steelie Wednesday, May 06, 2015 12:11 PM

Of course, I checked memory usage by using Process Explorer, and in my case, wuauserv.exe (of course, hosted by svchost) was the problematic process.

I posted all the steps, but I think that the one who solved the problem was using sfc.

If I gave all the troubleshooting details, they should be:

1. Ran Windows Update Client reset script (as mentioned in another post above) - 3 minutes after reboot, svchost was using 1,5GB RAM - Not solved
2. Installed all updates available - once rebooted and the last program in startup was loaded, svchost started to increase memory usage until approx 2GB - after a new reboot, same symptoms - Not solved
3. (after new reboot) Ran sfc /scannow
4. Restarted computer - once the last program in startup was loaded, svchost keeps using approx 150MB RAM - After a couple hours, rebooted the computer, same behavior - 12 hours after last reboot, svchost is still using approx 150MB RAM

I'll still keep watching, but for this moment, I think sfc has solved the problem in my case.

You keep saying svchost... if wuaserv isn't running, then of course your svchost process isn't going to spike.  Try running a windows update check manually and watch the memory usage of wuaserv.  Also, I'd be curious to see the cbs.log from the completed sfc process.

Yours is the first post I've seen that mentioned sfc.  I ran it, and it repaired several files including Windows Update.   Now my memory usage, even while Windows Update is running is no longer in the 90%+ range, but stays under 70%.

We can dance around the fire and do our hocus pocus magic forever. Some might ease the pain, some not.  The point is that this issue is recognized by MS and cure is in their hands and in their hands only. What we would like to hear is news from MS hotfix team, how is the work progressing, is the original timetable still valid?

• Edited by PS1000 Thursday, May 07, 2015 8:37 AM

Hi,

Temporary Solution:

Removed WSUS Server Address from Registry

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]

"WUServer"= " "
"WUStatusServer"= " "

Hi,

Temporary Solution:

Removed WSUS Server Address from Registry

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]

"WUServer"= " "
"WUStatusServer"= " "

No use posting these "solutions" that actually are not fixing anything. We all know that killing the Windows Update service stops memory issues but there is a reason why we need the Windows Update service to work as a decent citizen. Using  the same analogy I could suggest you to format your C-drive and install Linux. That would be even better "solution" because security would not be compromized.

In my case, the major problem is that due to high memory usage I can't complete the updates since RAM goes full first I can complete the process (windows7 x64 fresh installation, 180+ updates, 2GB of RAM). The only workaround I found at the moment is to split updates in three parts; this way it takes me even more time...but it works without problems...if you don't care CPU usage at 100% and computer completely paralized.

We also have this issue with our clients (4GB RAM)
According to the WindowsUpdate.log file the scanning takes only 5 minutes.

But in those 5 minutes the clients are suffering from paging and I see the disk queue length
increasing above 10 (where it is normally around 0.05).

I changed the Windows Update service type to create it's own svchost process.

I also ran the Decline-SupersededUpdates powershell script with the -SkipDecline argument
to get an idea of the number of superseded updates on the WSUS server.

In our case we get the following result:

Summary:
========
All Updates = 12827
Any except Declined = 12565
All Superseded Updates = 6522
    Superseded Updates (Intermediate) = 4101
    Superseded Updates (Last Level) = 2421

SkipDecline flag is set to True. Skipped declining updates

Does anybody else has the same results? 
In our case it seems that 50% of the updates in WSUS are superseded in some way.

Also important to know is that we use SCCM to deploy updates and
we also run the "Server Cleanup Wizard" from within WSUS every month.

Hopefully Microsoft releases the hotfix to address this issue soon.

Any news on this one ? WE have laptops with 2 GB memory, which are essentionally useless,

unless I disable windows updates service (wuauserv) .  The standalone machine, so SCCM does notreally have anything to do with it.

We have the same problem, although it is only happening on our x64 builds with less than 4GB RAM. I am currently in the process of rolling out a windows 7 x64 image. Although this problem has halted progress! Staff report machines as being unusable for around 20-30minutes each day (when clients check for updates). Running a manual update check has the same high memory usage problem as when clients check for updates which we manage using SCCM 2012.

Really hope a hotfix is provided soon, this is causing lots of frustration..... Any news on a hotfix release date? 

We have the same problem, although it is only happening on our x64 builds with less than 4GB RAM. I am currently in the process of rolling out a windows 7 x64 image. Although this problem has halted progress! Staff report machines as being unusable for around 20-30minutes each day (when clients check for updates). Running a manual update check has the same high memory usage problem as when clients check for updates which we manage using SCCM 2012.

Really hope a hotfix is provided soon, this is causing lots of frustration..... Any news on a hotfix release date? 

Hey Brent,

Running the scripts from this article on the WSUS DB will help.. http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

It didn't fixed the problem entirely but it shortened the memory spike. and made the the computer usable after a few minutes vs waiting for 30-40 minutes.

There is a notable difference.

We have the same problem, although it is only happening on our x64 builds with less than 4GB RAM. I am currently in the process of rolling out a windows 7 x64 image. Although this problem has halted progress! Staff report machines as being unusable for around 20-30minutes each day (when clients check for updates). Running a manual update check has the same high memory usage problem as when clients check for updates which we manage using SCCM 2012.

Really hope a hotfix is provided soon, this is causing lots of frustration..... Any news on a hotfix release date? 

Hey Brent,

Running the scripts from this article on the WSUS DB will help.. http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

It didn't fixed the problem entirely but it shortened the memory spike. and made the the computer usable after a few minutes vs waiting for 30-40 minutes.

There is a notable difference.

Thanks for replying. I have just tried this on our WSUS server and must say it has improved things massively! Cleaned up ~19,000 updates, memory usage appears to be much more manageable for now...... 

I've been following this post also. Thanks Brent.  I need to ask,  if I run Server cleanup EVERYDAY and Decline 'Superseded Updates' why then are there sooo many 'Unneeded' updates to be declined - as was pointed out in the link you posted above? Could this be a problem related to the core issue of this thread?

I also have been following this, and we have ~75 machines having this issue with Windows 7. But we currently do not use our own WSUS server. Is there no way to fix this when using Microsofts servers? This seems like a fairly large issue for MS to overlook.

I can see why the issue is there, when the client has to go through and compare 20k+ updates to what it currently has installed.

I did try the idea in the post about SFC above on a few machines, but the scans found no issues. And the memory issue for me is still present.

Same here - working with Microsoft, will post if there is a fix. no WSUS just Kaseya agents in one case and Logmein agents in another, 180 machines affected.

Same problem here. We've been experiencing this issue on all computers running W7 Enterprise SP1 x86 with 2 Gbyte RAM or less. Our WUAUENG.DLL version is 7.6.7600.256 (dated 2012) and the problem is present, so it's definitely not an issue of the engine, but rather something they changed on the updates catalog.

I've personally seen this happening on both W7 Pro / Enterprise and with or without WSUS, with or without SCCM.

We will probably open a service request with MS and will post it here if anything useful comes up.

Best Regards,

Gabriel

• Edited by G.Priarone Thursday, May 14, 2015 8:21 AM

We currently have same issues with Windows Updater. At the moment, we have no solution to the problem than the stop Update Service.

Out of curiosity, has anybody discussed this issue with their legal department?

We have spent thousands of dollars in staff hours and hardware to troubleshoot this and upgrade our users to 8 GB of memory and our department was definitely interested in the details. It seems rather obvious that this problem can be attributed to previous updates which could be uninstalled until the patch was released. Yet, MS is not releasing any information other than we have to wait until approximately the end of Q2 which seems a bit ridiculous considering how serious this is.

Thoughts anyone?

I have v256 on a i5 2nd gen machine 6 GB RAM 1333 just turned on since last Aug and tried a performance update check test update It uses 400MB max (from 1.6 to 2GB) normal operation. I shut off all updates until MS gets their shit together. I will send said dll to whom ever for testing as long as no conflicts with this site or Microsoft. BTW they should use Oracle for a db instead of SQLserver Next test: will allow updates (made a copy of dll and restore point). Deleted all C:\Windows\SoftwareDistribution to narrow down KB. It makes no difference.

v256 WU turned on no big deal hovers 1.9 GB asking to install new Windows Update. I say OK and let updates happen

most recent check for updates: never:...scanning 10:32 oh on 7500Mbs home fibre with latest modem everything. 10:39 I have 132/20 updates, My WU is now v320. Will. Shoots to 3GB flat out. Had to upgrade to get this far. 10:52, 3.3GB RAM and stable but I had a lot of updates. 10:59 3.39 GB. 11:07, 3,7 GB steady. 11:33PM 4.26 GB RAM and nothing has really changed since I am  watching TV and afk. 11:40PM 'm at 4.25 GB and at 99 of 125 updates. 11:49PM I give up, at 4.7GBour of 109 of 125 and climbing. 11:53 5.25GB Mem gone. The whole time I had 1-ie, 1-taskManager, 1-WU 1-MS Securities Bluetooth yadayada 1.6 GB worth. Anyway my updates are done (12:AM) RAM is steady at 5GB and I have to reboot so goodnight

Moral of story, if you have 6GB or more you are OK. I don't think 4GB is enuff. at 4.whatever - 1.6(norml) at least 4 GB gone to WU so update independently or, if you can, blame it on the contractor :)

• Edited by Chrid Guidry Friday, May 15, 2015 3:02 AM

Hi there, same problem in our organisation - SCCM 2012 R2 + clients W7 with 2GB RAM - when update scan run, then clients are not usable...

With quite a few people pinning their hopes on this blog, even with its misleading title, has there been any official linkage from people who've actually raised this specific issue with Microsoft, to confirm that the work that is rumoured in the Blog post, is ACTUALLY addressing an issue that is relevant to the symptoms described here ?

There are some reasons to be hopeful, a suggestion that in memory structures used during the scanning process demand a very large memory footprint, but I've not seen anything showing a conclusive statement of cause and effect.

I've seen a few people have stated that a call has been raised with Microsoft, but the evidence of Microsoft responses seems merely to provide a set of housekeeping activities (i.e. Mitigation by reducing the complexity of the checking), and in no cases I've noticed has there been a statement from Microsoft that recognises a coding issue, and confirms that they are working to fix it.

One thing that people probably should be encouraged to apply is to split WUAUSERV into its own service - this is a very simple (and fully supported) change which will help with memory management for the wuauserv component - in particular avoiding progressive fragmentation problems that can complicate the situation if the code runs in a shared svchost.exe.

Separating wuauserv should also help confirm that high memory usage by svchost.exe is caused by wuauserv and not by other services that share the same container. That can help people recognise this specific problem, as distinct from any others that cause similar symptoms in one or other of the svchost.exe processes that are 'normal' for Windows 7.

Steelie - can you comment ? Are we pinning our hopes on thin air ?

 

Hi

We also have the same issue as everyone else.  In fact it seems to be getting worse as more and more PC's at my company slow down due to the WUAUSERV service.  We have on a few PC's, that became too slow to use, disabled Windows Updates from running automatically and then manually update them each month.  Not ideal but is the best solution we have for now

I logged a support call with Microsoft regarding this just before Easter.  They are still working on it and don't seem to be getting any closer to a fix.  They take logs from our PC's and then apparently send them to their developers.  As so many people/companies are experiencing this issue I am amazed that they have not come up with a fix so far.  I will keep you updated each time they speak to me however

Hi,

Same problem here - all memory being sucked up until the PC becomes unusable and your're left with two options, either leave it and wait a couple of hours or kill the windows update service.

I've only seen it on two laptops so far but we have another three that my colleague found were extremely slow but was unable to diagnose which I believe probably are suffering from the same problem.  Also recently we've had to increase the memory on some machines from the same batch as they were running slowly.

Hoping Microsoft will release a fix soon!

@BonfireBoy

I attempted to post a comment directly in the blog post asking the author about this thread.  I asked him to post any relevant information either here or in the blog post, but after submitting my comment, a message popped up saying "comment pending moderator approval".  This was over a week ago and has not yet been approved or posted.

Interesting.. I just checked the blog again there was a comment posted today.  Maybe they missed mine?  I'll have to send it again. 

I just submitted a new comment, again greeted by this:

Thank you, your comment requires moderation so it may take a while to appear.  

• Edited by steelie Friday, May 15, 2015 7:56 PM

I raised a ticket with my IT dept to make them aware of this. They just want to do a wipe / reimage of my machine to fix it. They say "less than a dozen" other people have complained about it. Well everyone else I think is just used to their computers being slow all the time.

Also said they don't use WSUS or Windows Update. We get our patches from some Microsoft System Center. Not sure how it works but every Monday when I connect to the VPN it happens. It happens on my home machine also, which just uses normal old Windows Update for home users.

I ended up just using Belarc to find all my missing updates and applied them manually, cause I wasn't getting them all the other way.

They might send me a different laptop to test out, so if that one does it fresh out of the box I will just keep my old one. I will post back if the test machine does any better and see if I can figure out what settings are different. I know they have patched and changed a bunch of settings since my initial Win 7 install and who know if I got all the settings updates or not, or if I broke / enabled / disabled something to make it worse in the meantime.

Been running great all week this week though except for Monday morning. I think getting all the updates manually installed made whatever was triggering scans all the time stop.

Not sure if this matters or what DLL it is actually using but I have that WUAUENG.DLL in 3 places

I have all patches applied, so not sure why I dont have the v320 talked about.

C:\Windows\System32 v265 from 6/2/2012

C:\Windows\winsxs\amd64_microsoft-windows-w..wsupdateclient-core_31bf3856ad364e35_7.6.7600.256_none_d5f513f25190f276

C:\Windows\winsxs\amd64_microsoft-windows-w..wsupdateclient-core_31bf3856ad364e35_7.5.7601.17514_none_1f3413afc64d10c5 (Version is in folder name, dated 11/20/2010)

• Edited by jtp10181 Saturday, May 16, 2015 3:30 AM

Just wanted to post my info about the Windows Update version.

The windows update agent page is here: https://support.microsoft.com/en-us/kb/949104

This page suggests that version 7.6.7600.256 for Windows 7 is the latest version.

However, the download link provides version 7.6.7600.320.

But, the latest version on two Windows 7 SP1 systems I checked (one x86 and one x64) is 7.6.7601.18804 and was last modified March 24th, 2015.

It should be noted that this problem is not limited to Windows 7.  It is exactly the same on Vista.  And I suspect Windows 8 is just as bad, but all those machines have at least 4GB of RAM or more, so its not noticeable.

I will say that the suggestion to move the Windows Update process to its own svchost process has helped.  Using the following command: sc config wuauserv type= own and then restarting the Windows Update service helped.

After the change, on the 32-bit system, I experience about 500MB RAM usage during the scan, with a single, very brief spike to 800MB.  After the scan finished it sat idle, using around 230MB for several minutes, then dropped off the list of high memory processes all together.

On the 64-bit system, prior to the change, during a scan memory usage was around 1.1GB and spiked up several times and reached 1.8GB at one point and then idled at around 530MB for several minutes.  After the change the memory usage was around 800MB with a couple of spikes up to 1.2GB at one point and then idled around 373MB for several minutes.  The second scan, after the change, was much faster.

Not drastic improvements, but anything helps here.

1. Part of memory is used for graphics and you have not 2GB but less than that.

2. Upgarade RAM (physical RAM. The more you have the better.)

3. Computers with "native" graphics card will respond more slowely that that of having separate graphics card (more graphics processing is removed from CPU to dedicated GPU)

4. Notebooks has "light" version of CPU with one or two cores.(The more cores the CPU has, the more power is needed and notebooks live on battery much shortly.)

5. As we know nothing about application on your computer, we could hardly give a reasonable advice on application optimalization. Find info on application(s) prerequisites.

6. There is general optimalization that may help in some situation, but do not expect any dramatic improvement.

7. "High memory usage" does not say too much. More important parameter is how fast is process of "internal cleaning" of RAM when other application(s) need to share memory.

Regards

Milos

• Edited by Milos Puchta Saturday, May 16, 2015 8:06 PM

wuauserv is crazy.

sc config wuauserv type= own will make the world a little more peaceful.

• Edited by Z5L Saturday, May 16, 2015 10:54 PM

1. Part of memory is used for graphics and you have not 2GB but less than that.

2. Upgarade RAM (physical RAM. The more you have the better.)

3. Computers with "native" graphics card will respond more slowely that that of having separate graphics card (more graphics processing is removed from CPU to dedicated GPU)

4. Notebooks has "light" version of CPU with one or two cores.(The more cores the CPU has, the more power is needed and notebooks live on battery much shortly.)

5. As we know nothing about application on your computer, we could hardly give a reasonable advice on application optimalization. Find info on application(s) prerequisites.

6. There is general optimalization that may help in some situation, but do not expect any dramatic improvement.

7. "High memory usage" does not say too much. More important parameter is how fast is process of "internal cleaning" of RAM when other application(s) need to share memory.

Regards

Milos

Milos, I'm not sure you have read this thread if that is all you have to contribute.

I don't know how Windows determines when to run these scans, it doesn't seem related to the setting that lets you specify when to install important updates automatically. I have those set to 2AM but these scans that eat up all the RAM run at various times during the day for each user.

So far I have had success by running the /detectnow option at more preferable times, generally after they have left for the day and log off, and it seems to reschedule it. Not really a fix but it keeps people happy...

%windir%\system32\wuauclt.exe /detectnow

We've been working on this problem since a few days now, and the solution proposed by Barryt_jam above (declining all superseded updates on WSUS) somewhat has definitely reduced the problem.

A few discoveries i've made:

• This problem is not related to the agent, a patch, or whatever. We've reinstalled 2 different machines with a Windows 7 image captured 2 years ago (which DID NOT have any problem back then) and as soon as the installation process has finished and the first windows update check is made, the memory problem immediately shows up. This logically proves the problem is not on the clients side, but rather on the server side (the windows update catalog is getting too big?).
  
• We declined all superseded updates from our WSUS and the memory usage on the clients went from 1.1 Gb (peak) down to 600 mb (peak). This is much more acceptable and dramatically improves performance during updates.
• If we try to ignore our WSUS and point the agent back to Windows Update online, the memory peaks to around 900 Mb again.
• Part of the problem seems to be the Microsoft Antimalware engine and its definition updates. Firstly it makes windows update check triggers more often, and secondly i've tested that by removing it memory usage is almost halved.

I hope these information are useful to someone else ...

Best regards,

Gabriel

I have a domain joined Dell Vostro 1700 laptop with Windows 7 SP1 (x64) with 2GB of RAM that hadnt been turned on in a while.  This machine is running only Microsoft Security Essentials and still had Internet Explorer 10 installed.  I turned it on a few days ago with the intent of getting it ready for use by a coworker.  I turned the machine on, established that it was able to connect to our network (and WSUS server) and started the windows update service knowing that it might take a while to install all of its pending updates.   I left the machine running overnight and came back to install 122 updates the next morning, power cycled, checked again for updates and at this point noticed the memory issue that dominates this forum and began looking into it.  I eventually left as I figured it wouldnt hurt to just let it run in this sluggish state for the entire weekend trying to let it get caught up.  When I returned yesterday morning it was still exhibiting this problem.  The symptoms are as follows:

1.       Slow to boot.
2.       Slow to log in
3.       Once logged in sluggish in response to commands.
4.       Using the GUI to begin checking for windows updates - it starts looking and gets kind of stuck staring off into WSUS space for hours.
5.       Once the windows update automatic update service has been called the svchost.exe process that calls it begins slowing consuming memory until the machine is almost entirely unresponsive and greater than 90% of memory is in use.
6.       I leave it running overnight and come back the next day and it has turned itself off.  Booting the machine usually fires off the installation of a round of updates but symptoms continue once booted.
7.       Turning off the Windows Update Service restores  the machine to a usable state

I should say at this point that the problem for me seems to have been resolved or at least the windows update service no longer gets stuck staring into WSUS space and the process no longer consumes every last scrap of available memory for hours while its checking for updates.  Here are the steps I took in the order I took them:

1.       I moved the windows update automatic update service to its own svchost.exe process to prevent memory fragmentation per suggestions above:
   1.        Run command prompt as admin:
   2.       sc config wuauserv type=own
   3.        net stop wuauserv
   4.       net start wuauserv
      1. i.      problem persists
2.       Flushed the DataStore folder:
   1.       net stop wuauserv
   2.       net stop bits
   3.       rd /s /q %windir%\softwaredistribution
   4.       net start bits
   5.       net start wuauserv
      1. i.      Problem actually seemed worse at this point
3.       Downloaded and installed the latest version of Windows Update:
   1.        https://support.microsoft.com/en-us/kb/949104
      1. i.      Problem persists
4.       On the WSUS server, ran the WSUS Server Cleanup Wizard which automatically declines superseded updates.
   1.        Problem persists
5.       At this point I began uninstalling everything that wasnt absolutely necessary.  I booted into safe mode and uninstalled as many programs as I could.
   1.        Windows update service doesnt run in safe mode.
6.       I then booted back into normal windows and continued uninstalling everything that I couldnt uninstall in safe mode.
   1.        Problem persists
7.       Ran System File Check and rebooted
   1.        sfc \scannow
      1. i.      Problem persists
8.       I looked at the status of this laptop on the WSUS server to see which major updates hadnt yet been installed and saw that it still needed the update that installs Internet Explorer 11.  I figured I could install that one manually:
   1.        Turned off Windows Update Service so that I could actually use the machine
      1. i.      net stop wuauserv
   2.       Downloaded and installed IE 11 manually.
      1. i.      http://windows.microsoft.com/en-us/internet-explorer/download-ie
9.       At this point it seems like the problems persist even after installing IE 11.  High memory usage on the svchost process holding the update service even after rebooting the problem persists but then the windows update service eventually finds and installs a few more updates and upon booting up this morning
   1.        The problem seems to finally be resolved.

I just hit check for updates and the process that is running the windows update service spikes up to 700MB for a minute or two then spikes all the way up to 1.5GB (on this 2GB machine) so the problem isn't 100% resolved but it comes back saying that Windows is up to date within a few minutes and the process goes back down to a much more reasonable 120 MB.  The WSUS server indicates that the laptop has 100% of its updates and the machine is once again running as it should.

Given that most of the folks on this forum have likely tried a number of the above suggestions, Id like to know if Internet Explorer 10 is a common theme or if Im just experiencing a temporary reprieve from a more persistent problem  Or if maybe my issues were unrelated?

Edit: I also removed most of my printers at some point. 

• Edited by RobbyMcMurry Tuesday, May 19, 2015 6:00 PM

Robby, coincidence I think.  I've got IE11 installed with the latest update, 4GB ram, and when I run updates it spikes at >1.7G.

Edit: What I had seen as a spike to 1.2G is because that is where memory filled up.  I closed down everything and re-ran the scan for updates and Process Explorer reports the following:

Peak Working Set: 1,748,448 K

Disk I/O Read Bytes: 10 MB

Receive Bytes: 24.1 KB

What!?!? It's reading 10 meg from the disk and receiving 24.1 K from the network and it's expanding to >2.1GB virtual with >1.7GB working?

Insane.

I have turned off automatic checking for updates.  This is intolerable.

• Edited by CaptainWasabi Tuesday, May 19, 2015 5:48 PM

the only fix i found out to be working OK " in my case"  but diffidently not a solution is uninstalling office 2013 from a workstation and / or  removing office 2013 from wsus catalog 

@Spyle1

Check my earlier posts.. There seems to be a way to 'somewhat' cause a more predictable scan time, but I've had mixed results.  It's worth a shot if it works for you...

@RobbieMcMurry

I'm guessing it's a coincidence.  There is some caching of scan results, so it may be checking the online catalog against cached results, which would be much faster.  I bet next month after the new updates are released (or probably any new update between now and then) the problem will re-occur.

I can take a plain Windows 7 VM, 64bit, and watch the memory skyrocket when kicking off an update. I don't see it linked to MS Office. Having MS Office might increase the memory usage because it's an additional product to scan for.

We've been working with MSFT for awhile now and we are at a bit of a loss. All the steps we've taken (and have been outlined in this thread) have helped but I think we should just resolve that a Hotfix will be out late Q2 2015 as was blogged here: http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx.

It says: "A hotfix for the Windows Update Agent is currently in development. The update will change how the update metadata is loaded into memory. Pending the results of final testing, this fix should be available late in the 2nd quarter of CY2015. This post will be updated with more information as it becomes available."

We may need to limp along here til this is out.

Hi All,

I may have a temporary workaround. I created 2 bat files with the following commands:

First bat

sc config wuauserv start= disabled

sc stop wuauserv

Second bat

sc config wuauserv start= auto

sc start wuauserv

Put these files in a Task Scheduler and have them start at logon.  Have the second one start with an hour delay.  Make sure it is running with administrative privileges.  I have tested it and my logon script went from 40 minutes to run to 1 minute.  This will allow users to login in the morning without being bogged down and your patch management concerns are covered.

hi all,

any new information about hotfix ?

I think it's just a waiting game at this point.

We have the same issue in our SCCM environment

While we wait a hotfix, we have applied following on our clients.

NET STOP WUAUSERV
NET STOP BITS
sc config wuauserv type= own
NET START BITS
NET START WUAUSERV

We also cleanup the windowsupdate folder.

rd /s /q %windir%\softwaredistribution

This helps a bit, not much but we see a positive result doing this.

We hope a hotfix will be available soon!

------------------------------------------------------------------------------------------

dimi

We have the same issue. SCCM 2012 R2 environment, Win7 32bit/64bit with less than 3Gb memory have this problem.

My colleague found that kb3004394 and rootsupd.exe helps to speed up first updates installation process. I have been tested this solution on my test VMs and they updates successfully. But It looks like it's not helps with second and following scan updates. Could anyone check it?

With so many people having the same (very confirmed) problem, I really cannot understand why wouldn't a Microsoft's employee post in this thread, to tell us what is going on. Every rumor of a "fix" that has been posted here was posted by fellow thread users, not by Microsoft. It is really appalling they won't even address our problem here.

I am having the same issue as this, having just re-installed Win7 on a friends PC.

Joining this thread to keep updated.

Thank you steelie for keeping on top of this.  Let's hope MS provide a fix as soon as possible!!

have somebody information about state this hotfix from microsoft ?

I definitely approve. It's a shame.

Maybe they have something better to do than maintaining the OS installed on most desktop (net market share ~ 60%). 

Another tech here with another group of clients who don't have an answer yet !!! Not good enough MS

An update to fix the issue has been rolled out:

support.microsoft.com/en-us/kb/3050265

Thank you all for your patience.

• Proposed as answer by 3050265 10 hours 22 minutes ago

I've rolled this out on 1 machine for testing and so far memory usage has dropped from 900,000k before fix to average of 154,000k after, so far so good.....

I can confirm it. Windows update process consumes now average 120Mb instead of 1-2GB per scan