Showing posts with label Windows Update. Show all posts
Showing posts with label Windows Update. Show all posts

Wednesday, July 10, 2013

Windows Update not working, error 0x8DDD0018

This can happen with Windows XP (Service Pack 3), but may not be ruled out for Vista and 7.

Windows Update error 0x8DDD0018, by which the Microsoft Update website now very helpfully explains that one or more of these services are not running:
* Automatic Updates
* Background Intelligent Transfer Service (BITS);
* Event Log

Even if all these services are running, and Windows Update refuses to run, then the culprit is the Windows Installer service not being active.

Run services.msc and then start Windows Installer. Refresh the Windows Update website. #worksforme

Sunday, June 2, 2013

DataStore.edb and Windows Vista

This here is not so much an instruction, but a use case.

So I got me to look at a Windows Vista system that has been running for quite a long time. With just 1 (one) gigabyte of RAM.

At every operating system start, it would search for updates and the hard disk would thrash alot.

With Resource Monitor I discovered that the oft-accessed file was DataStore.edb, located at
%WINDIR%\SoftwareDistribution\DataStore\

DataStore.edb had ballooned to was the size of 325 MB.

The file is a log file in database format listing the history of all updates installed to the system, and also includes the current status of updates waiting to install.

Now, the typical solution[Yes, Citation needed] to this that I had been looking at on the interwebs has been to create a backup of this file and then delete it. After that, Windows Update won't list the history of all updates installed to the system, and that would be that. < Well, there's more than that :>

Before manipulating DataStore.edb, turn off the Windows Update service, because when that service is active, the DataStore file is in use.

esentutl

For a short while I thought that defagmenting this one file with a command-line tool called esentutl would be the solution, so I wanted to go on with it. The catch was that the tool would not be able to copy the defragmented file to its original location and yielding an error about it, saying that the defragmented TEMP file could still manually be taken to its original location, with the original file replaced. I didn't do it and left it at that.

By the way, the esentutl tool does not list where the .TMP file is located. I eventually found out that it was at the main user data folder of a logged-in user:
C:\Users\username

For a long time I couldn't put my finger on what it was that was not working, and then a month or two later it turned out that I had not been running the esentutl command in Administrator mode.

The full command for defragmenting the file went on like this:
esentutl /d %windir%\SoftwareDistribution\DataStore\DataStore.edb

So I launched Command Prompt as Administrator and the tool did its job as expected. So that was that.

But checking for updates in Windows Update took a lot of time anyway, and the hard disk still kept thrashing when checking for updates.

What happens when removing datastore.edb

Note that you will still have to back up the file, just in case...

Well, Windows Update then knows no history of previous updates and takes a lot of time to check for them. Maybe an hour. Or so, because I assume it will check updates file-by-file for nearly all present Microsoft software. Before, when the still-large datastore.edb file was there, it seemed that the check for updates actually took much, much less time. Since I didn't measure the actual minutes and did not compare, then I can't tell with any reliable numbers as to what the effect was with regards to differences in update checking times.

Anyways, after installing the updates, DataStore.edb was recreated and sported about the same size as before (over 315 MB). So, there is really no point in deleting the file.

Worse is, that there doesn't seem to be any built-in way to merge two separate DataStore.edb files into one cohesive database, if the older database were absent for a short while and another one created anew.

Then I just moved the recently backed-up datastore.edb back, and checking for updates in Windows Update took about ten minutes, including a reasonably minor database refresh on account of the May updates installed in the interim, which was not reflected there.

To avoid Windows Update thrashing the hard drive anyway, it's then best not to have the Windows Update service run with such a low RAM count at all (1 GB); perhaps with the exception of every second Tuesday each month.

So much for now.

28.04.2014 update:

I don't have that Vista computer at hand, or any other Vista computer in any useful proximity, so it's impossible to tell with precision where to optimize wrt Windows Update.

Point being that it's possible to keep Windows Update from checking updates at every startup by making changes in scheduling.
  • I remember there being a scheduler snap-in module in Windows Management Console, which feature-wise in Windows Vista replaced the Scheduled Tasks folder in Windows xp. The Task Scheduler snap-in is alot more complex and allows very granular configuration options.
  • Turning off automatic updates is useful for very experienced users. If the computer has behaved well, then I've usually set the Windows Update service to delayed start. Attempt this at your own risk. Even if the risk is low, it doesn't account for unintended behaviour, especially when making large updates, such as upgrades to Windows service packs.
I also hazily remember a separate update not advertised on Windows Update itself, that also must have improved the situation, if only a bit. The overall result was that the DataStore file was touched only when I launched the Windows Update program.

27.01.2016 update:

I recently got my hands on a snappy Windows 7 machine with 4 Gb of RAM.

After making a large number of updates through Windows Update, one of the recent updates was KB3102810 (installed on 18.01.2016). While it apparently does not directly concern the use of the DataStore file, I noticed some performance improvement after applying that update.

12.11.2016 update:

A comment from a linkback contains more information about the innards of datastore.edb.

Sunday, January 8, 2012

Updates information not visible in Windows Vista

So here's a scenario: When using Windows Update in Windows Vista, and the Windows Update front page shows an x number of critical updates and an x number of regular updates, and you click on either of them, the detailed updates listing is all blank; a user doesn't know then which updates should he choose (or not) to download and install.

The specimen in question was Windows Vista Home Basic Service Pack 2 in a Dell Studio 1535 notebook.

I tried and searched for many solutions, and somehow got the thing to work normally again, but I can't exactly put a finger on what it is that I did, partly because I was too lazy to restart after every move or document too diligently. #tired

Assuming everything else is more or less in order, then —

Services started in-between:
1. COM+ System Application, but didn't set it to start automatically.
2. Microsoft .NET Framework NGEN v2.0.50727_X86 (Delayed Start).
I had read somewhere that in Windows Vista, Windows Update for some reason required .NET Framework 2.0 to run.
So, if memory serves me correctly, I did install it one day, but at the time it didn't yield the required effect and I had to let it be...
And yes, there were regsvr32 things started and re-started from the command line, but that didn't quite help.

After a few hours of searching for a solution, with many a discussion thread suggesting starting and stopping services, registering and unregistering system files, I stumbled upon a set of suggestions that matched the conditions that I had. See the forum thread here.

Since there was a match in error conditions registering Windows Update files, I was confident about the solution as much as the tech guys were on the forum.

So the solution was to run

SFC /scannow

in a Command Prompt window run as Administrator. If you decide to do the same, then beforehand, create a system restore point or rely on a very recent one, for example one made just a few days ago.

SFC is the System File Checker command-line tool and its variant in modern Windows versions checks protected Windows system files against tampering and replaces those it that appear to be wrong.

I ran the tool, it took its while, but then it finished.
I also got to check out its logs (requires administrator mode to view in WordPad) and separated the most recent check into a new file for the sake of posterity. I couldn't see any substantial errors when changing files over, but there was a lot of movement going on.

Then did a restart, and lo and behold, details about individual updates in Windows Update were visible again! Yay!

Thursday, September 11, 2008

Uus värdsõna

Uus sõnavärd: "Windowsi õelvara eemaldamise tööriist - September 2008" (KB890830)"

Termini kasutus Microsofti abi ühel eestikeelsel leheküljel.

Täiendus: Sami blogis on veel sõnu.

Tuesday, September 2, 2008

Windows Update error 0X80072F89 in Windows 98

If anyone gets their hands on a really old computer with 32Mb of RAM and, of course, a legitimate installation of Windows 95/98 in it, updating that operating system through Windows Update may prove to be a slight hurdle.

Internet Explorer 5.0 on its own is now quite an old web browser, but there are at least two reasons why it's important to download updates through Windows Update:

  • After browsing around the web to research the error, the most common suggested remedy was to install Internet Explorer 6 on the computer, but given that as a major next version, a typical installation of IE6 would take more system resources to run on a computer with 32Mb of RAM, than, say, IE5 that's already been installed.
  • Connecting to Windows Update early is especially useful in cases when the computer keeps acting up because of a software issue that must be fixed first.

  1. The first useful suggestion I got is to update root certificates for Internet Explorer, as suggested here.
  2. And this nice Microsoft newsgroup post offers a direct download link for it. Just in case, I'm providing the download link for ROOTSUPD.EXE here, too.
After that, Windows Update should work fine.

So if Internet Explorer 5 has already been installed, Internet Explorer 5.01 Service Pack 2 might also solve the issue, but I can then only vouch for it once I get to update another computer with Windows 98 that's already been installed on a PC. To download IE5.01SP2 and other assorted browser goodies, the browser archive at evolt.org is the best place to start.