Improve MOTW error handling in download flow

[Trenly]

• I have signed the Contributor License Agreement.
• I have updated the Release Notes.
• This pull request is related to an issue.
  • Resolves [Sandbox Test]: WinGet failed to download installer file with proper name #6121
  • Resolves Installer downloaded successfully and exists on disk, but installation phase fails/silently exits #6126

Fix MOTW security check failures for downloaded installers

Problem

All installer downloads were failing the security check with 0x80070003 (ERROR_PATH_NOT_FOUND), causing every install to terminate with "Installer failed security check".

Two root causes were identified:

• Wrong file scanned by IAttachmentExecute — UpdateInstallerFileMotwIfApplicable ran before RenameDownloadedInstaller in the workflow. This meant the Attachment Execution Service (AES) was scanning the
  temporary pre-hash-validation file (a raw SHA256 hex string with no extension, e.g. aab2dc8e…) rather than the final installer (e.g. BadlionClient.exe).

Important

Shell32's AES relies on file extension for MIME-type detection, scan policy, and zone assignment, so scanning an extensionless file produced unreliable results

• RemoveMotwIfApplicable failures aborted the security check — If removing the existing Zone.Identifier ADS failed, the exception propagated through the AES thread, leaving IAttachmentExecute::Save() never
  called and the whole check returning a failure code. Additionally, a missing THROW_IF_FAILED(hr) after IPersistFile::Load meant unexpected load errors were silently ignored, leading to Remove()/Save()
  being called on a non-loaded object.

Changes

DownloadFlow.cpp

• Reorder workflow: RenameDownloadedInstaller now runs before UpdateInstallerFileMotwIfApplicable, so AES always scans the properly-named installer file.

Downloader.cpp — RemoveMotwIfApplicable

• Also handle ERROR_PATH_NOT_FOUND (in addition to ERROR_FILE_NOT_FOUND) from IPersistFile::Load — different Windows builds return different codes when no Zone.Identifier ADS is present.
• Restore missing THROW_IF_FAILED(hr) to correctly surface any other Load failures rather than falling through to Remove()/Save() on an unloaded object.

Downloader.cpp — ApplyMotwUsingIAttachmentExecuteIfApplicable

• Wrap RemoveMotwIfApplicable in a try/catch inside the updateMotw lambda — log a warning but proceed to IAttachmentExecute::Save(). MOTW removal is best-effort; a removal failure should not abort the
  security scan.
• Wrap the entire AES thread body in try/catch and log exceptions via AICLI_LOG, so unhandled errors are surfaced rather than silently leaving hr in an indeterminate state. Use LOG_IF_FAILED for
  CoInitializeEx so failures are captured through WIL.
• Fix the return value: previously aesSaveResult was always returned, reporting S_OK when Save() was never reached (e.g. after CoInitializeEx failure). Now returns the thread's hr when aesSaveResult was
  never updated

---

Microsoft Reviewers: Open in CodeFlow

[Dragon1573]

Sorry to ask here. 🙏🏼

Is there any unknown reason that blocks this PR? A new preview version of winget.exe was released but I still unable to install packages from local manifests ...

[JohnMcPMS]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[JohnMcPMS]

I just realized that the failures being missing from the logs is probably due to this new thread. If you want this change to actually make the logs show up and not just fix the error handling, you would need to:

// outside lambda
ThreadGlobals* globals = ThreadGlobals::GetForCurrentThread();
// capture into lambda
... = [..., globals] (...)
{
if (globals)
{
  auto globalsCleanup = globals->SetForCurrentThread();
}
...
}

[Trenly]

Given that the error handling is the main thing causing the issue, my preference is to get this error handling merged so that some portion of the local manifests start working again for users who are having issues, and I can raise a second PR for the logging globals

[Dragon1573]

Hi @JohnMcPMS @hackean-msft, 👋🏼

I notice the latest prerelease v1.29.140-preview was just publisher around 9 hours ago. But it was tagged at commit 69a9e3d.

Could you please tell when this PR can be bundled into the prerelease? It blocks us from validating local manifests before submitting to winget-pkgs ... 🙏🏼

[Trenly]

@Dragon1573 - Based on previous discussions I've had in the Gitter chat, the prereleases have to go through some level of internal testing before they are published to GitHub. I'm not sure how frequently they are built and tested, but given that 69a9e3d was 3 weeks ago, and it seems like the pre-releases are happening almost weekly, I'd think it would be another 2-3 weeks before this makes it into a pre-release, depending on the internal build/test cycle of course

[florelis]

We generally make a weekly build based on the code at 00:00 Pacific time on Mondays. This was merged after that, so it didn't make the cut for this week, but it should be in next week's build. Each build is first distributed internally, and if everything goes well, it is published as a preview after a week.

So, if things go smoothly, you would see a build with this in about 2 weeks.

[Dragon1573]

Okay ❤️

If I'm eager to having issue been resolved in the binary, I should build master branch on my own locally. Is that right?

[florelis]

@Dragon1573 yes, but when you deploy that it will be available as wingetdev.exe instead of winget.exe