Update still failing with 80240020 and 8024000c

Updates download but then do not install, reporting

"Updates were unable to be successfully installed"

and with the following errors in the log file:

ISusInternal API failed CClientCallRecorder::DisconnectCall with error
0x8024000c
WU client failed installing updates with error 0x80240020
WU client calls back to install call
{FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
0x80240020
Operation completed due to earlier error. (hr=80240020)
SusInternal API failed CClientCallRecorder::DisconnectCall with error
0x8024000c

Any ideas?

Thanks!

Did you manage to fix that SID problem you had last month then?

<
http://www.microsoft.com/windowsxp/e...6-276b1638881a
>

Notice that hr = 800704dd was reported then *before* the code
which filtered back to you. If you are still getting this I think it is
what you should be trying to change.


HTH

Robert Aldwinckle
---


"Dan Epstein" <dseps@yahoo.com> wrote in message news:6emtm01er9rlc84ktuvet4egrcocdkh8a2@4ax.com...
> Updates download but then do not install, reporting
>
> "Updates were unable to be successfully installed"
>
> and with the following errors in the log file:
>
> ISusInternal API failed CClientCallRecorder::DisconnectCall with error
> 0x8024000c
> WU client failed installing updates with error 0x80240020
> WU client calls back to install call
> {FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
> 0x80240020
> Operation completed due to earlier error. (hr=80240020)
> SusInternal API failed CClientCallRecorder::DisconnectCall with error
> 0x8024000c
>
> Any ideas?
>
> Thanks!

On Sat, 16 Oct 2004 00:41:33 -0400, "Robert Aldwinckle"
<robald@techemail.com> wrote:

>Did you manage to fix that SID problem you had last month then?

That problem disappeared--no references to 800704dd have been seen since
that one instance. Just the errors referenced in the subject above,
80240020 and 8024000c. I'm happy to reissue my log file, but it hasn't
changed since the last time, and reports only these errors as described:

"Updates were unable to be successfully installed"

with the following errors in the log file:

ISusInternal API failed CClientCallRecorder::DisconnectCall with error
0x8024000c
WU client failed installing updates with error 0x80240020
WU client calls back to install call
{FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
0x80240020
Operation completed due to earlier error. (hr=80240020)
SusInternal API failed CClientCallRecorder::DisconnectCall with error
0x8024000c

I'm not the only one having this problem according to the newsgroup.

Thanks,
Dan

>
><
>http://www.microsoft.com/windowsxp/e...6-276b1638881a
>>
>
>Notice that hr = 800704dd was reported then *before* the code
>which filtered back to you. If you are still getting this I think it is
>what you should be trying to change.
>
>
>HTH
>
>Robert Aldwinckle
>---
>
>
>"Dan Epstein" <dseps@yahoo.com> wrote in message news:6emtm01er9rlc84ktuvet4egrcocdkh8a2@4ax.com...
>> Updates download but then do not install, reporting
>>
>> "Updates were unable to be successfully installed"
>>
>> and with the following errors in the log file:
>>
>> ISusInternal API failed CClientCallRecorder::DisconnectCall with error
>> 0x8024000c
>> WU client failed installing updates with error 0x80240020
>> WU client calls back to install call
>> {FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
>> 0x80240020
>> Operation completed due to earlier error. (hr=80240020)
>> SusInternal API failed CClientCallRecorder::DisconnectCall with error
>> 0x8024000c
>>
>> Any ideas?
>>
>> Thanks!
>

> I'm not the only one having this problem according to the newsgroup.

The only ones that have bothered to submit some log has the 0x800704dd
symptom or a very similar 0x800706dd symptom. (Both refer to
failures in GetUserTokenFromSessionID)

E.g. this search shows nobody posting details:

<
http://groups.google.com/groups?num=...%3Amicrosoft.* >

(Google Groups search for
(80240020 OR 0x80240020) -GetUserTokenFromSessionID group:microsoft.*
)


The other diagnostic I suggested last time was inconclusive because
you cleared your SoftwareDistribution directory. Are there any more
clues in the subdirectory structure yet?


Robert
---


"Dan Epstein" <dseps@yahoo.com> wrote in message
news:pde4n094ndquf4hcl5q160u07kmqjm9fue@4ax.com...
> On Sat, 16 Oct 2004 00:41:33 -0400, "Robert Aldwinckle"
> <robald@techemail.com> wrote:
>
>>Did you manage to fix that SID problem you had last month then?
>
> That problem disappeared--no references to 800704dd have been seen since
> that one instance. Just the errors referenced in the subject above,
> 80240020 and 8024000c. I'm happy to reissue my log file, but it hasn't
> changed since the last time, and reports only these errors as described:
>
> "Updates were unable to be successfully installed"
>
> with the following errors in the log file:
>
> ISusInternal API failed CClientCallRecorder::DisconnectCall with error
> 0x8024000c
> WU client failed installing updates with error 0x80240020
> WU client calls back to install call
> {FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
> 0x80240020
> Operation completed due to earlier error. (hr=80240020)
> SusInternal API failed CClientCallRecorder::DisconnectCall with error
> 0x8024000c
>
> I'm not the only one having this problem according to the newsgroup.
>
> Thanks,
> Dan
>
>>
>><
>>http://www.microsoft.com/windowsxp/e...6-276b1638881a
>>>
>>
>>Notice that hr = 800704dd was reported then *before* the code
>>which filtered back to you. If you are still getting this I think it is
>>what you should be trying to change.
>>
>>
>>HTH
>>
>>Robert Aldwinckle
>>---
>>
>>
>>"Dan Epstein" <dseps@yahoo.com> wrote in message news:6emtm01er9rlc84ktuvet4egrcocdkh8a2@4ax.com...
>>> Updates download but then do not install, reporting
>>>
>>> "Updates were unable to be successfully installed"
>>>
>>> and with the following errors in the log file:
>>>
>>> ISusInternal API failed CClientCallRecorder::DisconnectCall with error
>>> 0x8024000c
>>> WU client failed installing updates with error 0x80240020
>>> WU client calls back to install call
>>> {FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
>>> 0x80240020
>>> Operation completed due to earlier error. (hr=80240020)
>>> SusInternal API failed CClientCallRecorder::DisconnectCall with error
>>> 0x8024000c
>>>
>>> Any ideas?
>>>
>>> Thanks!
>>
>

Robert, The ONLY error reported in the log files is as stated below (ie.
errors 80240020 and 8024000c). There is no indication of another
problem.

The error reported weeks ago that you refer to was most likely related
to my failed attempt to get softwareupdate to work. For example, I
tried logging in as admin, and as another user with admin privileges to
see if the problem was associated with my account (which also has admin
privileges). This didn't work, and the problem still exists.

Others have a similar problem, if not the same. Google the groups and
you'll see this.

Again, the error log is as follows (I'd be happy to print more of the
log if anyone thinks it might help). Any ideas?

"Updates were unable to be successfully installed"

and with the following errors in the log file:

ISusInternal API failed CClientCallRecorder::DisconnectCall with error
0x8024000c
WU client failed installing updates with error 0x80240020
WU client calls back to install call
{FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
0x80240020
Operation completed due to earlier error. (hr=80240020)
SusInternal API failed CClientCallRecorder::DisconnectCall with error
0x8024000c



Dan

On Sun, 17 Oct 2004 09:02:12 -0400, "Robert Aldwinckle"
<robald@techemail.com> wrote:

>> I'm not the only one having this problem according to the newsgroup.
>
>The only ones that have bothered to submit some log has the 0x800704dd
>symptom or a very similar 0x800706dd symptom. (Both refer to
>failures in GetUserTokenFromSessionID)
>
>E.g. this search shows nobody posting details:
>
><
>http://groups.google.com/groups?num=...%3Amicrosoft.* >
>
>(Google Groups search for
> (80240020 OR 0x80240020) -GetUserTokenFromSessionID group:microsoft.*
>)
>
>
>The other diagnostic I suggested last time was inconclusive because
>you cleared your SoftwareDistribution directory. Are there any more
>clues in the subdirectory structure yet?
>
>
>Robert
>---
>
>
>"Dan Epstein" <dseps@yahoo.com> wrote in message
>news:pde4n094ndquf4hcl5q160u07kmqjm9fue@4ax.com...
>> On Sat, 16 Oct 2004 00:41:33 -0400, "Robert Aldwinckle"
>> <robald@techemail.com> wrote:
>>
>>>Did you manage to fix that SID problem you had last month then?
>>
>> That problem disappeared--no references to 800704dd have been seen since
>> that one instance. Just the errors referenced in the subject above,
>> 80240020 and 8024000c. I'm happy to reissue my log file, but it hasn't
>> changed since the last time, and reports only these errors as described:
>>
>> "Updates were unable to be successfully installed"
>>
>> with the following errors in the log file:
>>
>> ISusInternal API failed CClientCallRecorder::DisconnectCall with error
>> 0x8024000c
>> WU client failed installing updates with error 0x80240020
>> WU client calls back to install call
>> {FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
>> 0x80240020
>> Operation completed due to earlier error. (hr=80240020)
>> SusInternal API failed CClientCallRecorder::DisconnectCall with error
>> 0x8024000c
>>
>> I'm not the only one having this problem according to the newsgroup.
>>
>> Thanks,
>> Dan
>>
>>>
>>><
>>>http://www.microsoft.com/windowsxp/e...6-276b1638881a
>>>>
>>>
>>>Notice that hr = 800704dd was reported then *before* the code
>>>which filtered back to you. If you are still getting this I think it is
>>>what you should be trying to change.
>>>
>>>
>>>HTH
>>>
>>>Robert Aldwinckle
>>>---
>>>
>>>
>>>"Dan Epstein" <dseps@yahoo.com> wrote in message news:6emtm01er9rlc84ktuvet4egrcocdkh8a2@4ax.com...
>>>> Updates download but then do not install, reporting
>>>>
>>>> "Updates were unable to be successfully installed"
>>>>
>>>> and with the following errors in the log file:
>>>>
>>>> ISusInternal API failed CClientCallRecorder::DisconnectCall with error
>>>> 0x8024000c
>>>> WU client failed installing updates with error 0x80240020
>>>> WU client calls back to install call
>>>> {FE542022-4DA9-4BF9-A4CE-C376FE27C105} with code Call failed and error
>>>> 0x80240020
>>>> Operation completed due to earlier error. (hr=80240020)
>>>> SusInternal API failed CClientCallRecorder::DisconnectCall with error
>>>> 0x8024000c
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks!
>>>
>>
>

"Dan Epstein" <dseps@yahoo.com> wrote in message
news:95e8n0pleh6uque2b08jblakgfv1qtj1o7@4ax.com
....

Dan,

I wrote:
>>The only ones that have bothered to submit some log has the 0x800704dd
>>symptom or a very similar 0x800706dd symptom. (Both refer to
>>failures in GetUserTokenFromSessionID)
>>
>>E.g. this search shows nobody posting details:
>>
>><
>>http://groups.google.com/groups?num=...%3Amicrosoft.*
>> >
>>
>>(Google Groups search for
>> (80240020 OR 0x80240020) -GetUserTokenFromSessionID group:microsoft.*
>>)

You replied:
> Others have a similar problem, if not the same.
> Google the groups and you'll see this.

Did you look at the above search results?
That is precisely what I did in order to give you that summary.
The above search is inconclusive because by excluding the possibility
that the post referred to GetUserTokenFromSessionID there was no
mention of any other error codes--perhaps because the user didn't
bother to look for them. I find it significant though that if the code does
not necessarily involve problems with GetUserTokenFromSessionID
that I couldn't find at least one poster's log which doesn't contain it.
(BTW my WindowsUpdate.log contains *no* instance of that string
which supports the idea that it only appears in an error situation.)

I would still be interested in knowing what your directory structure
looks like, provided you haven't wiped it again--even more so
if you monitor its use with FileMon as I suggested previously
and can share some insight about how it is being used.


I do not get any ideas from the information that you have provided
so far. There is more to interpreting a log than looking at its error codes
out of context. Once a diagnostic trail is blazed we may be able
to start assuming what error codes by themselves imply and suggest
resolutions based on them. However, the results of the above search
and similar searches seem to indicate that there is no understanding
yet of what is necessary to avoid seeing 80240020.


HTH

Robert
---

Strangely enough, the old error has just returned.

Here's a complete log beginning from a fresh boot
through a failed attempt to install an update
(note the download seems to be successful,
it's just the update that fails):

2004-10-19 21:20:02-0700 336 278 Checking for different Redirector at: http://download.windowsupdate.com/ms...ir/wuredir.cab
2004-10-19 21:20:03-0700 336 278 WinInet: Server file is not newer. Skipping download.
2004-10-19 21:20:03-0700 336 278 Successfully refreshed Redirector cab.
2004-10-19 21:20:03-0700 336 278 WinInet: Server file is not newer. Skipping download.
2004-10-19 21:20:03-0700 336 278 WinInet: Download speed is 1583534 bytes/sec
2004-10-19 21:20:03-0700 336 278 WinInet: Successfully downloaded http://v5.windowsupdate.microsoft.co...en/wusetup.cab to file C:\WINDOWS\SoftwareDistribution\WebSetup\wusetup.cab
2004-10-19 21:20:03-0700 336 278 Loading inf file C:\WINDOWS\SoftwareDistribution\WebSetup\wusetup.inf
2004-10-19 21:20:03-0700 336 278 Section name: cdm: Index: 0
2004-10-19 21:20:03-0700 336 278 Section name: iuengine: Index: 1
2004-10-19 21:20:03-0700 336 278 Section name: wuapi: Index: 2
2004-10-19 21:20:03-0700 336 278 Section name: wuauclt: Index: 3
2004-10-19 21:20:03-0700 336 278 Section name: wuauclt1: Index: 4
2004-10-19 21:20:03-0700 336 278 Section name: wuaucpl: Index: 5
2004-10-19 21:20:03-0700 336 278 Section name: wuaueng_WebSetup: Index: 6
2004-10-19 21:20:03-0700 336 278 Section name: wuaueng1: Index: 7
2004-10-19 21:20:03-0700 336 278 Section name: wuauserv_WebSetup: Index: 8
2004-10-19 21:20:03-0700 336 278 Section name: wucltui: Index: 9
2004-10-19 21:20:03-0700 336 278 Section name: wups: Index: 10
2004-10-19 21:20:03-0700 336 278 Section name: winhttp: Index: 11
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\cdm.dll is: 5,5,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\cdm.dll: Target version: 5.5.3790.2182 Required: 5.5.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\iuengine.dll is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\iuengine.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wuapi.dll is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wuapi.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wuauclt.exe is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wuauclt.exe: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wuauclt1.exe is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wuauclt1.exe: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wuaucpl.cpl is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wuaucpl.cpl: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wuaueng.dll is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wuaueng.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wuaueng1.dll is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wuaueng1.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wucltui.dll is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wucltui.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:03-0700 336 278 Required Version for binary C:\WINDOWS\system32\wups.dll is: 5,4,3790,2182
2004-10-19 21:20:03-0700 336 278 Binary: C:\WINDOWS\system32\wups.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Checking for different Redirector at: http://download.windowsupdate.com/ms...ir/wuredir.cab
2004-10-19 21:20:34-0700 1100 458 WinInet: Server file is not newer. Skipping download.
2004-10-19 21:20:34-0700 1100 458 Successfully refreshed Redirector cab.
2004-10-19 21:20:34-0700 1100 458 WinInet: Server file is not newer. Skipping download.
2004-10-19 21:20:34-0700 1100 458 WinInet: Download speed is 76159049 bytes/sec
2004-10-19 21:20:34-0700 1100 458 WinInet: Successfully downloaded http://v5.windowsupdate.microsoft.co...en/wusetup.cab to file C:\WINDOWS\SoftwareDistribution\WebSetup\wusetup.cab
2004-10-19 21:20:34-0700 1100 458 Loading inf file C:\WINDOWS\SoftwareDistribution\WebSetup\wusetup.inf
2004-10-19 21:20:34-0700 1100 458 Section name: cdm: Index: 0
2004-10-19 21:20:34-0700 1100 458 Section name: iuengine: Index: 1
2004-10-19 21:20:34-0700 1100 458 Section name: wuapi: Index: 2
2004-10-19 21:20:34-0700 1100 458 Section name: wuauclt: Index: 3
2004-10-19 21:20:34-0700 1100 458 Section name: wuauclt1: Index: 4
2004-10-19 21:20:34-0700 1100 458 Section name: wuaucpl: Index: 5
2004-10-19 21:20:34-0700 1100 458 Section name: wuaueng_WebSetup: Index: 6
2004-10-19 21:20:34-0700 1100 458 Section name: wuaueng1: Index: 7
2004-10-19 21:20:34-0700 1100 458 Section name: wuauserv_WebSetup: Index: 8
2004-10-19 21:20:34-0700 1100 458 Section name: wucltui: Index: 9
2004-10-19 21:20:34-0700 1100 458 Section name: wups: Index: 10
2004-10-19 21:20:34-0700 1100 458 Section name: winhttp: Index: 11
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\cdm.dll is: 5,5,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\cdm.dll: Target version: 5.5.3790.2182 Required: 5.5.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\iuengine.dll is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\iuengine.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wuapi.dll is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wuapi.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wuauclt.exe is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wuauclt.exe: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wuauclt1.exe is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wuauclt1.exe: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wuaucpl.cpl is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wuaucpl.cpl: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wuaueng.dll is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wuaueng.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wuaueng1.dll is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wuaueng1.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wucltui.dll is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wucltui.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:34-0700 1100 458 Required Version for binary C:\WINDOWS\system32\wups.dll is: 5,4,3790,2182
2004-10-19 21:20:34-0700 1100 458 Binary: C:\WINDOWS\system32\wups.dll: Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-19 21:20:37-0700 1072 4e4 WU client succeeds CClientCallRecorder::BeginFindUpdates from WindowsUpdate with call id {9359661D-EE32-4838-9930-12375BD8AD1F}
2004-10-19 21:20:37-0700 1072 508 WU client executing call {9359661D-EE32-4838-9930-12375BD8AD1F} of type Search Call
2004-10-19 21:20:37-0700 168 308 Trying to make out of proc datastore active
2004-10-19 21:20:38-0700 168 308 Out of proc datastore is now active
2004-10-19 21:20:38-0700 1072 508 PT: Using serverID {9482F4B4-E343-43B6-B170-9A65BC822C77}
2004-10-19 21:20:38-0700 1072 508 PT: Using server URL https://v5.windowsupdate.microsoft.c...ce/client.asmx
2004-10-19 21:20:38-0700 1072 508 Add header for accept-encoding: xpress succeeded
2004-10-19 21:20:38-0700 1072 508 Failed to find token for SID S-1-5-21-849996735-2676242950-549133041-1007 with hr = 800704dd.
2004-10-19 21:20:38-0700 1072 508 Could not impersonate the user. Failed with 0x800704dd. Will continue in LS context to get proxy settings.
2004-10-19 21:20:52-0700 1072 508 DetectCompressionType returning type 1, hr=0x0
2004-10-19 21:20:52-0700 1072 508 Add header for accept-encoding: xpress succeeded
2004-10-19 21:20:54-0700 1072 508 DetectCompressionType returning type 1, hr=0x0
2004-10-19 21:20:54-0700 1072 508 PT: Using serverID {9482F4B4-E343-43B6-B170-9A65BC822C77}
2004-10-19 21:20:54-0700 1072 508 PT: Using server URL https://v5.windowsupdate.microsoft.c...ce/client.asmx
2004-10-19 21:20:54-0700 1072 508 Add header for accept-encoding: xpress succeeded
2004-10-19 21:20:54-0700 1072 508 DetectCompressionType returning type 1, hr=0x0
2004-10-19 21:20:54-0700 1072 508 WU client add update {76BAACDD-634F-487D-AC52-33CD061B49E7}.100 to search result
2004-10-19 21:20:54-0700 1072 508 WU client add update {B4B9471C-1A5E-4D9C-94EF-84B00592946A}.100 to search result
2004-10-19 21:20:54-0700 1072 508 WU client add update {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44}.100 to search result
2004-10-19 21:20:54-0700 1072 508 DeviceStatus: 0x180200a, DeviceProblemNumber: 00000000
2004-10-19 21:20:54-0700 1072 508 WU client add update {467ABF7F-A427-4CBF-B941-EC5C1E0608C3}.100 to search result
2004-10-19 21:20:54-0700 1072 508 WU client found 4 updates and 10 categories in search
2004-10-19 21:20:54-0700 1072 508 WU client finished Searching for update
2004-10-19 21:20:54-0700 1072 508 WU client calls back to search call WindowsUpdate with code Call complete and error 0
2004-10-19 21:20:54-0700 1072 508 WU client completed and deleted call {9359661D-EE32-4838-9930-12375BD8AD1F}
2004-10-19 21:20:59-0700 1072 508 REPORT EVENT: {01D4363B-0065-4F74-B7DE-8D912093A785} 302 2004-10-19 21:20:54-0700 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 WindowsUpdate Success Software Synchronization Agent has finished detecting items.
2004-10-19 21:21:12-0700 1072 4b8 WU client persisted 1 download calls
2004-10-19 21:21:12-0700 1072 508 WU client executing call {1FE62C24-3956-4E68-BC69-F9742CA18866} of type Download Call
2004-10-19 21:21:12-0700 1072 4b8 WU client succeeds CClientCallRecorder::BeginDownloadUpdates from WindowsUpdate with call id {1FE62C24-3956-4E68-BC69-F9742CA18866}
2004-10-19 21:21:12-0700 1072 508 Dumping out update 1 of 1
2004-10-19 21:21:12-0700 1072 508 title = Update for Windows XP HighMAT Support in CD Writing Wizard (KB831240)
2004-10-19 21:21:12-0700 1072 508 dumping updateId {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44}.100 bundling 1 updates
2004-10-19 21:21:12-0700 1072 508 bundled update No. 1 is {7903EC9D-E130-4A23-B4E1-96580E3818F0}.100
2004-10-19 21:21:12-0700 1072 508 Failed to find token for SID S-1-5-21-849996735-2676242950-549133041-1007 with hr = 800704dd.
2004-10-19 21:21:12-0700 1072 508 Could not impersonate the user. Failed with 0x800704dd. Will continue in LS context to get proxy settings.
2004-10-19 21:21:14-0700 1072 508 Downloading from http://www.download.windowsupdate.co...d9b236ec85.exe to C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\566ec47adc9d26a271c24f31c063cd84\3e7fd44a1dad696f72269378987ce5aecfc4a276 (full file).
2004-10-19 21:21:14-0700 1072 604 WU client calls back to download call {1FE62C24-3956-4E68-BC69-F9742CA18866} with code Call progress and error 0
2004-10-19 21:21:23-0700 1072 41c Download job for update {7903EC9D-E130-4A23-B4E1-96580E3818F0}, revision 100 completed successfully.
2004-10-19 21:21:23-0700 1072 41c Successfully downloaded file from http://www.download.windowsupdate.co...d9b236ec85.exe to C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\566ec47adc9d26a271c24f31c063cd84\3e7fd44a1dad696f72269378987ce5aecfc4a276.
2004-10-19 21:21:23-0700 1072 41c WU client persisted 1 download calls
2004-10-19 21:21:23-0700 1072 41c WU client persisted 1 download calls
2004-10-19 21:21:23-0700 1072 508 WU client calls back to download call {1FE62C24-3956-4E68-BC69-F9742CA18866} with code Call complete and error 0
2004-10-19 21:21:23-0700 1072 508 WU client completed and deleted call {1FE62C24-3956-4E68-BC69-F9742CA18866}
2004-10-19 21:21:23-0700 1072 508 WU client persisted 0 download calls
2004-10-19 21:21:23-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
2004-10-19 21:21:23-0700 1100 458 ISusInternal::DisconnectCall failed, hr=8024000C
2004-10-19 21:21:23-0700 1072 4e4 WU client succeeds CClientCallRecorder::BeginInstallUpdates from WindowsUpdate with call id {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4}
2004-10-19 21:21:23-0700 1072 508 WU client executing call {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4} of type Install call
2004-10-19 21:21:23-0700 1072 508 validate updates before Install
2004-10-19 21:21:24-0700 1072 508 prune update list before Install
2004-10-19 21:21:24-0700 1072 508 GetUserTokenFromSessionId failed with hr 0x800704dd
2004-10-19 21:21:24-0700 1072 508 WU client failed installing updates with error 0x80240020
2004-10-19 21:21:24-0700 1072 508 WU client calls back to install call {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4} with code Call failed and error 0x80240020
2004-10-19 21:21:24-0700 1072 508 WU client completed and deleted call {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4}
2004-10-19 21:21:24-0700 1100 458 Operation completed due to earlier error. (hr=80240020)
2004-10-19 21:21:24-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
2004-10-19 21:21:24-0700 1100 458 ISusInternal::DisconnectCall failed, hr=8024000C
2004-10-19 21:21:28-0700 1072 508 REPORT EVENT: {222E0E07-90DE-4061-94EB-0C332F07F27C} 303 2004-10-19 21:21:23-0700 1 162 101 {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44} 100 0 WindowsUpdate Success Content Download Download succeeded.
2004-10-19 21:21:28-0700 1072 508 REPORT EVENT: {60897902-64F0-4F22-90F7-A4869D0C149C} 304 2004-10-19 21:21:23-0700 1 162 101 {7903EC9D-E130-4A23-B4E1-96580E3818F0} 100 0 WindowsUpdate Success Content Download Download succeeded.
2004-10-19 21:21:30-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
2004-10-19 21:21:30-0700 1100 458 ISusInternal::DisconnectCall failed, hr=8024000C


On Tue, 19 Oct 2004 01:19:49 -0400, "Robert Aldwinckle" <robald@techemail.com> wrote:

>"Dan Epstein" <dseps@yahoo.com> wrote in message
>news:95e8n0pleh6uque2b08jblakgfv1qtj1o7@4ax.com
>...
>
>Dan,
>
>I wrote:
>>>The only ones that have bothered to submit some log has the 0x800704dd
>>>symptom or a very similar 0x800706dd symptom. (Both refer to
>>>failures in GetUserTokenFromSessionID)
>>>
>>>E.g. this search shows nobody posting details:
>>>
>>><
>>>http://groups.google.com/groups?num=...%3Amicrosoft.*
>>> >
>>>
>>>(Google Groups search for
>>> (80240020 OR 0x80240020) -GetUserTokenFromSessionID group:microsoft.*
>>>)
>
>You replied:
>> Others have a similar problem, if not the same.
>> Google the groups and you'll see this.
>
>Did you look at the above search results?
>That is precisely what I did in order to give you that summary.
>The above search is inconclusive because by excluding the possibility
>that the post referred to GetUserTokenFromSessionID there was no
>mention of any other error codes--perhaps because the user didn't
>bother to look for them. I find it significant though that if the code does
>not necessarily involve problems with GetUserTokenFromSessionID
>that I couldn't find at least one poster's log which doesn't contain it.
>(BTW my WindowsUpdate.log contains *no* instance of that string
>which supports the idea that it only appears in an error situation.)
>
>I would still be interested in knowing what your directory structure
>looks like, provided you haven't wiped it again--even more so
>if you monitor its use with FileMon as I suggested previously
>and can share some insight about how it is being used.
>
>
>I do not get any ideas from the information that you have provided
>so far. There is more to interpreting a log than looking at its error codes
>out of context. Once a diagnostic trail is blazed we may be able
>to start assuming what error codes by themselves imply and suggest
>resolutions based on them. However, the results of the above search
>and similar searches seem to indicate that there is no understanding
>yet of what is necessary to avoid seeing 80240020.
>
>
>HTH
>
>Robert
>---
>

"Dan Epstein" <dseps@yahoo.com> wrote in message
news:gbqbn09vafjni63dklcaosboduarr5g00b@4ax.com...
> Strangely enough, the old error has just returned.
>
> Here's a complete log beginning from a fresh boot
> through a failed attempt to install an update
> (note the download seems to be successful,
> it's just the update that fails):

I'm not actually convinced of that which is why I would still like to see
how that directory is being used. There is still indication that the SID
may be used in a subdirectory level. However, now I have my log and
subdirecory to compare with and I see no evidence of SID in either.
So it seems that, if the SID is used in the directory structure, it is used
transiently. Therefore I still think it would be worthwhile to at least list
the changed files and, as I mentioned, it would be even more informative
to know as well how the whole directory was accessed, e.g. using
FileMon to monitor it.

Also I would like to be clearer about which processes are doing the
reporting because I think that ultimately it is going to be their accounts
and the authority that they have which is going to be a determining
factor for what is causing this error condition.

E.g. in this log we have 336, 1100, 1072, 168, all reporting their
respective activity but which are which? FileMon would help straighten
out that question too.

In any case notice that the first problem occurs with 1072.
So if nothing else let's try to identify it. E.g. is it wuauclt or BITS?
Unfortunately both are transient processes so you would have to be
watching Task Manager and using tasklist (in a command window)
to know that. E.g. if a new svchost.exe pops up check for what
it is doing by entering:
tasklist /svc /fi "Imagename eq svchost.exe"

I have speculated that perhaps we could start BITS manually
and thereby avoid any confusion at least about that process.
You could try that too if you like.

I'm not sure what all the implications of it might be but a way
to ensure you knew which account was involved with wuauclt
would probably be to start it yourself from the Run... dialog:
wuauclt /detectnow

Notice that we still have the possibility of that interesting switch
between SIDs. It starts of with
SID S-1-5-21-849996735-2676242950-549133041-1007
and then (I'm guessing) switches to
C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\566ec47adc9d26a271c24f31c063cd84\3e7fd44a1dad696f72269378987ce5aecfc4a276 (full
file).

Have you managed to find out anything signficant about
those two accounts and their respective authorizations?
Remember, you used the getsid tool to find out which
was which.


Rather than cite the whole log I'll just quote the start
and end of the parts that I think may be significant.
Since I don't know what is really going on I'll just
highlight bits by their timestamp.

First messages from 1072 and 168.
up to first indication of trouble with SID:

> 2004-10-19 21:20:37-0700 1072 4e4 WU client succeeds CClientCallRecorder::BeginFindUpdates from WindowsUpdate with call id
> {9359661D-EE32-4838-9930-12375BD8AD1F}
> 2004-10-19 21:20:37-0700 1072 508 WU client executing call {9359661D-EE32-4838-9930-12375BD8AD1F} of type Search Call
> 2004-10-19 21:20:37-0700 168 308 Trying to make out of proc datastore active
> 2004-10-19 21:20:38-0700 168 308 Out of proc datastore is now active
> 2004-10-19 21:20:38-0700 1072 508 PT: Using serverID {9482F4B4-E343-43B6-B170-9A65BC822C77}
> 2004-10-19 21:20:38-0700 1072 508 PT: Using server URL https://v5.windowsupdate.microsoft.c...ce/client.asmx
> 2004-10-19 21:20:38-0700 1072 508 Add header for accept-encoding: xpress succeeded
> 2004-10-19 21:20:38-0700 1072 508 Failed to find token for SID S-1-5-21-849996735-2676242950-549133041-1007 with hr = 800704dd.
> 2004-10-19 21:20:38-0700 1072 508 Could not impersonate the user. Failed with 0x800704dd. Will continue in LS context to get proxy
> settings.


Start of recovery context for downloading what to where?
Why did it take 14 seconds for this to get started/ended?
Was anything happening in any of those tasks we noted?
Timestamps from dir/s/od | findstr /i "directory 2004-10-19"
or log entries from FileMon for the intervening period
might fill in some of these blanks.


> 2004-10-19 21:20:52-0700 1072 508 DetectCompressionType returning type 1, hr=0x0
> 2004-10-19 21:20:52-0700 1072 508 Add header for accept-encoding: xpress succeeded
> 2004-10-19 21:20:54-0700 1072 508 DetectCompressionType returning type 1, hr=0x0
> 2004-10-19 21:20:54-0700 1072 508 PT: Using serverID {9482F4B4-E343-43B6-B170-9A65BC822C77}
> 2004-10-19 21:20:54-0700 1072 508 PT: Using server URL https://v5.windowsupdate.microsoft.c...ce/client.asmx
> 2004-10-19 21:20:54-0700 1072 508 Add header for accept-encoding: xpress succeeded
> 2004-10-19 21:20:54-0700 1072 508 DetectCompressionType returning type 1, hr=0x0
> 2004-10-19 21:20:54-0700 1072 508 WU client add update {76BAACDD-634F-487D-AC52-33CD061B49E7}.100 to search result
> 2004-10-19 21:20:54-0700 1072 508 WU client add update {B4B9471C-1A5E-4D9C-94EF-84B00592946A}.100 to search result
> 2004-10-19 21:20:54-0700 1072 508 WU client add update {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44}.100 to search result
> 2004-10-19 21:20:54-0700 1072 508 DeviceStatus: 0x180200a, DeviceProblemNumber: 00000000
> 2004-10-19 21:20:54-0700 1072 508 WU client add update {467ABF7F-A427-4CBF-B941-EC5C1E0608C3}.100 to search result
> 2004-10-19 21:20:54-0700 1072 508 WU client found 4 updates and 10 categories in search
> 2004-10-19 21:20:54-0700 1072 508 WU client finished Searching for update
> 2004-10-19 21:20:54-0700 1072 508 WU client calls back to search call WindowsUpdate with code Call complete and error 0
> 2004-10-19 21:20:54-0700 1072 508 WU client completed and deleted call {9359661D-EE32-4838-9930-12375BD8AD1F}

What was happening here?
Why would it take 5 seconds to report that it was done?
(Another example where having reference to the files being accessed
could go a long way to understanding what the log entries imply.)


> 2004-10-19 21:20:59-0700 1072 508 REPORT EVENT: {01D4363B-0065-4F74-B7DE-8D912093A785} 302 2004-10-19 21:20:54-0700 1 147 101
> {00000000-0000-0000-0000-000000000000} 0 0 WindowsUpdate Success Software Synchronization Agent has finished detecting items.


Another big pause (almost 30 seconds)
leads up to another mix up with the SIDs.


> 2004-10-19 21:21:12-0700 1072 4b8 WU client persisted 1 download calls
> 2004-10-19 21:21:12-0700 1072 508 WU client executing call {1FE62C24-3956-4E68-BC69-F9742CA18866} of type Download Call
> 2004-10-19 21:21:12-0700 1072 4b8 WU client succeeds CClientCallRecorder::BeginDownloadUpdates from WindowsUpdate with call id
> {1FE62C24-3956-4E68-BC69-F9742CA18866}
> 2004-10-19 21:21:12-0700 1072 508 Dumping out update 1 of 1
> 2004-10-19 21:21:12-0700 1072 508 title = Update for Windows XP HighMAT Support in CD Writing Wizard (KB831240)
> 2004-10-19 21:21:12-0700 1072 508 dumping updateId {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44}.100 bundling 1 updates
> 2004-10-19 21:21:12-0700 1072 508 bundled update No. 1 is {7903EC9D-E130-4A23-B4E1-96580E3818F0}.100
> 2004-10-19 21:21:12-0700 1072 508 Failed to find token for SID S-1-5-21-849996735-2676242950-549133041-1007 with hr = 800704dd.
> 2004-10-19 21:21:12-0700 1072 508 Could not impersonate the user. Failed with 0x800704dd. Will continue in LS context to get proxy
> settings.
> 2004-10-19 21:21:14-0700 1072 508 Downloading from
> http://www.download.windowsupdate.co...d9b236ec85.exe to
> C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\566ec47adc9d26a271c24f31c063cd84\3e7fd44a1dad696f72269378987ce5aecfc4a276 (full
> file).

Comparing with mine, I do get the same S-1-5-18 here, which according to
getsid is System (not "Local System" and not LocalSystem, contradicting some
documentation I found.) So now I'm less convinced of my conjecture about
SID being a factor but I still think that watching FileMon to see what really
happens is going to be the only practical approach to going further.

The rest of the log just seems to convert this specific error into more
general reporting codes:


<extract>
> 2004-10-19 21:21:24-0700 1072 508 GetUserTokenFromSessionId failed with hr 0x800704dd
> 2004-10-19 21:21:24-0700 1072 508 WU client failed installing updates with error 0x80240020
....
> 2004-10-19 21:21:24-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
</extract>


I can't understand why 162 (whatever it is) can be claiming the download
succeeded and am even more mystified why 1072 (which was reporting
all those errors) echoes that success to the summary log. Again, I think
looking at the actual files that were accessed, especially the ones which
were created would go a long way to clarifying what this portion of the log
should really be trying to tell us.

<extract>
2004-10-19 21:21:23-0700 1 162 101 {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44} 100 0 WindowsUpdate Success Content Download Download
succeeded.
> 2004-10-19 21:21:28-0700 1072 508 REPORT EVENT: {60897902-64F0-4F22-90F7-A4869D0C149C} 304 2004-10-19 21:21:23-0700 1 162 101
> {7903EC9D-E130-4A23-B4E1-96580E3818F0} 100 0 WindowsUpdate Success Content Download Download succeeded.
</extract>


Remaining log (where the above extracts came from) is left here
for the convenience of those who may wish to see the full context
without switching back to a previous message.


BTW please take note of echsb report about his problems
with the System account yesterday. That is exactly the sort
of thing that I am thinking might explain these symptoms.
In your case the System account (SID S-1-5-18) would be
the account used by the recovery attempt for the initial account
(SID S-1-5-21-849996735-2676242950-549133041-1007)
which apparently had insufficient authority or some other problem.

news:940FCF9F-A665-45C1-9AE9-C894872030ED@microsoft.com
From: "=?Utf-8?B?ZWNoc2I=?=" <echsb@discussions.microsoft.com>
Subject: Solution for error: 0x80248011
Date: Thu, 21 Oct 2004 11:25:03 -0700


HTH

Robert
---


> 2004-10-19 21:21:14-0700 1072 604 WU client calls back to download call {1FE62C24-3956-4E68-BC69-F9742CA18866} with code Call
> progress and error 0
> 2004-10-19 21:21:23-0700 1072 41c Download job for update {7903EC9D-E130-4A23-B4E1-96580E3818F0}, revision 100 completed
> successfully.
> 2004-10-19 21:21:23-0700 1072 41c Successfully downloaded file from
> http://www.download.windowsupdate.co...d9b236ec85.exe to
> C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\566ec47adc9d26a271c24f31c063cd84\3e7fd44a1dad696f72269378987ce5aecfc4a276.
> 2004-10-19 21:21:23-0700 1072 41c WU client persisted 1 download calls
> 2004-10-19 21:21:23-0700 1072 41c WU client persisted 1 download calls
> 2004-10-19 21:21:23-0700 1072 508 WU client calls back to download call {1FE62C24-3956-4E68-BC69-F9742CA18866} with code Call
> complete and error 0
> 2004-10-19 21:21:23-0700 1072 508 WU client completed and deleted call {1FE62C24-3956-4E68-BC69-F9742CA18866}
> 2004-10-19 21:21:23-0700 1072 508 WU client persisted 0 download calls
> 2004-10-19 21:21:23-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
> 2004-10-19 21:21:23-0700 1100 458 ISusInternal::DisconnectCall failed, hr=8024000C
> 2004-10-19 21:21:23-0700 1072 4e4 WU client succeeds CClientCallRecorder::BeginInstallUpdates from WindowsUpdate with call id
> {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4}
> 2004-10-19 21:21:23-0700 1072 508 WU client executing call {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4} of type Install call
> 2004-10-19 21:21:23-0700 1072 508 validate updates before Install
> 2004-10-19 21:21:24-0700 1072 508 prune update list before Install
> 2004-10-19 21:21:24-0700 1072 508 GetUserTokenFromSessionId failed with hr 0x800704dd
> 2004-10-19 21:21:24-0700 1072 508 WU client failed installing updates with error 0x80240020
> 2004-10-19 21:21:24-0700 1072 508 WU client calls back to install call {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4} with code Call
> failed and error 0x80240020
> 2004-10-19 21:21:24-0700 1072 508 WU client completed and deleted call {AE2F7943-F5A1-4078-AFE5-2C13BEC171B4}
> 2004-10-19 21:21:24-0700 1100 458 Operation completed due to earlier error. (hr=80240020)
> 2004-10-19 21:21:24-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
> 2004-10-19 21:21:24-0700 1100 458 ISusInternal::DisconnectCall failed, hr=8024000C
> 2004-10-19 21:21:28-0700 1072 508 REPORT EVENT: {222E0E07-90DE-4061-94EB-0C332F07F27C} 303 2004-10-19 21:21:23-0700 1 162 101
> {AC94DB3B-E1A8-4E92-9FD0-E86F355E6A44} 100 0 WindowsUpdate Success Content Download Download succeeded.
> 2004-10-19 21:21:28-0700 1072 508 REPORT EVENT: {60897902-64F0-4F22-90F7-A4869D0C149C} 304 2004-10-19 21:21:23-0700 1 162 101
> {7903EC9D-E130-4A23-B4E1-96580E3818F0} 100 0 WindowsUpdate Success Content Download Download succeeded.
> 2004-10-19 21:21:30-0700 1072 4b8 ISusInternal API failed CClientCallRecorder::DisconnectCall with error 0x8024000c
> 2004-10-19 21:21:30-0700 1100 458 ISusInternal::DisconnectCall failed, hr=8024000C

Hi Robert and Dan.

I'm getting the same errors: GetUserTokenFromSessionId failed with hr
0x800704dd followed by 0x80240020 and then 8024000C.

Maybe having another installation (mine) where this happens can help
understanding what's going on.

Background: after SP2 install, all updates fails. I can update only manually
downloading patches and installing them. When I try to update from
WindowsUpdate I get the "Updates were unable to be successfully installed"
but no error appears in the Installation history (there's nothing there
besides updates before SP2 install and updates installed manually)

This is my dir structure. Note that I've never messed (yet) with my
"softwaredistribution" dir structure.

C:\WINDOWS\SoftwareDistribution
+--DataStore
| \--Logs
+--Download
| \--a078c16663ac0afc501578e96a4586a9
| +--asms
| | +--10
| | | +--msft
| | | | \--windows
| | | | \--gdiplus
| | | \--policy
| | | \--msft
| | | \--windows
| | | \--gdiplus
| | +--51
| | | +--msft
| | | | \--windows
| | | | \--system
| | | | \--default
| | | \--policy
| | | \--msft
| | | \--windows
| | | \--system
| | | \--default
| | +--52
| | | +--msft
| | | | \--windows
| | | | \--net
| | | | +--dxmrtp
| | | | +--rtcdll
| | | | \--rtcres
| | | \--policy
| | | \--msft
| | | \--windows
| | | \--networking
| | | +--dxmrtp
| | | \--rtcdll
| | +--60
| | | +--msft
| | | | \--windows
| | | | \--common
| | | | \--controls
| | | \--policy
| | | \--60
| | | \--comctl
| | \--70
| | +--msft
| | | \--windows
| | | \--mswincrt
| | \--policy
| | \--msft
| | \--mswincrt
| +--backup
| | +--asms
| | | +--10
| | | | \--msft
| | | | \--windows
| | | +--52
| | | | \--msft
| | | | \--windows
| | | | \--net
| | | +--60
| | | | \--msft
| | | | \--windows
| | | | \--common
| | | \--70
| | | \--msft
| | | \--windows
| | \--root
| | \--cmpnents
| | \--mediactr
| +--ip
| +--lang
| +--new
| +--root
| | \--cmpnents
| | \--mediactr
| | \--i386
| \--update
+--EventCache
+--SelfUpdate
+--WebSetup
\--WuRedir
\--9482F4B4-E343-43B6-B170-9A65BC822C77

And this is the tail of the log

2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\cdm.dll is: 5,5,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\cdm.dll:
Target version: 5.5.3790.2182 Required: 5.5.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\iuengine.dll is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\iuengine.dll:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wuapi.dll is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wuapi.dll:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wuauclt.exe is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wuauclt.exe:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wuauclt1.exe is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wuauclt1.exe:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wuaucpl.cpl is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wuaucpl.cpl:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wuaueng.dll is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wuaueng.dll:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wuaueng1.dll is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wuaueng1.dll:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wucltui.dll is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wucltui.dll:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:52+0200 2352 d5c Required Version for binary
C:\WINDOWS\system32\wups.dll is: 5,4,3790,2182
2004-10-23 07:12:52+0200 2352 d5c Binary: C:\WINDOWS\system32\wups.dll:
Target version: 5.4.3790.2182 Required: 5.4.3790.2182
2004-10-23 07:12:56+0200 1512 204 WU client succeeds
CClientCallRecorder::BeginFindUpdates from WindowsUpdate with call id
{067C5E74-6F75-4B97-B369-5BDB27F603FE}
2004-10-23 07:12:56+0200 1512 118 WU client executing call
{067C5E74-6F75-4B97-B369-5BDB27F603FE} of type Search Call
2004-10-23 07:12:56+0200 1512 118 PT: Using serverID
{9482F4B4-E343-43B6-B170-9A65BC822C77}
2004-10-23 07:12:56+0200 1512 118 PT: Using server URL
https://v5.windowsupdate.microsoft.c...ce/client.asmx
2004-10-23 07:12:57+0200 1512 118 Add header for accept-encoding: xpress
succeeded
2004-10-23 07:12:59+0200 1512 118 DetectCompressionType returning type 1,
hr=0x0
2004-10-23 07:12:59+0200 1512 118 Add header for accept-encoding: xpress
succeeded
2004-10-23 07:13:02+0200 1512 118 DetectCompressionType returning type 1,
hr=0x0
2004-10-23 07:13:02+0200 1512 118 PT: Using serverID
{9482F4B4-E343-43B6-B170-9A65BC822C77}
2004-10-23 07:13:02+0200 1512 118 PT: Using server URL
https://v5.windowsupdate.microsoft.c...ce/client.asmx
2004-10-23 07:13:02+0200 1512 118 Add header for accept-encoding: xpress
succeeded
2004-10-23 07:13:03+0200 1512 118 DetectCompressionType returning type 1,
hr=0x0
2004-10-23 07:13:03+0200 1512 118 DeviceStatus: 0x180200a,
DeviceProblemNumber: 00000000
2004-10-23 07:13:03+0200 1512 118 WU client add update
{377E5A6E-C860-43E9-9907-D0792470C5F3}.100 to search result
2004-10-23 07:13:03+0200 1512 118 WU client add update
{8992C33E-AB76-4DFB-9AF0-0FD471338F32}.100 to search result
2004-10-23 07:13:03+0200 1512 118 WU client add update
{879FFB13-1610-4F09-BF93-A7C6A495175E}.106 to search result
2004-10-23 07:13:03+0200 1512 118 WU client found 3 updates and 10
categories in search
2004-10-23 07:13:03+0200 1512 118 WU client finished Searching for update
2004-10-23 07:13:03+0200 1512 118 WU client calls back to search call
WindowsUpdate with code Call complete and error 0
2004-10-23 07:13:03+0200 1512 118 WU client completed and deleted call
{067C5E74-6F75-4B97-B369-5BDB27F603FE}
2004-10-23 07:13:08+0200 1512 118 REPORT EVENT:
{CF33862C-46E0-4BBC-B278-EB5B3A88745C} 262 2004-10-23
07:13:03+0200 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 WindowsUpdate Success Software Synchronization Agent has finished detecting items.
2004-10-23 07:13:11+0200 1512 7f0 WU client succeeds
CClientCallRecorder::BeginInstallUpdates from WindowsUpdate with call id
{C6C443B7-7BD2-43C0-B0B5-551214439A58}
2004-10-23 07:13:11+0200 1512 118 WU client executing call
{C6C443B7-7BD2-43C0-B0B5-551214439A58} of type Install call
2004-10-23 07:13:11+0200 1512 118 validate updates before Install
2004-10-23 07:13:12+0200 1512 118 prune update list before Install
2004-10-23 07:13:12+0200 1512 118 GetUserTokenFromSessionId failed with hr
0x800704dd
2004-10-23 07:13:12+0200 1512 118 WU client failed installing updates with
error 0x80240020
2004-10-23 07:13:12+0200 1512 118 WU client calls back to install call
{C6C443B7-7BD2-43C0-B0B5-551214439A58} with code Call failed and error
0x80240020
2004-10-23 07:13:12+0200 1512 118 WU client completed and deleted call
{C6C443B7-7BD2-43C0-B0B5-551214439A58}
2004-10-23 07:13:12+0200 2352 d5c Operation completed due to earlier error.
(hr=80240020)
2004-10-23 07:13:12+0200 1512 204 ISusInternal API failed
CClientCallRecorder::DisconnectCall with error 0x8024000c
2004-10-23 07:13:12+0200 2352 d5c ISusInternal::DisconnectCall failed,
hr=8024000C


Livio

Hi Robert and Dan,

I have notice that I've another issue since I installed SP2 and it might be
related to this one.
Can you tell me if you have the same issue too?

Basically the Scheduled Tasks doesn't work anymore.

If I create a scheduled task with option "Run only if logged on" enabled,
then the scheduler doesn't even try to run the task as if I'm not logged on
(but I AM logged on)
If I create a task, say "calc.exe", with option "Run only if logged on"
disabled, than the task is properly run, but I don't see the calculator
window. It's like the task is run on a different session, which makes me
think that the task scheduler belives that the current session is of a
different user (actually I scheduled the task with the same user that I'm
currently logged on as).

Regards
Livio

Hi Robert and Dan,

I have notice that I've another issue since I installed SP2 and it might be
related to this one.
Can you tell me if you have the same issue too?

Basically the Scheduled Tasks doesn't work anymore.

If I create a scheduled task with option "Run only if logged on" enabled,
then the scheduler doesn't even try to run the task as if I'm not logged on
(but I AM logged on)
If I create a task, say "calc.exe", with option "Run only if logged on"
disabled, than the task is properly run, but I don't see the calculator
window. It's like the task is run on a different session, which makes me
think that the task scheduler belives that the current session is of a
different user (actually I scheduled the task with the same user that I'm
currently logged on as).

Regards
Livio

"lbertacco" <lbertacco@discussions.microsoft.com> wrote in message
news:A75F8585-D702-4894-97B9-83CD6E5EF7CC@microsoft.com...
> Hi Robert and Dan.
>
> I'm getting the same errors: GetUserTokenFromSessionId failed with hr
> 0x800704dd followed by 0x80240020 and then 8024000C.
>
> Maybe having another installation (mine) where this happens can help
> understanding what's going on.
>
> Background: after SP2 install, all updates fails. I can update only manually
> downloading patches and installing them. When I try to update from
> WindowsUpdate I get the "Updates were unable to be successfully installed"
> but no error appears in the Installation history (there's nothing there
> besides updates before SP2 install and updates installed manually)
>
> This is my dir structure. Note that I've never messed (yet) with my
> "softwaredistribution" dir structure.

Livio,

This is not at all what I was expecting to see.
Certainly not what I have.

I'm still not exactly clear what I have but it looks as if
my Download subdirectory contains only files with names
each having 40 hex characters and no extensions.
This is *after* the patches have been installed.
What is really interesting is that it looks as if (e.g. after dragging
them to a Notepad window) some of them are actually executables
and that is where some of the messages (or at least the information
for them) that we see in the log originate.

I'm now concluding that the some of my ideas about what might be
happening in the subdirectory may be being misled by fake pathnames
in the messages which are probably being constructed to show more
information than the real pathnames would. I am really regretting have
lost my FileMon trace which would have resolved all such uncertainty
definitively.


What is your objective? To try to understand better how it is supposed
to work or just to install some patches and get on with other things?
If it is only the latter I would just use WU as a guide for which patches
to download and install manually. Or, if you would like to try to get WU
working but don't care why see if Torgeir's tip about proxycfg helps
you out.


Good luck

Robert
---

....

Hi Robert

> I'm still not exactly clear what I have but it looks as if
> my Download subdirectory contains only files with names
> each having 40 hex characters and no extensions.

Well, my download subdir contains those too. The tree I've shown is that of
the SoftwareDistribution dir. My download subdir however contains, besides
hex number named files, another (still hex number named) subdir with lots of
other file/subdirs. Maybe this is a consequence of some old and big update ?
(sp1?)

> What is your objective?

I'd like to make this thing working again, but in a rational way. Not just
reinstalling Windows or doing some other nonsense which might for some
unknown reason solve this problem (and possible cause many others)

> Or, if you would like to try to get WU
> working but don't care why see if Torgeir's tip about proxycfg helps
> you out.
No proxy configured. And BTW my WU download updates allright, just can't
install them.

See also my post of yesterday about scheduled tasks.

Livio

"lbertacco" <lbertacco@discussions.microsoft.com> wrote in message
news:CFEB3D3E-A837-4994-A6EF-A48C698060FE@microsoft.com...
> Hi Robert
>
>> I'm still not exactly clear what I have but it looks as if
>> my Download subdirectory contains only files with names
>> each having 40 hex characters and no extensions.
>
> Well, my download subdir contains those too. The tree I've shown is that of
> the SoftwareDistribution dir. My download subdir however contains, besides
> hex number named files, another (still hex number named) subdir with lots of
> other file/subdirs. Maybe this is a consequence of some old and big update ?
> (sp1?)

Oh. Perhaps. I was thinking it would represent a failed install,
e.g. thinking that running one of those executable 40-hexdigit
files would create a bunch of work folders to expand their contents
into and from there they would be installed into the appropriate existing
folders. You could actually check on that by looking at the create date
and timestamp of that mystery subdirectory. (E.g. dir/tc )

BTW What is the history of your SoftwareDistribution folder?
In my case it was created when I installed XPsp2RC1
and then I didn't realize that it would be best to clear it
after upgrading to XPsp2RTM (by CD). I eventually cleared it
as I have documented elsewhere in order to verify that AU was
working properly but there just weren't any updates being served to it.
It would have been interesting I think to see if AU would have
worked without that intervention; however, the log was definitely
cleaner (fewer error messages) afterwards.


I imagine also that if your problem is simply a question of the installing
account and the authority it has you might even have some success
simply running one of those "executables" under your own account
(assuming it has sufficient authority). Note that this is highly speculative
and again (kicking myself) would have been made much clearer if I hadn't lost
that FileMon trace I had. I think I am just going to have to wait for the
next patch to be downloaded as my next opportunity to study how it
actually works. Who knows? By the time that happens we may actually
have some better official documentation which will make all this reverse
engineering unnecessary.


>
>> What is your objective?
>
> I'd like to make this thing working again, but in a rational way. Not just
> reinstalling Windows or doing some other nonsense which might for some
> unknown reason solve this problem (and possible cause many others)
>
>> Or, if you would like to try to get WU
>> working but don't care why see if Torgeir's tip about proxycfg helps
>> you out.
> No proxy configured. And BTW my WU download updates allright, just can't
> install them.

That's why I referred you to Torgeir's posts. A recent explanation
he gave about it made it sound as if it could have wider applicability
than the name of the command suggests. The post I am thinking
of specifically definitely made mention that different accounts and
different account authority could explain why some phases of the
update could occur but not others. (It may only have been the
checking phase which could mean that the accounts used by different
programs were involved, e.g. the account used with wuauclt.exe
versus the account used with Background Intelligent Transfer Service.)
So in your case there would be a third-phase (installing) with its own
account authority questions. Hmm... what if those "executables"
we found really are run? Do you have any software or other restrictions
which might inhibit that from occurring? (e.g. trying to execute something
which doesn't have a clearly identifiable extension) Perhaps a related
question: have you checked out the sc sdshow and sc sdset commands
which others have been advised to use for their symptoms?
(e.g. maybe there is something embedded in all that cryptic stuff
which accidently implements such a restriction and prevents
the service from executing those files.) Etc.


>
> See also my post of yesterday about scheduled tasks.

I don't use the scheduler feature.
Discussing it would be off-topic for this newsgroup
so you would do better to try looking in a newsgroup
for your OS or somewhere there would be admin types
who should be more knowledgeable about automation
techniques.


Good luck

Robert
---

Hi Livio,

Just catching up with the group.

I don't use task scheduler and it's a good thing: when I tried your
experiment I got zero results. I checked the log file schedlgu.txt in
the C:\Windows directory and it hasn't been modified since July.
Scheduler service is running and set to automatic. I couldn't get it to
kick in and do anything.

The problems might very well be related. I don't know where to go from
here--any ideas?

Thanks,
Dan

On Tue, 26 Oct 2004 06:57:05 -0700, lbertacco
<lbertacco@discussions.microsoft.com> wrote:

>Hi Robert and Dan,
>
>I have notice that I've another issue since I installed SP2 and it might be
>related to this one.
>Can you tell me if you have the same issue too?
>
>Basically the Scheduled Tasks doesn't work anymore.
>
>If I create a scheduled task with option "Run only if logged on" enabled,
>then the scheduler doesn't even try to run the task as if I'm not logged on
>(but I AM logged on)
>If I create a task, say "calc.exe", with option "Run only if logged on"
>disabled, than the task is properly run, but I don't see the calculator
>window. It's like the task is run on a different session, which makes me
>think that the task scheduler belives that the current session is of a
>different user (actually I scheduled the task with the same user that I'm
>currently logged on as).
>
>Regards
>Livio