Windows Update Fails DnldMgr Error 0x8020000d

One of our Windows XP computers fails to run Windows Update correctly. It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the c:\windows\windowsupdate.log file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that another
program, such as CheckDisk, is not running, which would lock the volume.
When the volume is available, Background Intelligent Transfer Service (BITS)
will try aga


So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I find the
offending process / application?

--
W

W wrote:
One of our Windows XP computers fails to run Windows Update correctly. It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the c:\windows\windowsupdate.log file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that another
program, such as CheckDisk, is not running, which would lock the volume.
When the volume is available, Background Intelligent Transfer Service (BITS)
will try aga


So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I find the
offending process / application?


Maybe it's trying to put the download on a partition
other than C: ?

This page has some ideas for processes locking files, but your
complaint makes it sound like the entire partition is unavailable.

http://windowsxp.mvps.org/processlock.htm

I would use a copy of Process Monitor, and track the file operations,
or just "log everything" with Process Monitor and then go through the
log by hand. See what file system it's poking.

Process Monitor
http://technet.microsoft.com/en-us/s...rnals/bb896645

Paul

"Paul" wrote in message
...
W wrote:
One of our Windows XP computers fails to run Windows Update correctly.
It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the c:\windows\windowsupdate.log
file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that another
program, such as CheckDisk, is not running, which would lock the volume.
When the volume is available, Background Intelligent Transfer Service
(BITS)
will try aga


So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I find
the
offending process / application?


Maybe it's trying to put the download on a partition
other than C: ?

This page has some ideas for processes locking files, but your
complaint makes it sound like the entire partition is unavailable.

http://windowsxp.mvps.org/processlock.htm

I would use a copy of Process Monitor, and track the file operations,
or just "log everything" with Process Monitor and then go through the
log by hand. See what file system it's poking.

Process Monitor
http://technet.microsoft.com/en-us/s...rnals/bb896645

What I care about here are file operations of Windows Update? So in
Process Monitor I should watch MSIE only?

--
W

W wrote:
"Paul" wrote in message
...
W wrote:
One of our Windows XP computers fails to run Windows Update correctly.
It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the c:\windows\windowsupdate.log
file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that another
program, such as CheckDisk, is not running, which would lock the volume.
When the volume is available, Background Intelligent Transfer Service
(BITS)
will try aga


So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I find
the
offending process / application?

Maybe it's trying to put the download on a partition
other than C: ?

This page has some ideas for processes locking files, but your
complaint makes it sound like the entire partition is unavailable.

http://windowsxp.mvps.org/processlock.htm

I would use a copy of Process Monitor, and track the file operations,
or just "log everything" with Process Monitor and then go through the
log by hand. See what file system it's poking.

Process Monitor
http://technet.microsoft.com/en-us/s...rnals/bb896645

What I care about here are file operations of Windows Update? So in
Process Monitor I should watch MSIE only?


If the problem is reproducible on demand (run Windows Update manually),
then the log produced by Process Monitor can be scanned by hand for
evidence of what it's doing. That's what I'd try.

There could be services, "svchost" activity, for all I know. You can
set up a filter in Process Monitor, if you're absolutely sure of the
source of the events in question.

Process Monitor can run "RAM backed" or "file backed". The latter
option allows truly huge logs to be collected, if you need to do that.
But it's pretty silly to start out that way, attempting to collect
a big log, because it's so hard to go through it later. If the problem
is reproducible on demand, and in less than a minute or two, you might
not need to go to extraordinary lengths later, analyzing the results.
The time I created a 500MB log, it wasn't a lot of fun trying to
go through it later. Process Monitor produce a *ton* of data. If
you're debugging a program you wrote yourself, and you know all
the details (only the one process involved), then you can achieve
a lot using nothing but filters to reduce the collected data.

I managed to figure out a missing registry entry for a sound driver
on my computer, by using Process Monitor and collecting around 100,000
events. One of the attempts to access a certain registry key, which failed,
was the clue as to which registry key had gone missing. A sound driver
for another hardware sound device, had erased the key!

I'm not saying this exercise is easy. But on occasion, it does
give results.

If the "system volume was locked", you'd think there would be
consequences elsewhere on that computer. Other stuff failing.

Paul

"Paul" wrote in message
...
W wrote:
"Paul" wrote in message
...
W wrote:
One of our Windows XP computers fails to run Windows Update correctly.
It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the
c:\windows\windowsupdate.log
file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that
another
program, such as CheckDisk, is not running, which would lock the
volume.
When the volume is available, Background Intelligent Transfer Service
(BITS)
will try aga


So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I
find
the
offending process / application?

Maybe it's trying to put the download on a partition
other than C: ?

This page has some ideas for processes locking files, but your
complaint makes it sound like the entire partition is unavailable.

http://windowsxp.mvps.org/processlock.htm

I would use a copy of Process Monitor, and track the file operations,
or just "log everything" with Process Monitor and then go through the
log by hand. See what file system it's poking.

Process Monitor
http://technet.microsoft.com/en-us/s...rnals/bb896645

What I care about here are file operations of Windows Update? So in
Process Monitor I should watch MSIE only?


If the problem is reproducible on demand (run Windows Update manually),
then the log produced by Process Monitor can be scanned by hand for
evidence of what it's doing. That's what I'd try.

There could be services, "svchost" activity, for all I know. You can
set up a filter in Process Monitor, if you're absolutely sure of the
source of the events in question.

Process Monitor can run "RAM backed" or "file backed". The latter
option allows truly huge logs to be collected, if you need to do that.
But it's pretty silly to start out that way, attempting to collect
a big log, because it's so hard to go through it later. If the problem
is reproducible on demand, and in less than a minute or two, you might
not need to go to extraordinary lengths later, analyzing the results.
The time I created a 500MB log, it wasn't a lot of fun trying to
go through it later. Process Monitor produce a *ton* of data. If
you're debugging a program you wrote yourself, and you know all
the details (only the one process involved), then you can achieve
a lot using nothing but filters to reduce the collected data.

I managed to figure out a missing registry entry for a sound driver
on my computer, by using Process Monitor and collecting around 100,000
events. One of the attempts to access a certain registry key, which
failed,
was the clue as to which registry key had gone missing. A sound driver
for another hardware sound device, had erased the key!

I'm not saying this exercise is easy. But on occasion, it does
give results.

If the "system volume was locked", you'd think there would be
consequences elsewhere on that computer. Other stuff failing.

Since I am familiar with how huge the event list from Process Monitor can
be, I was hoping I could look at the MSIE process alone and figure from that
were the failure occurs. If I have to look outside of MSIE that promises
to be a really thankless task. Because something locked the volume
probably at boot time, and I'd never notice the event even if I were logging
it.

My guess is something is temporarily locking the volume and somehow leaving
a flag of that condition behind even after it stops locking the volume.

--
W

On 10/18/2013 4:48 PM, W wrote:
"Paul" wrote in message
...
W wrote:
"Paul" wrote in message
...
W wrote:
One of our Windows XP computers fails to run Windows Update correctly.
It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the
c:\windows\windowsupdate.log
file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that
another
program, such as CheckDisk, is not running, which would lock the
volume.
When the volume is available, Background Intelligent Transfer Service
(BITS)
will try aga


So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I
find
the
offending process / application?

Maybe it's trying to put the download on a partition
other than C: ?

This page has some ideas for processes locking files, but your
complaint makes it sound like the entire partition is unavailable.

http://windowsxp.mvps.org/processlock.htm

I would use a copy of Process Monitor, and track the file operations,
or just "log everything" with Process Monitor and then go through the
log by hand. See what file system it's poking.

Process Monitor
http://technet.microsoft.com/en-us/s...rnals/bb896645

What I care about here are file operations of Windows Update? So in
Process Monitor I should watch MSIE only?


If the problem is reproducible on demand (run Windows Update manually),
then the log produced by Process Monitor can be scanned by hand for
evidence of what it's doing. That's what I'd try.

There could be services, "svchost" activity, for all I know. You can
set up a filter in Process Monitor, if you're absolutely sure of the
source of the events in question.

Process Monitor can run "RAM backed" or "file backed". The latter
option allows truly huge logs to be collected, if you need to do that.
But it's pretty silly to start out that way, attempting to collect
a big log, because it's so hard to go through it later. If the problem
is reproducible on demand, and in less than a minute or two, you might
not need to go to extraordinary lengths later, analyzing the results.
The time I created a 500MB log, it wasn't a lot of fun trying to
go through it later. Process Monitor produce a *ton* of data. If
you're debugging a program you wrote yourself, and you know all
the details (only the one process involved), then you can achieve
a lot using nothing but filters to reduce the collected data.

I managed to figure out a missing registry entry for a sound driver
on my computer, by using Process Monitor and collecting around 100,000
events. One of the attempts to access a certain registry key, which
failed,
was the clue as to which registry key had gone missing. A sound driver
for another hardware sound device, had erased the key!

I'm not saying this exercise is easy. But on occasion, it does
give results.

If the "system volume was locked", you'd think there would be
consequences elsewhere on that computer. Other stuff failing.

Since I am familiar with how huge the event list from Process Monitor can
be, I was hoping I could look at the MSIE process alone and figure from that
were the failure occurs. If I have to look outside of MSIE that promises
to be a really thankless task. Because something locked the volume
probably at boot time, and I'd never notice the event even if I were logging
it.

My guess is something is temporarily locking the volume and somehow leaving
a flag of that condition behind even after it stops locking the volume.


FWIW, the last time I came across an error message like this, and it
was a very long time ago, was due to insufficient space in the system
partition. How much usuable space is there in the system partition for
the update files?

GR

"Ghostrider" wrote in message
m...
On 10/18/2013 4:48 PM, W wrote:
"Paul" wrote in message
...
W wrote:
"Paul" wrote in message
...
W wrote:
One of our Windows XP computers fails to run Windows Update
correctly.
It
finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the
c:\windows\windowsupdate.log
file
there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that
another
program, such as CheckDisk, is not running, which would lock the
volume.
When the volume is available, Background Intelligent Transfer Service
(BITS)
will try aga


So apparently some application we have installed is locking the
system
volume? Where do I even begin to figure out this one? How do I
find
the
offending process / application?

Maybe it's trying to put the download on a partition
other than C: ?

This page has some ideas for processes locking files, but your
complaint makes it sound like the entire partition is unavailable.

http://windowsxp.mvps.org/processlock.htm

I would use a copy of Process Monitor, and track the file operations,
or just "log everything" with Process Monitor and then go through the
log by hand. See what file system it's poking.

Process Monitor
http://technet.microsoft.com/en-us/s...rnals/bb896645

What I care about here are file operations of Windows Update? So in
Process Monitor I should watch MSIE only?


If the problem is reproducible on demand (run Windows Update manually),
then the log produced by Process Monitor can be scanned by hand for
evidence of what it's doing. That's what I'd try.

There could be services, "svchost" activity, for all I know. You can
set up a filter in Process Monitor, if you're absolutely sure of the
source of the events in question.

Process Monitor can run "RAM backed" or "file backed". The latter
option allows truly huge logs to be collected, if you need to do that.
But it's pretty silly to start out that way, attempting to collect
a big log, because it's so hard to go through it later. If the problem
is reproducible on demand, and in less than a minute or two, you might
not need to go to extraordinary lengths later, analyzing the results.
The time I created a 500MB log, it wasn't a lot of fun trying to
go through it later. Process Monitor produce a *ton* of data. If
you're debugging a program you wrote yourself, and you know all
the details (only the one process involved), then you can achieve
a lot using nothing but filters to reduce the collected data.

I managed to figure out a missing registry entry for a sound driver
on my computer, by using Process Monitor and collecting around 100,000
events. One of the attempts to access a certain registry key, which
failed,
was the clue as to which registry key had gone missing. A sound driver
for another hardware sound device, had erased the key!

I'm not saying this exercise is easy. But on occasion, it does
give results.

If the "system volume was locked", you'd think there would be
consequences elsewhere on that computer. Other stuff failing.

Since I am familiar with how huge the event list from Process Monitor can
be, I was hoping I could look at the MSIE process alone and figure from
that
were the failure occurs. If I have to look outside of MSIE that
promises
to be a really thankless task. Because something locked the volume
probably at boot time, and I'd never notice the event even if I were
logging
it.

My guess is something is temporarily locking the volume and somehow
leaving
a flag of that condition behind even after it stops locking the volume.


FWIW, the last time I came across an error message like this, and it
was a very long time ago, was due to insufficient space in the system
partition. How much usuable space is there in the system partition for
the update files?

The c: drive / system partition is 30GB and more than 5GB is still
available. But you might be onto something: I wonder if this could be a
permissions problem on some key folder that needs to be written to. I
assume Windows Update works as the Local System, and on our drives SYSTEM
would have Modify access to nearly everything.

--
W

"W" wrote in message
...
One of our Windows XP computers fails to run Windows Update correctly.
It finds updates to apply, but as soon as you start to apply updates it
immediately fails on ALL of them. In the c:\windows\windowsupdate.log
file there is the repeated error:

DnldMgr Error 0x8020000d occurred while downloading update

The only documentation I could find was on this web site:

http://inetexplorer.mvps.org/answers/63.html

It defines this error as:

0x8020000D -2145386483 BG_E_Destination_Locked
The destination file system volume is not available. Verify that another
program, such as CheckDisk, is not running, which would lock the volume.
When the volume is available, Background Intelligent Transfer Service
(BITS) will try aga

So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one? How do I find
the offending process / application?

So the offending application was an older version of Acronis Disk Director.
Apparently it was holding the system volume in some state Windows Update did
not like.

I have had good luck with Acronis Disk Director in many environments.
Unlike Acronis True Image - which is a horrific and buggy piece of
software - Disk Director has always been reliable for me.

--
W

Per W:
So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one?

I use a utility called WhoLockMe to find out what has what locked.

More often than not, it turns out to be a service called FolderSize that
I have installed (tells how much is in each folder). Slow learner
that I am, I keep forgetting to disable it before formatting drives.
--
Pete Cresswell

In message ,
"(PeteCresswell)" writes:
Per W:
So apparently some application we have installed is locking the system
volume? Where do I even begin to figure out this one?

I use a utility called WhoLockMe to find out what has what locked.

More often than not, it turns out to be a service called FolderSize that
I have installed (tells how much is in each folder). Slow learner
that I am, I keep forgetting to disable it before formatting drives.

I use unlocker - http://www.emptyloop.com/unlocker/ - for the same
purpose as WhoLockMe. The above website compares unlocker to lots of
other similar utilities (including WhoLockMe); of course, as you'd
expect from a table on its own website, it comes out ahead of the
competition.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

If you like making stuff there's always somebody ready to say that its
ridiculous. But, actually, I don't think it is. In fact, enthusiasms are good.
Hobbies are healthy. They don't harm anybody. - James May in RT, 6-12
November 2010.