Hi Technet,

I have a Server 08 R2 installation with process svchost.exe gradually increases memory usage over time until the servers performance suffers.

Using process explorer, in the handles pane, errors in path C:\Windows\SoftwareDistribution\DataStore\datastore.edb
The error:(An error occurred while reading or writing to a file).

Stopping the Windows update service clears the errors, restarting and they appear again.

I have run the Microsoft windows update fixit.

I have renamed the C:\Windows\SoftwareDistribution folder and allowed it to rebuild its contents.

I have used esentutl to both repair and defrag the datastore.edb, both performed successfully.
However the errors persist.

Can anyone assist in what my next troubleshooting steps would be please?

Thanks,

Andrew

Hi Andrew,

Please check if anyone of the following links is helpful:

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

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

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

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

Best Regards.

Thanks Steven for your suggestions,

I worked through all the KB's you mentioned and:

KB977357 was close, in that it is a svchost.exe process consuming the memory, but the second symptom of unable to restart the wmi was not true in my case.  The error in my case relates to the wuausvr database, which also runs in the same svchost.exe process.

KB2847346 relates to the NSI service, which is not running in the misbehaving svchost.exe

KB2703157 relates to the WinHttpAutoProxySvc , which is not the issue.

KB2889748 relates to WMF V3.0, the server is running powershell v2.0, and neither of the mentioned updates have been installed.

The processes running inside the svchost.exe are: 

AeLookupSvc, BITS, CertPropSvc, gpsvc, IKEEXT, iphlpsvc, LanmanServer, ProfSvc, Schedule, SENS, SessionEnv, ShellHWDetection, Winmgmt, wuauserv 

While I concede the error could very well be caused byany of these services, attached are the 

screenshots of the particular svchost with the wuauserv stopped, and then started again to show the errors generated. 

Thanks,

Andrew

• Edited by Digispar 4 hours 27 minutes ago typos

Thanks Steven for your suggestions,

I worked through all the KB's you mentioned and:

KB977357 was close, in that it is a svchost.exe process consuming the memory, but the second symptom of unable to restart the wmi was not true in my case.  The error in my case relates to the wuausvr database, which also runs in the same svchost.exe process.

KB2847346 relates to the NSI service, which is not running in the misbehaving svchost.exe

KB2703157 relates to the WinHttpAutoProxySvc , which is not the issue.

KB2889748 relates to WMF V3.0, the server is running powershell v2.0, and neither of the mentioned updates have been installed.

The processes running inside the svchost.exe are: 

AeLookupSvc, BITS, CertPropSvc, gpsvc, IKEEXT, iphlpsvc, LanmanServer, ProfSvc, Schedule, SENS, SessionEnv, ShellHWDetection, Winmgmt, wuauserv 

While I concede the error could very well be caused byany of these services, attached are the 

screenshots of the particular svchost with the wuauserv stopped, and then started again to show the errors generated. 

Thanks,

Andrew

• Edited by Digispar Wednesday, May 13, 2015 2:34 AM typos

Any updates on this issue?  I've been watching this thread for weeks, but thought I'd better join the discussion in hopes of bumping the visibility and response.

I have the same problem and have used procexp and procmon to come to the same conclusion, namely that there is a leak when reading the DataStore.edb file.  The memory usage for the related svchost during the Windows Update process grows to 2 GB.  Every. Single. Day.

I work in a large corporate environment where the configuration of the computers is tightly locked down.  Even our direct IT guys have limited control over when the Windows Update process is initiated.  Nevertheless, I have a limited admin privileges, so if I can help figure this thing out, just tell me what to do.

The leak occurs on both my desktop and laptop, both running Win7 SP1.  I'm confident others in my department suffer the same problem (because of the complaints I'm hearing), but haven't had time to verify.

What data do you need to know about my computers, Moderator, in order to help debug this problem?

Have you tried this?

Windows Update Client for Windows 7: June 2015

Hey Dugz, haven't come across any updates nor am I any closer to asolution.  

As a workaround I doubled the ram in the Server 08 machine, which alleviates the performance hit for users, but does nothing to address the actual issue.

• Edited by Digispar 2 hours 51 minutes ago

Thanks Rolf, I will install this and report back.

Hey Dugz, haven't come across any updates nor am I any closer to asolution.  

As a workaround I doubled the ram in the Server 08 machine, which alleviates the performance hit for users, but does nothing to address the actual issue.

• Edited by Digispar Tuesday, June 09, 2015 4:09 AM

Update:  I have installed the June 15 2015 windows update client update, and although it has only been 24 hours  the SVChost.exe running the windows update service is happily sitting on 94k memory usage.  I will monitor for a week and report back.

Update: the svchost process has crept back up to 1Gb ram, and the read/write errors to the Datastore.edb are still present. =/

Rolf:  That update is installed, but didn't help.

I've been requesting additional ram, but haven't received any.  But this is an absolute bug.  I shouldn't need to request additional ram.

Since I am lucky enough to have a little bit of admin power on my machine, I created a batch file that provides a bit of relief:

C:\tools> type GetMemBack.bat
net stop wuauserv
ping -n 2 localhost
%0

It runs recursively all day while I'm at work, stopping the Windows Update service once per second.  When I leave for the day, I kill the batch file and restart the Windows Update service.  I have verified that my IT department is OK with this, and that an Update does indeed occur.

Rolf:  That update is installed, but didn't help.

Thanks for reporting back.