TSWorkspace.dll cannot repair

Reported some time ago that I couldn't install KB3078601 and got a few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told me
to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful or
are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told me
to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful or
are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul

On 26/10/2015 07:58, Paul wrote:
Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told
me to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful
or are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul
Paul
Many thanks.
Just checked the WU list and KB2985461 installed successfully last year.
Where do I go from here please?
Thanks
aw56001

Andrew Wilson wrote:
On 26/10/2015 07:58, Paul wrote:
Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told
me to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful
or are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul
Paul
Many thanks.
Just checked the WU list and KB2985461 installed successfully last year.
Where do I go from here please?
Thanks
aw56001

There is a suggestion here, the message indicates a permissions problem.

When you run "sfc /scannow", it should be from an elevated command prompt.
When you type "cmd" in Start, and the list of found items is returned,
and the "cmd.exe" item at the top is visible, right click it and select
"Run as Administrator". Then, the Command Prompt window has the permissions
to start running SFC. But if you check CBS.log, it makes copious usage of
tiworker (TrustedInstaller worker), and tiworker has the token for
"trustedinstaller" account and can work on files in the System folder.
The administrator account cannot do that directly. The permissions are
set up such that tiworker does the work.

This article shows fiddling with permissions on a file, to let SFC proceed.

http://forum.thewindowsclub.com/wind...mber-file.html

(From "These links may interest some of you")

http://www.thewindowsclub.com/window...-corrupt-files

*******

The only other thing I know of is DISM restorehealth or checkSUR (for Win7).
SFC works on the DLLs in the actual System folder. CheckSUR works on the
component store, and a file from the component store is hard linked
into the System folder. I see no reason for CheckSUR to fix your
problem, but provide a link here anyway for your usage.

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

You want the latest download for CheckSUR that you can find. As far
as I know, the package is updated with information from security updates,
so the manifest for the various packages will be up to date, and any
packages found can have their store components fixed (re-downloaded perhaps).
The package is huge, but still not big enough to contain an entire copy
of the OS.

I'm still not able to find an article tying together SFC and CheckSUR/DISM,
and when we should be using one of those and not the other. But my guess
is, CheckSUR won't fix the actual copy in the System folder. SFC does that.
And SFC (and helpers) need the right permissions on the files to go forward.
That's why SFC uses tiworker and doesn't attack the files (as Administrator)
itself.

Paul

On 27/10/2015 00:07, Paul wrote:
Andrew Wilson wrote:
On 26/10/2015 07:58, Paul wrote:
Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told
me to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful
or are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul
Paul
Many thanks.
Just checked the WU list and KB2985461 installed successfully last
year. Where do I go from here please?
Thanks
aw56001

There is a suggestion here, the message indicates a permissions problem.

When you run "sfc /scannow", it should be from an elevated command prompt.
When you type "cmd" in Start, and the list of found items is returned,
and the "cmd.exe" item at the top is visible, right click it and select
"Run as Administrator". Then, the Command Prompt window has the permissions
to start running SFC. But if you check CBS.log, it makes copious usage of
tiworker (TrustedInstaller worker), and tiworker has the token for
"trustedinstaller" account and can work on files in the System folder.
The administrator account cannot do that directly. The permissions are
set up such that tiworker does the work.

This article shows fiddling with permissions on a file, to let SFC proceed.

http://forum.thewindowsclub.com/wind...mber-file.html


(From "These links may interest some of you")

http://www.thewindowsclub.com/window...-corrupt-files


*******

The only other thing I know of is DISM restorehealth or checkSUR (for
Win7).
SFC works on the DLLs in the actual System folder. CheckSUR works on the
component store, and a file from the component store is hard linked
into the System folder. I see no reason for CheckSUR to fix your
problem, but provide a link here anyway for your usage.

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

You want the latest download for CheckSUR that you can find. As far
as I know, the package is updated with information from security updates,
so the manifest for the various packages will be up to date, and any
packages found can have their store components fixed (re-downloaded
perhaps).
The package is huge, but still not big enough to contain an entire copy
of the OS.

I'm still not able to find an article tying together SFC and CheckSUR/DISM,
and when we should be using one of those and not the other. But my guess
is, CheckSUR won't fix the actual copy in the System folder. SFC does that.
And SFC (and helpers) need the right permissions on the files to go
forward.
That's why SFC uses tiworker and doesn't attack the files (as
Administrator)
itself.

Paul
Paul
Many thanks for the reply.
I'm not that good with computers so apologies but I'm a bit unsure as to
what you are suggesting that I do next.
Regards
aw56001

Andrew Wilson wrote:
On 27/10/2015 00:07, Paul wrote:
Andrew Wilson wrote:
On 26/10/2015 07:58, Paul wrote:
Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told
me to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful
or are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul
Paul
Many thanks.
Just checked the WU list and KB2985461 installed successfully last
year. Where do I go from here please?
Thanks
aw56001

There is a suggestion here, the message indicates a permissions problem.

When you run "sfc /scannow", it should be from an elevated command
prompt.
When you type "cmd" in Start, and the list of found items is returned,
and the "cmd.exe" item at the top is visible, right click it and select
"Run as Administrator". Then, the Command Prompt window has the
permissions
to start running SFC. But if you check CBS.log, it makes copious usage of
tiworker (TrustedInstaller worker), and tiworker has the token for
"trustedinstaller" account and can work on files in the System folder.
The administrator account cannot do that directly. The permissions are
set up such that tiworker does the work.

This article shows fiddling with permissions on a file, to let SFC
proceed.

http://forum.thewindowsclub.com/wind...mber-file.html



(From "These links may interest some of you")

http://www.thewindowsclub.com/window...-corrupt-files



*******

The only other thing I know of is DISM restorehealth or checkSUR (for
Win7).
SFC works on the DLLs in the actual System folder. CheckSUR works on the
component store, and a file from the component store is hard linked
into the System folder. I see no reason for CheckSUR to fix your
problem, but provide a link here anyway for your usage.

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

You want the latest download for CheckSUR that you can find. As far
as I know, the package is updated with information from security updates,
so the manifest for the various packages will be up to date, and any
packages found can have their store components fixed (re-downloaded
perhaps).
The package is huge, but still not big enough to contain an entire copy
of the OS.

I'm still not able to find an article tying together SFC and
CheckSUR/DISM,
and when we should be using one of those and not the other. But my guess
is, CheckSUR won't fix the actual copy in the System folder. SFC does
that.
And SFC (and helpers) need the right permissions on the files to go
forward.
That's why SFC uses tiworker and doesn't attack the files (as
Administrator)
itself.

Paul
Paul
Many thanks for the reply.
I'm not that good with computers so apologies but I'm a bit unsure as to
what you are suggesting that I do next.
Regards
aw56001

There are two tsworkspace.dll files.

C:\Windows\System32\TSWorkspace.dll
C:\Windows\SysWOW64\TSWorkspace.dll

Do properties on each one. See if it is owned
by TrustedInstaller. In the Properties, there
may be an Advanced button, that gives a list
of three or four "owners" of the thing. TrustedInstaller
is the only one that can make changes.

If TrustedInstaller doesn't have permission to do things,
then that could be a reason for SFC to fail.

SFC could fail for multiple reasons, like...

1) The package that installed it, says it is version
12345. A search of the Microsoft server, doesn't have
a version 12345. And SFC reports it cannot fix the item.
On one package where this happened, Microsoft admitted
the SFC system did not properly handle a couple of web
files in the package. A user would then ignore those failures
(for the time being).

2) SFC probably used TrustedInstaller account for its work,
because the directories it repairs are TrustedInstaller
areas. If a user (or a previous installer package) mess
up the permissions on a file, SFC might decide it cannot
repair the damage - because it doesn't have write access.
But being stupid software, it can't come right out and
say *why* it can't fix something. It's like all those
problem reports, where the error mess is "The parameter
is incorrect", and the message doesn't report what parameter,
what is wrong about it, and so on. Indistinct error messages
are a curse.

You can try checking the permissions, but without further info
in an error message, there's really no way to know for sure
what the problem is.

*******

You can try CheckSUR if you want, then try installing the package
in question again. CheckSUR is at least several hundred megabytes,
and should be downloaded fresh before you use it. If you have a
three month old one, it's probably time to get a later
version if it is available. The SUR stands for System Update Readiness.
CheckSUR might typically be used before a service pack is
about to be installed, but you can try it before your
Windows Update attempt.

You can also download the failing Windows Update and install it
manually. This has worked for me multiple times as a solution,
with no explanation why the outcome should be any different.
In this case, a file is offered for 32 bit Windows or 64 bit
Windows.

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

Windows 7 SP1 Download 32-bit (KB3078601)
Download 64-bit (KB3078601)

HTH,
Paul

On 27/10/2015 21:38, Paul wrote:
Andrew Wilson wrote:
On 27/10/2015 00:07, Paul wrote:
Andrew Wilson wrote:
On 26/10/2015 07:58, Paul wrote:
Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a
few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice told
me to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful
or are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul
Paul
Many thanks.
Just checked the WU list and KB2985461 installed successfully last
year. Where do I go from here please?
Thanks
aw56001

There is a suggestion here, the message indicates a permissions problem.

When you run "sfc /scannow", it should be from an elevated command
prompt.
When you type "cmd" in Start, and the list of found items is returned,
and the "cmd.exe" item at the top is visible, right click it and select
"Run as Administrator". Then, the Command Prompt window has the
permissions
to start running SFC. But if you check CBS.log, it makes copious
usage of
tiworker (TrustedInstaller worker), and tiworker has the token for
"trustedinstaller" account and can work on files in the System folder.
The administrator account cannot do that directly. The permissions are
set up such that tiworker does the work.

This article shows fiddling with permissions on a file, to let SFC
proceed.

http://forum.thewindowsclub.com/wind...mber-file.html



(From "These links may interest some of you")

http://www.thewindowsclub.com/window...-corrupt-files



*******

The only other thing I know of is DISM restorehealth or checkSUR (for
Win7).
SFC works on the DLLs in the actual System folder. CheckSUR works on the
component store, and a file from the component store is hard linked
into the System folder. I see no reason for CheckSUR to fix your
problem, but provide a link here anyway for your usage.

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

You want the latest download for CheckSUR that you can find. As far
as I know, the package is updated with information from security
updates,
so the manifest for the various packages will be up to date, and any
packages found can have their store components fixed (re-downloaded
perhaps).
The package is huge, but still not big enough to contain an entire copy
of the OS.

I'm still not able to find an article tying together SFC and
CheckSUR/DISM,
and when we should be using one of those and not the other. But my guess
is, CheckSUR won't fix the actual copy in the System folder. SFC does
that.
And SFC (and helpers) need the right permissions on the files to go
forward.
That's why SFC uses tiworker and doesn't attack the files (as
Administrator)
itself.

Paul
Paul
Many thanks for the reply.
I'm not that good with computers so apologies but I'm a bit unsure as
to what you are suggesting that I do next.
Regards
aw56001

There are two tsworkspace.dll files.

C:\Windows\System32\TSWorkspace.dll
C:\Windows\SysWOW64\TSWorkspace.dll

Do properties on each one. See if it is owned
by TrustedInstaller. In the Properties, there
may be an Advanced button, that gives a list
of three or four "owners" of the thing. TrustedInstaller
is the only one that can make changes.

If TrustedInstaller doesn't have permission to do things,
then that could be a reason for SFC to fail.

SFC could fail for multiple reasons, like...

1) The package that installed it, says it is version
12345. A search of the Microsoft server, doesn't have
a version 12345. And SFC reports it cannot fix the item.
On one package where this happened, Microsoft admitted
the SFC system did not properly handle a couple of web
files in the package. A user would then ignore those failures
(for the time being).

2) SFC probably used TrustedInstaller account for its work,
because the directories it repairs are TrustedInstaller
areas. If a user (or a previous installer package) mess
up the permissions on a file, SFC might decide it cannot
repair the damage - because it doesn't have write access.
But being stupid software, it can't come right out and
say *why* it can't fix something. It's like all those
problem reports, where the error mess is "The parameter
is incorrect", and the message doesn't report what parameter,
what is wrong about it, and so on. Indistinct error messages
are a curse.

You can try checking the permissions, but without further info
in an error message, there's really no way to know for sure
what the problem is.

*******

You can try CheckSUR if you want, then try installing the package
in question again. CheckSUR is at least several hundred megabytes,
and should be downloaded fresh before you use it. If you have a
three month old one, it's probably time to get a later
version if it is available. The SUR stands for System Update Readiness.
CheckSUR might typically be used before a service pack is
about to be installed, but you can try it before your
Windows Update attempt.

You can also download the failing Windows Update and install it
manually. This has worked for me multiple times as a solution,
with no explanation why the outcome should be any different.
In this case, a file is offered for 32 bit Windows or 64 bit
Windows.

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

Windows 7 SP1 Download 32-bit (KB3078601)
Download 64-bit (KB3078601)

HTH,
Paul
Paul
Thanks for your help.

C:\Windows\SysWOW64\TSWorkspace.dll owned by Trusted Installer but
doesn't have Special permissions and no option to change this although
has Full control/Modify/Read & Execute/Read/Write permissions.

C:\Windows\SysWOW64\TSWorkspace.dll doesn't apparently exist on my
system - problem?

Thanks
aw56001

On 30/10/2015 16:56, Andrew Wilson wrote:
On 27/10/2015 21:38, Paul wrote:
Andrew Wilson wrote:
On 27/10/2015 00:07, Paul wrote:
Andrew Wilson wrote:
On 26/10/2015 07:58, Paul wrote:
Andrew Wilson wrote:
Reported some time ago that I couldn't install KB3078601 and got a
few
replies but nothing worked.
Have been looking into it more and advised to do a 'sfc /scannow'.
Did this and read the cbs.log using notepad and some more advice
told
me to look for 'cannot repair' in Edit - Find next.
Did this OK and got 4 instances of - cannot repair TSWorkspace.dll
Have googled this but unsure if the results that come up are helpful
or are trying to get me to download dodgy software onto my machine.
Anyone help please?
Thanks
aw56001

This is a font security patch. Fonts appear to be
rendered by the kernel (or some part of the process
was put down there). The patch is probably related
to some exploit using font information to tip over
Windows.

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

TSWorkspace.dll is not mentioned in that update.
TSWOrkspace is likely to be Terminal Server Workspace.
RemoteApp on the other hand, may use TSWorkspace, but
there might not be a new copy of TSWorkspace in the update.
Which means maybe the update is checking the version
or something. The above patch mentions that a RemoteApp
issue also happens to be repaired by that patch.

Whereas this patch (from a year ago maybe), has copies
of tsworkspace.dll in it. Check your Windows Update history
and see if this patch succeeded or not.

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

For fun, I tried running sfc /scannow on my Win7sp1 Pro
and it said "nothing needed to be fixed". Yet, when I
checked CBS.log, it had queued up around 1800 files
for renaming (which might mean they were about
to be deleted). Since I made a backup of the C: drive
before running that thing, it didn't get to carry
out its mission on the next reboot :-) Most of the
involved files were of type cdf-ms.

Paul
Paul
Many thanks.
Just checked the WU list and KB2985461 installed successfully last
year. Where do I go from here please?
Thanks
aw56001

There is a suggestion here, the message indicates a permissions
problem.

When you run "sfc /scannow", it should be from an elevated command
prompt.
When you type "cmd" in Start, and the list of found items is returned,
and the "cmd.exe" item at the top is visible, right click it and select
"Run as Administrator". Then, the Command Prompt window has the
permissions
to start running SFC. But if you check CBS.log, it makes copious
usage of
tiworker (TrustedInstaller worker), and tiworker has the token for
"trustedinstaller" account and can work on files in the System folder.
The administrator account cannot do that directly. The permissions are
set up such that tiworker does the work.

This article shows fiddling with permissions on a file, to let SFC
proceed.

http://forum.thewindowsclub.com/wind...mber-file.html




(From "These links may interest some of you")

http://www.thewindowsclub.com/window...-corrupt-files




*******

The only other thing I know of is DISM restorehealth or checkSUR (for
Win7).
SFC works on the DLLs in the actual System folder. CheckSUR works on
the
component store, and a file from the component store is hard linked
into the System folder. I see no reason for CheckSUR to fix your
problem, but provide a link here anyway for your usage.

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

You want the latest download for CheckSUR that you can find. As far
as I know, the package is updated with information from security
updates,
so the manifest for the various packages will be up to date, and any
packages found can have their store components fixed (re-downloaded
perhaps).
The package is huge, but still not big enough to contain an entire copy
of the OS.

I'm still not able to find an article tying together SFC and
CheckSUR/DISM,
and when we should be using one of those and not the other. But my
guess
is, CheckSUR won't fix the actual copy in the System folder. SFC does
that.
And SFC (and helpers) need the right permissions on the files to go
forward.
That's why SFC uses tiworker and doesn't attack the files (as
Administrator)
itself.

Paul
Paul
Many thanks for the reply.
I'm not that good with computers so apologies but I'm a bit unsure as
to what you are suggesting that I do next.
Regards
aw56001

There are two tsworkspace.dll files.

C:\Windows\System32\TSWorkspace.dll
C:\Windows\SysWOW64\TSWorkspace.dll

Do properties on each one. See if it is owned
by TrustedInstaller. In the Properties, there
may be an Advanced button, that gives a list
of three or four "owners" of the thing. TrustedInstaller
is the only one that can make changes.

If TrustedInstaller doesn't have permission to do things,
then that could be a reason for SFC to fail.

SFC could fail for multiple reasons, like...

1) The package that installed it, says it is version
12345. A search of the Microsoft server, doesn't have
a version 12345. And SFC reports it cannot fix the item.
On one package where this happened, Microsoft admitted
the SFC system did not properly handle a couple of web
files in the package. A user would then ignore those failures
(for the time being).

2) SFC probably used TrustedInstaller account for its work,
because the directories it repairs are TrustedInstaller
areas. If a user (or a previous installer package) mess
up the permissions on a file, SFC might decide it cannot
repair the damage - because it doesn't have write access.
But being stupid software, it can't come right out and
say *why* it can't fix something. It's like all those
problem reports, where the error mess is "The parameter
is incorrect", and the message doesn't report what parameter,
what is wrong about it, and so on. Indistinct error messages
are a curse.

You can try checking the permissions, but without further info
in an error message, there's really no way to know for sure
what the problem is.

*******

You can try CheckSUR if you want, then try installing the package
in question again. CheckSUR is at least several hundred megabytes,
and should be downloaded fresh before you use it. If you have a
three month old one, it's probably time to get a later
version if it is available. The SUR stands for System Update Readiness.
CheckSUR might typically be used before a service pack is
about to be installed, but you can try it before your
Windows Update attempt.

You can also download the failing Windows Update and install it
manually. This has worked for me multiple times as a solution,
with no explanation why the outcome should be any different.
In this case, a file is offered for 32 bit Windows or 64 bit
Windows.

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

Windows 7 SP1 Download 32-bit (KB3078601)
Download 64-bit (KB3078601)

HTH,
Paul
Paul
Thanks for your help.

C:\Windows\System32\TSWorkspace.dll owned by Trusted Installer but
doesn't have Special permissions and no option to change this although
has Full control/Modify/Read & Execute/Read/Write permissions.

C:\Windows\SysWOW64\TSWorkspace.dll doesn't apparently exist on my
system - problem?

Thanks
aw56001

Andrew Wilson wrote:

Paul
Thanks for your help.

C:\Windows\System32\TSWorkspace.dll owned by Trusted Installer but
doesn't have Special permissions and no option to change this although
has Full control/Modify/Read & Execute/Read/Write permissions.

C:\Windows\SysWOW64\TSWorkspace.dll doesn't apparently exist on my
system - problem?

Thanks
aw56001


My information was for a 64 bit install.

I just checked a 32 bit install (in a VM) and

C:\Windows\System32\TSWorkspace.dll

is the only file in use right now. I guess a
32 bit OS doesn't have a SysWOW64 folder ? I
don't see a folder there.

Paul

On 30/10/2015 21:48, Paul wrote:
Andrew Wilson wrote:

Paul
Thanks for your help.

C:\Windows\System32\TSWorkspace.dll owned by Trusted Installer but
doesn't have Special permissions and no option to change this although
has Full control/Modify/Read & Execute/Read/Write permissions.

C:\Windows\SysWOW64\TSWorkspace.dll doesn't apparently exist on my
system - problem?

Thanks
aw56001


My information was for a 64 bit install.

I just checked a 32 bit install (in a VM) and

C:\Windows\System32\TSWorkspace.dll

is the only file in use right now. I guess a
32 bit OS doesn't have a SysWOW64 folder ? I
don't see a folder there.

Paul

Paul
Done everything that you suggested but the update fails yet again.
I'm giving up on this but many thanks for your time in assisting me.
Regards
aw56001