Re: Update still failing with 80240020 and 8024000c

From: Robert Aldwinckle (robald_at_techemail.com)
Date: 10/22/04 

Date: Fri, 22 Oct 2004 15:01:41 -0400

"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.com/ClientWebService/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.com/ClientWebService/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.com/msdownload/update/v3-19990518/cabpool/hmtcdwizard_enu_80a018bb6f81870a5dbc5d9b236ec85.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.com/msdownload/update/v3-19990518/cabpool/hmtcdwizard_enu_80a018bb6f81870a5dbc5d9b236ec85.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

Relevant Pages

  • Re: WindowsUpdate failing -- log
    ... >Which account is being used on that connection? ... >Do you see SID mentioned in there? ... That is the SYSTEM account. ... I just looked at this and "Allow service to interact with desktop" was ...
    (microsoft.public.windowsupdate)
  • Re: EFS Decryption Problem
    ... Was it only used to match up to the backed up userprofile, ... I thought the account's SID and password was involved in generating the ... a new account is created). ... instance of Windows would have a different SID even after restoring the ...
    (microsoft.public.windowsxp.security_admin)
  • RE: Error 15401 using sp_grantlogin (not addressed by current KB articles)
    ... argument to get_sid, it returns a sid. ... The sysxlogins.name column stores the NT account ... One way to get SQL Server to agree with the renamed NT ... check "Script all objects", on the Formatting tab UNcheck "Generate the ...
    (microsoft.public.sqlserver.security)
  • Re: is there a simple to get "userid" in a windows domain?
    ... suspect a minor change to the way I access ntSecurityDescriptor would give ... Is it possible to get a User SID from ... >> than the account names when referring to the account. ... >> Eric Fitzgerald ...
    (microsoft.public.security)
  • Re: Process running under Adminstrator account
    ... I did not realize the SID was all that was needed. ... start with "administrator" and a dictionary or other attack? ... would not the changing of the admin name help? ... Renaming the account does not change the SID. ...
    (microsoft.public.windows.server.sbs)
Loading