[omaha-discuss] Downloaded File failed verification. Error code = 0x80040204

455 views
Skip to first unread message

robev

unread,
May 11, 2010, 11:34:44 AM5/11/10
to Omaha Discuss
I'm THIS close to getting Omaha to work for my company's needs. At the
present moment I am just using a test executable instead of a real
installer. This test executable simply writes to the registry the keys
necessary to register with omaha (Clients\{GUID}\name and pv)

When I do GoogleUpdate.exe /install... it starts downloading the newer
executable that registers a newer version key, but then it says
Download error. The downloaded file failed verification. Error code =
0x80040204.

I looked at the GoogleUpdate.log and it says where it downloaded the
exe, and I found it in complete condition. So I'm not sure what the
problem is, and whats not being verified properly.

I read that the 'installer' should return 0 for success, which is what
my exe does (I'm pretty sure). Is this the reason for the error? If
not, what is?

Near the bottom of the log I see this:

[05/11/10 11:02:50.708][GoogleUpdate:goopdate][1588:1068][job
completed][status 2][completion code 3][error 0x80040204][text
"Download error. The downloaded file failed verification. Error code =
0x80040204"]
[05/11/10 11:02:50.708][GoogleUpdate:goopdate][1588:1068]
[WorkerJob::OnComplete][3][0x80040204]
[05/11/10 11:02:50.709][GoogleUpdate:goopdate][1588:1068][DownloadJob
failed with 0x80040204]

Which doesn't help much except its completion code 3.

Above it I found this which might be relevant:

[05/11/10 11:02:50.497][GoogleUpdate:goopdate][1588:1068]
[ValidateDownloadedFile][C:\Users\User\AppData\Local\Google\Update
\Download\{F8A2D768-A6C9-4952-93BA-235FDDFEB835}\Hello1010.exe]
[KQlI17pssk1h5B4EpWLrLHJFNEA=][59392]
[05/11/10 11:02:50.509][GoogleUpdate:goopdate][1588:1068]
[Job::DownloadJob DownloadFile failed][0x80040204][{0F1DCFE2-
E68D-4B9E-9BE0-5E69954ACCF9}]

at first I noticed the download location isnt the same GUID as the one
from my /install (the last GUID is) but I think it just put it in a
location thats guaranteed to be unique.

Any help would be appreciated

Thanks

--
You received this message because you are subscribed to the Google Groups "Omaha Discuss" group.
To post to this group, send email to omaha-...@googlegroups.com.
To unsubscribe from this group, send email to omaha-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omaha-discuss?hl=en.

robev

unread,
May 11, 2010, 11:44:14 AM5/11/10
to Omaha Discuss
I noticed in one of the log lines I pasted that
[KQlI17pssk1h5B4EpWLrLHJFNEA=][59392]

appears after the ValidateDownloadedFile line. The first part is the
hash and the second part is the filesize. I found in the google code
that ValidateDownloadedFile() checks if they're correct. I have
checked myself and I'm pretty sure those are the correct values, so
I'm not sure why it thinks they are wrong.

David Dorwin

unread,
May 11, 2010, 11:49:12 AM5/11/10
to omaha-...@googlegroups.com
This error is SIGS_E_INVALID_SIGNATURE, which means the hash of the downloaded file does not match the one in the update response. Make sure the update response has a hash and size and it matches the file you downloaded. The hash is a SHA-1 hash. You should be able to see the hash Omaha is expecting in the update response in the same log.

FYI, Omaha errors start with 0x8004 (SEVERITY_ERROR, FACILITY_ITF), so if you see an error that starts with this value, look in common/error.h to find the constant, which should give an indication of what is wrong and allow you to search for places it can occur.

Sorin Jianu

unread,
May 11, 2010, 11:49:59 AM5/11/10
to omaha-...@googlegroups.com
Hi,
Omaha validates the integrity of each file it downloads by comparing the expected hash of the file in the update response with actual hash of the file it downloaded. The hash value itself is a SHA-1 hash of the installer binary, encoded in base64. In other words, what's being returned in the update response must match what's computed for the file.

Just to clarify, we need to talk about what other changes you need to make _before_ releasing your Omaha-based update solution. Otherwise, there will be conflicts between the two updaters and things will break.

I hope this helps. Thank you!

robev

unread,
May 11, 2010, 12:26:11 PM5/11/10
to Omaha Discuss
So in the log the has appears several times:

[Send response received][<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response"
protocol="2.0">
<daystart elapsed_seconds="43433"/>
<app appid="{0F1DCFE2-E68D-4B9E-9BE0-5E69954ACCF9}" status="ok">
<updatecheck Version="1.0.1.0" codebase="URL/Hello1010.exe"
hash="KQlI17pssk1h5B4EpWLrLHJFNEA=" needsadmin="false" size="59392"
status="ok"/>
</app>
</gupdate>
]

and

[ValidateDownloadedFile][..\{BD265475-
AAB3-4754-86CB-854E038F9B95}\Hello1010.exe]
[KQlI17pssk1h5B4EpWLrLHJFNEA=][59392]

is this the update response? The two hashes are the same
> > omaha-discus...@googlegroups.com<omaha-discuss%2Bunsubscribe@goog legroups.com>
> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/omaha-discuss?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Omaha Discuss" group.
> > To post to this group, send email to omaha-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > omaha-discus...@googlegroups.com<omaha-discuss%2Bunsubscribe@goog legroups.com>
> > .

Sorin Jianu

unread,
May 11, 2010, 12:44:24 PM5/11/10
to omaha-...@googlegroups.com
On Tue, May 11, 2010 at 9:26 AM, robev <rob...@gmail.com> wrote:
So in the log the has appears several times:

[Send response received][<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response"
protocol="2.0">
 <daystart elapsed_seconds="43433"/>
 <app appid="{0F1DCFE2-E68D-4B9E-9BE0-5E69954ACCF9}" status="ok">
   <updatecheck Version="1.0.1.0" codebase="URL/Hello1010.exe"
hash="KQlI17pssk1h5B4EpWLrLHJFNEA=" needsadmin="false" size="59392"
status="ok"/>
 </app>
</gupdate>
]

and

[ValidateDownloadedFile][..\{BD265475-
AAB3-4754-86CB-854E038F9B95}\Hello1010.exe]
[KQlI17pssk1h5B4EpWLrLHJFNEA=][59392]

is this the update response? The two hashes are the same

The hash value in the log statement above is the expected value that comes from the update response. The log line effectively logs the arguments of ValidateDownloadedFile, which in this case are the expected values. Are there any log lines following? They should log the actual hash. For instance, search the debug log for "actual hash=".
 

robev

unread,
May 11, 2010, 1:21:38 PM5/11/10
to Omaha Discuss
Okay you guys were right. I couldn't find actual hash anywhere in the
log but I stepped through the code and saw the expected hash compared
against the actual and it WAS wrong.

So thats all fixed. Yay :)

Now an unrelated error that I noticed in this process thats coming to
bite me. Whenever I run the installer it ALWAYS gets the latest
version even if its already installed.

I think it has to do with this error:

[05/11/10 13:10:05.585][GoogleUpdate:goopdate][5796:5660]
[RegKey::GetValue failed][0x80070002][HKCU\Software\..\{0F1DCFE2-
E68D-4B9E-9BE0-5E69954ACCF9}][dr]
[05/11/10 13:10:05.586][GoogleUpdate:goopdate][5796:5660][Could not
ProcessKey][0x80070002][{0F1DCFE2-E68D-4B9E-9BE0-5E69954ACCF9}]

What happens is my program doesn't send the Version Number when it
checks for an update, so it always gets it.
I'm pretty sure it has to do with these registry values not being able
to be read. Why do you think that is? I'll step through the code and
try and see but it might have to do with admin privileges maybe? This
is for HKCU not HKLM though so I don't think its necessary.

The registry key "pv" does exist by the way, and its the latest
version.

On May 11, 12:44 pm, Sorin Jianu <so...@google.com> wrote:

Sorin Jianu

unread,
May 11, 2010, 1:26:16 PM5/11/10
to omaha-...@googlegroups.com
Awesome! Just to clarify an important thing: are you using a machine or a user installer?

robev

unread,
May 11, 2010, 1:30:41 PM5/11/10
to Omaha Discuss
For now, user installer. Maybe later machine but that will definitely
require admin privileges
> To post ...
>
> read more »

David Dorwin

unread,
May 11, 2010, 1:39:08 PM5/11/10
to omaha-...@googlegroups.com
That log entry is probably related to reading active data. It shouldn't cause failures.

When you install an app, it will always send version 0 to your server. This is so that over-installs work correctly. For update checks, it will send the version you registered in the pv value.

FYI, there is a bug that was preventing you from seeing the "actual hash" log entry. If you're interested in fixing it locally, add 
  LC_ENTRY(LC_REPORT),
to the end of LogCategoryNames in common\logging.cc.

Sorin Jianu

unread,
May 11, 2010, 1:43:38 PM5/11/10
to omaha-...@googlegroups.com
Can you please post here or send me the update request and response respectively, in the case of an install and update. The most important pieces of data are the versions. You can edit the privacy-sensitive data if you'd like to. I know you mentioned that the pv exists and it is the correct version. Make sure you are checking HKCU\SOFTWARE\<Your Co>\Update\Clients\<Your appid>\ for the pv value.

On Tue, May 11, 2010 at 10:30 AM, robev <rob...@gmail.com> wrote:

robev

unread,
May 11, 2010, 2:00:51 PM5/11/10
to Omaha Discuss
[05/11/10 13:48:58.829][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eff78][receiving]
[05/11/10 13:48:58.829][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eff78][received]
[05/11/10 13:48:58.829][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eff78][closing]
[05/11/10 13:48:58.829][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eff78][closed]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068][bytes
downloaded 250]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068]
[SimpleRequest::Send][0x00000000][200]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068]
[HttpRequestInterface::Send returned 0x00000000]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068][Send request
returned 0x00000000. Http status code 200]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068][Send
response received][<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response"
protocol="2.0">
<daystart elapsed_seconds="49735"/>
<app appid="{430FD4D0-B729-4F61-AA34-91526481799D}" status="error-
unknownApplication"/>
</gupdate>
]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068]
[Setup::~Setup]
[05/11/10 13:48:58.830][GoogleUpdate:goopdate][5004:6068]
[WorkerJob::DoUpdateCheck]
[05/11/10 13:48:58.831][GoogleUpdate:goopdate][5004:6068]
[WorkerJob::OnCheckingForUpdate]
[05/11/10 13:48:58.831][GoogleUpdate:goopdate][5004:6048]
[ProgressWnd::OnCheckingForUpdate]
[05/11/10 13:48:58.831][GoogleUpdate:goopdate][5004:6068]
[WorkerJob::CreateRequestFromProducts]
[05/11/10 13:48:58.832][GoogleUpdate:goopdate][5004:6068]
[GenerateRequest]
[05/11/10 13:48:58.832][GoogleUpdate:goopdate][5004:6068][Sending
update check...]
[05/11/10 13:48:58.843][GoogleUpdate:goopdate][5004:6068][detected
configurations][
source=IE, direct connection
source=auto, wpad=1, script=
]
[05/11/10 13:48:58.843][GoogleUpdate:goopdate][5004:6068][Send]
[url=http://myURL/gu/update2/][request=<?xml version="1.0"
encoding="UTF-8"?><o:gupdate xmlns:o="http://www.google.com/update2/
request" protocol="2.0" version="1.2.187.0" ismachine="0"
testsource="auto" requestid="{745C9403-1A28-4512-
B962-41CA731FB978}"><o:os platform="win" version="6.1" sp=""/><o:app
appid="{0F1DCFE2-E68D-4B9E-9BE0-5E69954ACCF9}" version="" lang="en"
brand="" client="" installage="0"><o:updatecheck/></o:app></o:gupdate>
][filename=]
[05/11/10 13:48:58.843][GoogleUpdate:goopdate][5004:6068][msg Trying
config: source=IE, direct connection]
[05/11/10 13:48:58.843][GoogleUpdate:goopdate][5004:6068][trying
CUP:WinHTTP]
[05/11/10 13:48:58.843][GoogleUpdate:goopdate][5004:6068][http://myURL/
gu/update2/]
[05/11/10 13:48:58.844][GoogleUpdate:goopdate][5004:6068]
[SimpleRequest::Send][http://myURL/gu/update2/?
w=3:q5RnT51m9WJUUY06A8vai1ixPtfUgMzkC9Uma6VoY8YhpY8KKCQs1XZC332Yb2nDqrnQf2qkA0OQAprwxJmH9wAKL2A1UxB5bxTvYSqfybGcDk7j_5shps0huvZKikkoAynQZ8s7N5yQblH-2hspf0ksCZX0g9jKZ92TQvi5nc4]
[05/11/10 13:48:58.844][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][resolving][myURL]
[05/11/10 13:48:58.844][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][resolved][216.139.221.156]
[05/11/10 13:48:58.845][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][connecting][216.139.221.156]
[05/11/10 13:48:58.890][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][connected][216.139.221.156]
[05/11/10 13:48:58.890][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][sending]
[05/11/10 13:48:58.891][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][sent]
[05/11/10 13:48:58.923][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][connected][216.139.221.156]
[05/11/10 13:48:58.923][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][sending]
[05/11/10 13:48:58.923][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][sent]
[05/11/10 13:48:58.947][GoogleUpdate:goopdate][4992:5960]
[SimpleRequest::DoSend][request sent]
[05/11/10 13:48:58.947][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][receiving]
[05/11/10 13:48:58.948][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][received]
[05/11/10 13:48:58.948][GoogleUpdate:goopdate][4992:5960][response
headers...]
HTTP/1.1 404 Not Found
Connection: close
Date: Tue, 11 May 2010 17:48:55 GMT
Content-Length: 299
Content-Type: text/html; charset=iso-8859-1
Server: Apache/2.2.3 (Red Hat)


[05/11/10 13:48:58.949][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][receiving]
[05/11/10 13:48:58.949][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][received]
[05/11/10 13:48:58.949][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][closing]
[05/11/10 13:48:58.949][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][closed]
[05/11/10 13:48:58.949][GoogleUpdate:goopdate][4992:5960][bytes
downloaded 299]
[05/11/10 13:48:58.949][GoogleUpdate:goopdate][4992:5960]
[SimpleRequest::Send][0x00000000][404]
[05/11/10 13:48:58.950][GoogleUpdate:goopdate][4992:5960]
[HttpRequestInterface::Send returned 0x00000000]
[05/11/10 13:48:58.950][GoogleUpdate:goopdate][4992:5960][Send request
returned 0x80042194. Http status code 404]
[05/11/10 13:48:58.950][GoogleUpdate:goopdate][4992:5960][Send
response received][]
[05/11/10 13:48:58.950][GoogleUpdate:goopdate][4992:5960][file bytes:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//
EN">.<html><head>.<title>404 Not Found</title>.</head><body>.<h1>Not
Found</h1>.<p>The requested URL /gu/check2/ was not found on this
server.</p>.<hr>.<address>Apache/2.2.3 (Red Hat) Server at http://myURL
Port 80</address>.</body></html>.]
[05/11/10 13:48:58.950][GoogleUpdate:goopdate][4992:5960]
[SimpleRequest::Close]
[05/11/10 13:48:58.950][GoogleUpdate:goopdate][4992:5960]
[HttpClient::StatusCallback][0x002a9970][0x00000800]
[05/11/10 13:48:58.951][GoogleUpdate:goopdate][4992:5960]
[BitsRequest::Close]
[05/11/10 13:48:58.951][GoogleUpdate:goopdate][4992:5960]
[FixGoogleUpdate returned 0x80004005]
[05/11/10 13:48:58.952][GoogleUpdate:goopdate][4992:5960]
[has_uninstalled is 0]
[05/11/10 13:48:58.952][GoogleUpdate:goopdate][4992:5960]
[AggregateMetrics]
[05/11/10 13:48:58.952][GoogleUpdate:goopdate][4992:5960]
[Goopdate::~Goopdate]
[05/11/10 13:48:58.952][GoogleUpdate:goopdate][4992:5960]
[GoopdateImpl::~GoopdateImpl]
[05/11/10 13:48:58.953][GoogleUpdate:goopdate][4992:5960][exception
handler has been uninstalled]
[05/11/10 13:48:58.953][GoogleUpdate:goopdate][4992:5960][DllEntry
exit][0x00000000]
[05/11/10 13:48:58.991][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][sending]
[05/11/10 13:48:58.991][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][sent]
[05/11/10 13:48:58.992][GoogleUpdate:goopdate][5004:6068]
[SimpleRequest::DoSend][request sent]
[05/11/10 13:48:58.992][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][receiving]
[05/11/10 13:48:58.992][GoogleUpdate:goopdate][5004:6068]
[HttpClient::StatusCallback][0x006eb428][received]
[05/11/10 13:48:58.992][GoogleUpdate:goopdate][5004:6068][response
headers...]
HTTP/1.1 200 OK
Connection: close
Date: Tue, 11 May 2010 17:48:55 GMT
Content-Length: 279
Content-Type: text/html
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.1.6

430.. is googleupdate itself. my server doesn't know how to handle
updating it I guess because it says error-unknownApplication and we
dont handle that GUID

0F1D.. is my GUID

the version number is empty that it sends.

Since the version number is empty we now have it set up to spit out an
error when that happens. So its not installing it anymore but I'd like
to find out why its not sending the version number

robev

unread,
May 11, 2010, 3:13:29 PM5/11/10
to Omaha Discuss
Okay walking through the code I found that when it tries to open the
registry keys it looks at
HKCU\...\Update\Clients\{0F1DCFE2-
E68D-4B9E-9BE0-5E69954ACCF9}\Components
What's with this Components subkey? All my stuff is in {GUID}, there's
nothing called Components. Should I add this in?

I found that this is stored in the constant kComponentsRegKeyName
which is used in the function:

AppendRegKeyPath(GetProductClientKeyName(app_guid),
kComponentsRegKeyName);

why is this being done?

Thanks for all your help
> server.</p>.<hr>.<address>Apache/2.2.3 (Red Hat) Server athttp://myURL

robev

unread,
May 11, 2010, 3:51:23 PM5/11/10
to Omaha Discuss
Okay now I'm wondering if theres a bug at all.
I was running /install manually each time, which would always get the
latest version regardless of the current version. When it sent
requests the version number was blank.

But I notice that when theres an automatic check for updates, the
version number IS sent. It would then download/install the latest
version. This is what I think should be happening. They shouldn't be
running the metainstaller each time to get updates, so it doesn't
matter that when you run it no version number is sent. I guess this is
to ensure that the latest version is always installed the first time.

Are these assumptions correct? Do I have everything up and running?

David Dorwin

unread,
May 11, 2010, 3:58:05 PM5/11/10
to omaha-...@googlegroups.com
Yes, that is correct. Omaha installs tasks and a service (for machine apps) to check for updates automatically and silently.

There are two types of update checks: initial update check requests to download the app installer when you run the metainstaller and update checks to see if there are updates. In the first case, it does not send a version so that over-installs work correctly. Otherwise, the user might get "no update". The version in pv is only sent during the latter case.

You can ignore the Components stuff. It's something that has been deprecated. There will be lots of "not found" or even "failed to read" log messages as Omaha checks various optional values. They don't necessarily mean that something is wrong.

Regarding the Omaha ID (430..) in your log, that is a ping, not an update check. Your server should add the Omaha ID (or rather a new GUID for your instance of Omaha) to your server so the server recognizes the app and responds with "ok" to these pings. If the app is recognized, the response should always be "ok".

On Tue, May 11, 2010 at 12:51 PM, robev <rob...@gmail.com> wrote:
m wondering if theres a bug at all.
I was running /install manually each time, which would always get the
latest version regardless of the current version. When it sent
requests the version number was blank.

But I notice that when theres an automatic check for updates, the
version number IS sent. It would then download/install the latest
version. This is what I think should be happening. They shouldn't be
running the metainstaller each time to get updates, so it doesn't
matter that when you run it no version number is sent. I guess this is
to ensure that the latest version is always installed the fi

Reply all
Reply to author
Forward
0 new messages