brave-browser: Subsequent delta updates on Windows fail

This issue behaves exactly like #29469, except the reason now is different.

The present reason is that after a normal installation, setup.exe in Brave’s installation directory is code signed. But delta updates put a non-signed version of setup.exe into the installation directory. When the next delta update runs, it expects the code signed file. It sees a “different” file and falls back to the full update.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 21

Most upvoted comments

@MadhaviSeelam thank you for checking this. I need to aplogise: The instructions were not correct for per-user installations. For per-user installations, we want to use a normal command prompt, not an Administrator command prompt, and we should not set BraveSoftwareUpdateIsMachine=1. Your replication steps work for me with these adjustments. Can you check whether they work for you too? Sorry for the trouble.

@mherrmann sounds good. QA passing this issue.

@MadhaviSeelam the steps you documented are really clear to understand. Thank you!

When you invoke brave_installer-delta-x64.exe from the command line, then the contents of BraveUpdate.log do not matter. All that matters is that brave://version shows the expected new version.

Let me explain why.

Brave’s update mechanism on Windows works as follows: It asks the update server for a new version. If there is a new version, then the server returns the URL to a .exe file. The updater downloads and runs this file. As it performs these steps, it writes to BraveUpdate.log.

If the .exe fails with a non-zero exit code, then the updater repeats the process on the same channel, but with -full appended to the channel name. This lets the updater fall back to the full update when a delta update fails. For example: The typical Nightly channel is x64-ni. Say the updater obtained a delta update brave_installer-delta-x64.exe from there, but this .exe fails. Then the updater performs an update check on x64-ni-full. This returns the full installer, and so (hopefully) the update goes through even though the delta update failed.

Now to tie this back to BraveUpdate.log: When we manually execute brave_installer-delta-x64.exe on the command line, then we are simulating the updater. The reason why we do it this way is that the updater would receive the full update 1.54.43 -->1.54.53 from the server, which would prevent us from testing the delta 1.54.43 -->1.54.48. The relevant log file for brave_installer-delta-x64.exe is C:\Users\<user>\AppData\Local\Temp\chromium_installer.log.

I hope this helps clarify the context?

@MadhaviSeelam great, thanks. As long as the correct version is shown in brave://version, then I don’t consider the log files important.

@MadhaviSeelam I have done testing on Windows 10 x64, please add the QA pass label once you’re done with the per-user installations testing on windows 11. Thanks!

@GeetaSarvadnya This issue is passed on Win 11 x64 and I am yet verify in Win arm64. When you get a chance, please test this issue on Win 10.

@MadhaviSeelam yes, Unable to connect to Internet is expected. It seems like everything worked now. Thank you for checking again! 🙏