Windows Defender Smartscreen blocks installation

[mrzade]

Triage

Issues are triaged at online meetings, generally held alternate Thursdays at 9:30 a.m. Pacific time (UTC-7/UTC-8). Meeting requests are sent to the wix-devs and wix-users mailing lists, as well as in Discussions.

Discussions and support

Note that discussions are best held on the mailing lists not in issues. Please do not open issues requesting support or debugging help; first start a thread on the wix-users mailing list and open an issue if the discussion suggests a bug in the WiX Toolset or that a feature request is appropriate. You can also try out the beta Discussions feature.

Instructions

Read the sections above. Delete the Triage, Discussions and support, and Instructions sections and fill out the rest.

Bugs

If this issue is a bug:

• Which version of WiX are you building with?

3.11.2.4516

• Which version of Visual Studio are you building with (if any)?

Visual Studio 2019 Pro (16.5.2)

• Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

1.0.0.4

• Which version of .NET are you building with?

4.7

• If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Windows 10 Pro v1909 20H2 (Build 18363)

• Describe the problem and the steps to reproduce it.

We experience weird behavior of our installer when running it on recent versions of Windows 10 with Windows Defender SmartScreen turned on.
The installer is a single-file Burn bootstrapper that launches several EXE packages (VC Runtime installers of different versions that are required by the components we're using in our product) followed by several MSI packages (that is our product, support tools, and a device driver). The installation occurs per-machine, meaning it will be elevated by Burn at a certain moment. The installation package is downloaded from the internet (we have tested it with Google Drive).
The problem we are facing is that sometimes (we don't have found any pattern yet) when SmartScreen turned on (which is the default for fresh Windows installations!) it blocks the unpack, creation, and caching of the packages in PackageCache folder which makes the entire installation to fail!
The behavior is completely random - sometimes it starts with an error during the creation of the restore point followed by the mismatch of the checksum of the cached package; sometimes it cannot move verified files from .unverified folder to PackageCache folder. There is no particular package that fails - on one system it could be VC Runtime, on the other - one of the MSIs.
All our MSI, as well as EXE modules, are signed with either our corporate code signing certificate issued by DigiCert (not EV certificate), or component vendor's certificate. All our MSIs are built with WiX. The installing user has administrative rights on the target system.
It is also worth mentioning that on some systems SmartScreen warning pops up. In this case, the user gives permission to run.

• Describe the behavior you expected and how it differed from the actual behavior.

Well, it is obvious - when the user gives his/her permission to run the installer, it should run without being blocked.

[barnson]

WiX doesn't use issues for support. We moved this issue to the experimental GitHub discussions area.

[mrzade]

Bob!
Sorry, but for me, it looks like a bug.

[BMurri]

@mrzade from this discussion area, we can help diagnose what happened to determine if we need to improve documentation (yes, we already know we need to improve documentation, but it helps us to see specific places where it goes wrong) or if there really is a bug in the code (it happens sometimes, but several of us haven't seen issues with SmartScreen with our installers as you're describing them).

Could you share logs associated with some of the failed installations, along with successful logs for comparison's sake?

[mrzade]

@BMurri thank you for the quick reply!
Attached are bootstrapper logs for failed and succeeded installations. Both runs have been made in the same environment - the only difference is that failed one has been executed with SmartScreen set to "Warn".

failure_smartscreen_on.log
success_smartscreen_off.log

[rseanhall]

The successful case is launched unelevated, the failure case was launched elevated. Probably would be fixed as part of #5856. Workaround is not to launch the bundle elevated.

[mrzade]

@rseanhall

The only thing the logs are showing is that you are not running the bundle the same way each time,

that is correct. The state of the SmartScreen / Windows Defender had been changed between the runs. But that was the point of the test!

and you are not cleaning up between runs.

As I mentioned before, I have uninstalled the packages before each run and deleted the content of temporary folders. What else I can clean up? Please advise, if there are some Burn command-line switches that activate extended logging.

I don't see any bugs here.

From the log of Test 3:
[139C:1174][2021-03-09T01:53:02]e000: Error 0x80070003: Failed to move verified file to complete payload path: C:\ProgramData\Package Cache\Fif.Pkg.FifSEClient\packages\FifSE\fifse.msi
[139C:1174][2021-03-09T01:53:02]e000: Error 0x80070003: Failed to cache payload: Pkg.FifSEClient
[06BC:1160][2021-03-09T01:53:02]e314: Failed to cache payload: Pkg.FifSEClient from working path: C:\Users\Test\AppData\Local\Temp{F2893E71-DC56-451C-9F1D-E675386DE689}\Pkg.FifSEClient, error: 0x80070003.

To my understanding, Burn is responsible for caching. Or I'm missing something?

It looks like the error first logged at /src/burn/engine/cache.cpp, line 902 and could be traced back to the FileEnsureMove(). There is a special handling for ERROR_PATH_NOT_FOUND (hr=0x80070003) there. Maybe some additional flags are required for MoveFileEx() call?

[BMurri]

1_success_smarts_off_defender_off_nowibu.log is an uninstallation, not installation, but it leaves most of your packages installed (and cached).

2_success_smarts_off_defender_on_nowibu.log reveals that several changes to the system's state occurred between the two logs (several packages removed, some caches left in partial states) before it was run.

The package that failed in 3_fail_smarts_on_defender_on_nowibu.log (Pkg.FifSEClient) was partially cached at the start of `` but completely absent from the cache at the start of 2_success_smarts_off_defender_on_nowibu.log. I would suspect anti-virus product interference going on, but it's hard to say because each of these test cases don't start with the same machine/product-installation/cache states.

[mrzade]

@BMurri thanks for the tip!
It turned out that it fails whenever at least one of the packages is cached. However it is still not clear why does it happen and this raises questions:

• Is there any guide or "best practices" on caching and when to apply it?
• Is there any way to enforce cache cleanup before Installation from BA?
• What does "partial caching" mean?

Please note that we're using WiX since 2010 and our bootstrapper doesnt changed much between software releases. It had survived several Windows generations without any major problems and this is the first time we are facing the issue that is showstopper.

Kind regards,
Denis.

[BMurri]

@mrzade Specific advice depends on your particular requirements, but in general leaving most attributes at default values by not writing them at all seems to best facilitate the most general use case scenarios in the collective experience of most of our clients (if you don't directly touch caching, packages will be cached when installed and removed when uninstalled, which allows them to be present in case repairs are needed). It can be appropriate to not cache packages that will never be repaired by your bundle(s) (which would generally include third-party "sharables" that are widely used, like MSFT libraries), but that's a general exception to the rule.

You may want/need to cache packages that could be installed later from the same bundle running in management mode (especially if that's an expected use case).

Make sure you use the option to verify all payloads using hashes (and never certificates).

If you build your bundle using msbuild (including using WixProj files in Visual Studio) make sure you are codesigning both the engine and the bundle separately using the targets provided in the documentation. If not, make sure you check out the documentation to see the steps for correct codesigning.

Submit your bundles to anti-virus providers so that they train their systems to not incriminate your packages (especially before you release to customers).

I'm sure others can add to this list, it's off-the-cuff and I'm sure I'm leaving various good ideas out.

Blair

[mrzade]

@BMurri thank you Sir for pointing me in the right direction!

Disabling caching on permanent packages and assigning unique CacheID before bundle compilation for the remaining solved the problem. Also, the trick with payload verification has helped since the installation crashed from time to time on one of the test systems due to the payload verification issues.

The feedback from the customers support team shows that the same issue occured with McAffe and Symantec antiviruses but never with ESET, AVG, or TrendMicro.

In general, I have an impression, that sometimes the Burn desides to overwrite previously cached package event if it is binary identical to that one that is currenty cached. It would be great if somebody form the dev. team on occasion double-checks the conditions that trigger caching.

Regards,
Denis.

[mrzade]

The answer is the reply from @BMurri.