Windows 7 - CDF-MS files stuck in C:\Windows\winsxs\Temp\Pending Renames

Asked By TM on 12-Sep-07 09:06 AM
Hi - I'm running Windows Vista Home Premium Edition.

I have a group of six CDF-MS files stuck in C:\Windows\winsxs\Temp
\Pending Renames. Can anyone advise as to how I can get rid of them?

I don't seem to be able to change permissions to be able to get at
them. I've tried deleting them in Safe Mode, even tried turning off
the UAC, but nothing works.

If it helps, these are the files in question. All have been there
since 12.35pm on August 30th:

747a52e2f9eac701130000005c0d3c08.$$.cdf-ms
7456cfe3f9eac7011a0000005c0d3c08.$$_system32_21f9a9c4a2f8b514.cdf-ms
141950e2f9eac701120000005c0d3c08._0000000000000000.cdf-ms
f4d0c5e3f9eac701180000005c0d3c08._0000000000000000.cdf-ms
f4d0c5e3f9eac701190000005c0d3c08.$$.cdf-ms
f4ff5be2f9eac701140000005c0d3c08.$$_system32_21f9a9c4a2f8b514.cdf-ms

This XML Document file is also stuck in the same folder:

94f6f1e2f9eac701160000005c0d3c08.pending

Any help appreciated.

Many thanks -


TM




bob.andrews replied on 14-Sep-07 02:51 PM
These files are waiting for Windows update to do something with them
on reboot, and perhaps something about that has become corrupted, so
they are in limbo.  You can't delete them because they are owned by
the "Trusted Installer" account, which is a special account used only
by Windows Installer.  To delete them, you first need to take
ownership (right click, properties, security, advanced, owner, EDIT,
choose the new owner, Apply); then you can grant yourself full
control.

But before you do that, you may be able to get out of limbo with a
registry edit.
Have a look at HKLM/ Components for entries that have something to do
with pending windows updates:   if you see PendingXmIdentifier and
AdvanacdInstallersNeedResolving, then export the Components key to be
safe, then delete both those entries, and reboot.  Then try to run
Windows Update and you may find it fixes all those temp/pending files
for you.

Also, if you're curious, if you open the XML file in a browser, you
likely can read the Knowledge Base number from one of the first lines,
which will let you identify which particular Windows Update messed up.
mrbsky replied on 14-Sep-07 03:23 PM
These files are waiting for Windows update to do something with them
on reboot, and perhaps something about that has become corrupted, so
they are in limbo.  You can't delete them because they are owned by
the "Trusted Installer" account, which is a special account used only
by Windows Installer.  To delete them, you first need to take
ownership (right click, properties, security, advanced, owner, EDIT,
choose the new owner, Apply); then you can grant yourself full
control.

But before you do that, you may be able to get out of limbo with a
registry edit.
Have a look at HKLM/ Components for entries that have something to do
with pending windows updates:   if you see PendingXmIdentifier and
AdvanacdInstallersNeedResolving, then export the Components key to be
safe, then delete both those entries, and reboot.  Then try to run
Windows Update and you may find it fixes all those temp/pending files
for you.

Also, if you're curious, if you open the XML file in a browser, you
likely can read the Knowledge Base number from one of the first lines,
which will let you identify which particular Windows Update messed
up.
TM replied on 15-Sep-07 09:19 AM
Many thanks, bluesky1 - I deleted them via the "Trusted Installer"
route.

TM
cmeredith3005 replied on 15-Dec-07 03:32 AM
I'm having a very similar problem with PendingRenames.  I started down
this road in an effort to resolve a problem I'm having with Media Player
and Media Center with regards to the media library.  I decided to give
sfc a go.  I've run it with Administrative privileges from within Vista
in normal mode and in safe mode (also Admin).  Like everyone else having
this problem, it barfs at about 99% complaining of corrupt files.  When
I examine the cbs.log, I encounter a long list of issues with pending
renames.  When I findstr (findstr /c:\"[SR]\" %windir%\logs\cbs\cbs.log
one of their KBs, everything is nominal.

I suspect that the error generated from sfc is a bit of a catch-all, in
that not everything succeeded during sfc's execution, so it assumes that
SOMETHING must be corrupt for it to not have succeeded ... including
renaming files.

In my case, there are an inordinate number of entries in
PendingRenames.  About 2600, I think.

The registry entries that indicate pending operations to rename/clean
up these files are not present.  My system has successfully rebooted
many times with the condition and I've also been able to update the
system, install software, uninstall software, etc., without any
noticeable problems.

I considered simply living with the problem until I recalled occasions
when TrustedInstaller would start gobbling up CPU cycles for long
periods of time for no apparent reason (no installion running, etc.).
It occurred to me that the process might be wrestling with the
PendingRenames directory among other things.  So, I'm interested in
clearing this problem up.

Another thing to note is that I can recall killing the TrustedInstaller
process in the past when I would see it race (not when there was an
installation ongoing).  I can only imagine that I might have made things
worse or possibly have caused the problem myself.  I like to think that
the problem already existed.

Regardless, I took ownership of the PendingRenames directory and files
and modified the security of same and moved all of the files to an
archived directory (C:\PendingRemanesOld) as a precaution.  I restored
the security and ownership of the PendingRenames folder afterwards and
ran sfc again.  To my surprise, sfc failed again and produced a cbs.log
with a series of entries regarding PendingRenames.  This time, however,
the log was much shorter and there were only 842 files in
PendingRenames.  I thought this was very interesting.  I was monitoring
running processes during this whole operation and didn't see
TrustedInstaller execute.  I can only imagine that Windows File
Protection restored relevant files in PendingRenames.  I've yet to
restart the computer to see if the files will clear on their own.  I
suspect they won't be (I've rechecked the registry and the
HKLM\COMPONENTS entries have not been added).

I'll add another post to let you know what happens after I reboot.

Thanks,
Corey


--
cmeredith3005
cmeredith3005 replied on 16-Dec-07 06:02 AM
Following up on my last post.

Here's the sequence of things I did and I STILL have the 872 files in
PendingRenames:

1) Rebooted (back into normal mode ... not safe mode)
2) Took ownership of PendingRenames and files within
3) Modified security of same to give me full control
4) Deleted files within PendingRenames
5) Restored security and ownership settings of PendingRenames
6) Rebooted (back into normal mode ... not safe mode)
7) Checked PendingRenames (directory was still empty)
8) Ran sfc /scannow as administrator

sfc complained again at 99% and the 872 files magically reappeared.

I can't imagine that these files somehow fall under the purview of
Windows File Protection.  I can only guess at the source.  I'm at a
loss.  I'd love to hear if anyone has any ideas.

I suppose I could call this a curiosity at this point.  The system
seems stable enough despite a lingering problem I'm having with Media
Center that I need to address directly.

Thanks,
Corey


--
cmeredith3005