What would cause the update client to return 0x80072F8F (-2147012721 decimal)

12 views
Skip to first unread message

Thom BENTLEY

unread,
Dec 16, 2024, 11:29:44 AM12/16/24
to Omaha Discuss
This happens during an auto update scenario using Omaha Consulting's implementation of the omaha server.
I don't have access to the client logs.

Screenshot 2024-12-16 at 11.05.30 AM.png



The information in this email and any attachments are intended solely for the recipient(s) to whom it is addressed, and may be confidential and/or privileged. Any unauthorized distribution or copying of this transmittal or its attachments is prohibited. If you are not a named recipient or have received this email in error: (i) you should not read, disclose, or copy it, (ii) please notify the sender of your receipt by reply email and delete this email and all attachments.

Joshua Pawlicki

unread,
Dec 16, 2024, 12:06:20 PM12/16/24
to omaha-...@googlegroups.com
That looks like "ERROR_INTERNET_DECODING_FAILED: WinINet failed to perform content decoding on the response. For more information, see the Content Encoding topic."

What's the Content-Encoding header on the download URL?

--
You received this message because you are subscribed to the Google Groups "Omaha Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omaha-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/omaha-discuss/a5a6ae1f-cb24-4119-b2de-cc7d6026aea9n%40googlegroups.com.

Thom BENTLEY

unread,
Dec 17, 2024, 12:48:06 PM12/17/24
to Omaha Discuss
Thanks.  Where did you find that error in the code base?
Also, How do I find the Content-Encoding Header if I don't have access to the client that's sending the error to the Omaha Server?

Thom BENTLEY

unread,
Dec 17, 2024, 12:48:07 PM12/17/24
to Omaha Discuss
What about an error code of 2?
Screenshot 2024-12-16 at 12.17.33 PM.png

On Monday, December 16, 2024 at 12:06:20 PM UTC-5 Joshua Pawlicki wrote:

Joshua Pawlicki

unread,
Dec 18, 2024, 11:20:43 AM12/18/24
to omaha-...@googlegroups.com
> Thanks.  Where did you find that error in the code base?

We have a CSV file of various Windows and updater error codes and their meanings, 0x80072F8F is WININET_E_DECODING_FAILED. Unfortunately I don't think the CSV is open-sourced.
If you're using Omaha 3, there's some special handling in this area as well that gives a hint: https://github.com/google/omaha/blob/c3e428cce2af4f8619658b553292147643820219/omaha/net/simple_request.cc#L721C15-L721C40


> Also, How do I find the Content-Encoding Header if I don't have access to the client that's sending the error to the Omaha Server?

If you know the URL the client is trying to download, it's possible you can just issue a request yourself to that URL using curl or a similar tool and look at the Content-Encoding header.

But, on further reading, I think it's more likely that this is a TLS version error, so you might check to make sure that the client is running on a version of Windows that supports whatever TLS version the server wants to speak. (e.g. the client may need to install KB3140245 on Win 7 - refer to https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392)


> installer error 2

Most likely this is due to the application installer exiting with exit code 2. I don't think I can know more without having the source code for the application installer.

Thom BENTLEY

unread,
Dec 20, 2024, 12:57:56 PM12/20/24
to Omaha Discuss
Thanks,  Would love to have access to that CVS :) 

Sorin Jianu

unread,
Dec 20, 2024, 1:23:59 PM12/20/24
to omaha-...@googlegroups.com
On Fri, Dec 20, 2024 at 9:57 AM Thom BENTLEY <tben...@mdsol.com> wrote:
Thanks,  Would love to have access to that CVS :) 

To map errors such as 0x80072F8F, where the most significant word is 8007 and indicates a Windows system error, one needs to take the least significant word (in this case 2F8F), convert it to decimal (12175), then look it up on msdn. This error resolves to ERROR_WINHTTP_SECURE_FAILURE. 

Please note that because Omaha is using WinHTTP, then the error must be looked up in the WinHTTP documentation (https://learn.microsoft.com/en-us/windows/win32/winhttp/error-messages).

In this case, this indicates a problem with the TLS connection. Essentially, the client could not connect to the server because of an HTTPS issue.

WinInet is a different error stack, and errors reported are slightly different, even though they mean the same thing . The code in github Joshua linked below is correct but somewhat obsolete. At one point in the past, Omaha used a dual network stack (WinInet/WinHTTP). Some symbols still remained in the code after we dropped WinInet support. I am sorry for the confusion.

Reply all
Reply to author
Forward
0 new messages