My RAM and CPU has improved significantly when doing scans for updates. That's why I've stopped ignoring the WU client updates. I just use the GP workaround to block the 10 upgrade. But, I've seen no ill-effects from installing those on my system, only an improvement while scanning.
Maybe check this post:
100% CPU Usage svchost.exe windows update eror 0x80070005 Please Read
If you can run RAMmap in your VM does it show high memory usage by datastore.edb ?
Take a look at my earlier post:
https://www.sevenforums.com/general-d...ml#post3141430
I gave RAMMap a try. Sadly, I could not get the RAM to go over 2.2GB out of 4GB. (I changed the RAM assigned - as I have done in the past - to let the scan go faster.) I did not wait for the installation of the updates. The database file did have about the same amount of RAM assigned to it that your screenshot showed - but the vast majority of it was not locked.
Once again, my current list and my WUA version is 7.6.7601.18979
Updates not to Install
KB2876229 SKYPE, If you want Skype then install it.
KB2923545 RDP
KB2970228
KB3035583
KB2990214
KB3021917
KB3068708 Telemetry
KB2592687
KB2660075
KB2506928
KB2952664 x2
KB3050265
KB2726535
KB2994023
KB3022345 Replaced by KB3068708 Telemetry
KB3022345 Caused false sfc result
KB2545698 (IE9)
KB3065987
KB3077715
KB3078667
KB3080149 Telemetry
KB3075249 Telemetry
KB2999226
KB3083710
KB3097966
Well your screenshot shows the same problem with datastore.edb that I have seen on my own machine. No way should it show that many open handles.
Normal behaviour is like this:
With a windows update check in progress have a look at usage shown in the "Active" tab.
Also this is normal for the number of handles. I used Process Explorer but as you found out RAMmap can display some details on handles too.
Note: Memory usage by datastore.edb during WU checks seems to have crept up since I last checked. Here's how it appeared after the fix:
EDIT: Just for comparison. Screenshot of "Active" tab before the problem was fixed:
Last edited by Callender; 18 Oct 2015 at 09:59. Reason: add image
Could be ?
Little too close to Halloween for a spoofing update
Known issues in this security update
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
- Microsoft is aware of legitimate kernel drivers for D-Link products (including network adapters) that were signed by the affected D-Link certificates. These drivers include the Windows 7 drivers on the installation CD for the DUB-E100 USB network adapter. After you install this security update, these kernel drivers will no longer load, and the hardware will stop functioning. Updated drivers that aren't affected by this issue are available on Windows Update.
Callender,
I do see a high number of handles; about 790M. Deleting the softwaredistribution folder and starting with a fresh datastore database does cause fewer active handles (~186M). The overall RAM usage is the same; but, since most of that RAM was not locked by active handles, it is of little concern.
Rather than find the last good WU client, deleting the softwaredistribution folder seems easiest for fresh builds. For existing builds, such a deletion would unhide hidden updates. Perhaps the a more surgical approach might work.
Quote
