Hmmmm. I just did something risky, or perhaps dumb on my production PC. You can see the evidence in the lead-in graphic, a PowerShell session that shows an issue (in red, at bottom) with the installer hash for a Google Chrome update. What you can’t see is that I was already updating Chrome inside Chrome itself while this was happening. The installer changes when a new version is installed. Fortunately, dissecting Winget logs shows root causes, so that’s what I did next. It was more illuminating than the error message, for sure…

How Dissecting Winget Logs Shows Root Causes

First, some background on Winget logs. You can find out more about them (and related troubleshooting stuff) in the MS Learn article “Debugging and troubleshooting issues with the winget tool.” It also gives you a huge honkin path where the log files reside — namely:

%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

But, rather than grab and use this, I simply told Voidtools Everything to show me all instances of the final directory name DiagOutputDir. That got me there a whole lot faster!

Once into the logfile named WinGet-2023-07-21-10-59-05.148.log I jumped to the bottom to see how it mentioned Chrome. Here’s the tail end of that log from 11:00:09 to 11:00:14.


2023-07-21 11:00:09.043 [CLI ] Generated temp download path: C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26
2023-07-21 11:00:09.043 [CORE] Downloading to path: C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26
2023-07-21 11:00:09.044 [CORE] DeliveryOptimization downloading from url: https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi
2023-07-21 11:00:13.663 [CORE] Download completed.
2023-07-21 11:00:14.593 [CORE] Started applying motw to C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26 with zone: 3
2023-07-21 11:00:14.602 [CORE] Finished applying motw
2023-07-21 11:00:14.603 [CLI ] Package hash verification failed. SHA256 in manifest [2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26] does not match download [aae26a4cf7d92a4c9198d8fac9534670e9fb5f8d1e38897d99b0b51e68107d2a]
2023-07-21 11:00:14.604 [CLI ] Terminating context: 0x8a150011 at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\DownloadFlow.cpp:15e
2023-07-21 11:00:14.604 [CLI ] Terminating context: 0x8a15002c at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\InstallFlow.cpp:28a


I bolded the line where things went south. Basically, the hash verification failed because I had already overwritten the old version of the installer with the new version (and the new Chrome version itself, as well). Good thing winget is smart enough to recognize the ground has shifted under its feet. If it finds things it doesn’t expect, it wisely decides to quit what it’s doing. Now I know what I had always suspected. And now, of course, you know too. Cheers!