Windows integration tests fail due to mis-compiled test fuzzers

[ranweiler]

Windows integration tests build libFuzzers using the latest LLVM and Windows SDK. We install LLVM here. The SDK version is inherited from the GitHub Actions environment. A recent update to the Windows SDK (either here or maybe here) looks to have surfaced a mis-compilation in the Windows ASAN runtime static library that is shipped with LLVM. As a result, ASAN-instrumented targets exit abnormally, which our integration tests catch via a failed binary validity check.

In practice, the test failure looks like:

ERROR:integration:task failed: windows-libfuzzer - libfuzzer_fuzz (code=<ErrorCode.TASK_FAILED: 468> errors=['task failed. exit_status:code=1 signal=None success=False', '', '[2021-09-15T18:08:22Z INFO onefuzz_agent::tasks::config] agent ready, dispatching task\n[2021-09-15T18:08:22Z INFO onefuzz_agent::tasks::config] task_start event_type:libfuzzer_fuzz\n[2021-09-15T18:08:25Z ERROR onefuzz_agent::managed::cmd] error running task: fuzzer does not respond to \'-help=1\'. output:Output { status: ExitStatus(ExitStatus(255)), stdout: "", stderr: "" }\nError: fuzzer does not respond to \'-help=1\'. output:Output { status: ExitStatus(ExitStatus(255)), stdout: "", stderr: "" }\n']) - 7a9a9766-5088-49f0-826b-39570d8a6e03

Ways we can work around this:

• Implement binary test artifacts (see: Support integration tests with fixed binary artifacts #1143), which would let us integration test with known-good artifacts
• In CI, patch LLVM post-install, for example, by replacing the faulty ASAN runtime static lib with a known good one.
• Downgrade the Windows SDK to a known "good" version (one which doesn't trigger the mis-compile's edge case).