I ran into an edge case today while helping a friend with CrowdStrike on a Windows 11 24H2 endpoint protected by Windows Defender Application Control (WDAC).

Even with a working signer allow rule for CrowdStrike, install still failed in some capacity because a temporary installer binary was blocked at runtime by Code Integrity policy enforcement. Or at least, the event logs for all clients lit up with a failure note (3033, 3037 events).

The key “trick” was to run the installer in a “Windows Sandbox” instance so that it was a very clean install, save the event log, and then use the WDAC wizard to get the two failure messages which contained the signer information for the temp files created by CrowdStrike.

If you’ve worked with WDAC extensively, you might be rolling your eyes at this point. In theory, if you’ve carefully captured the required signers in your policy, this step shouldn’t be necessary—and I’ll admit that was my reaction when the support engineer first suggested it. The only reason I’m writing this post is that it actually worked for me this time. Historically, I’ve had very little success using the event log–driven approach, but in this case it ended up being the key.

The symptom

A representative block looked like this:

Code Integrity determined that a process (...\CSInstallTemp{GUID}\TMP1187.tmp) attempted to load ...\TMP1187.tmp that did not meet the Custom 3 / Antimalware signing level requirements or violated code integrity policy (Policy ID:{7f4a6b2d-9c31-4d8e-8ab4-21f3c6d9e5a7}).

Another related block was Event ID 3077 for:

...\CSFalconServiceUninstallTool_x64.exe

Environment where this occurred

• OS: Windows 11 24H2
• WDAC policy mode: enforced
• Base policy ID example: {7f4a6b2d-9c31-4d8e-8ab4-21f3c6d9e5a7}

Why this happens

CrowdStrike setup can execute temporary or packaged components that do not always match the signer pattern you expected when you only allow the primary vendor signer at a broad level.

In practice, you may need to explicitly trust additional signer metadata (for example, a Microsoft hardware compatibility publisher chain plus the CrowdStrike publisher for a specific file attribute pairing).

Recommended fix (from Microsoft support guidance)

Use the App Control for Business Wizard to generate a supplemental policy from observed CI events.

Microsoft documentation:

• App Control Wizard event log flow: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-create-policy
• Policy merge operation: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/appcontrol-wizard-policy-merge

Steps

1. Run the installer in Windows Sandbox: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/
2. Export the “CodeIntegrity” event log. (Event Viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)
3. Open App Control Wizard (back on your engineering machine).
4. Choose Select Event Log Files.
5. Load the CIOperational.evtx file.
6. Locate the relevant CrowdStrike block events (including both 3077 events if present).
7. For each event, select trust based on Issuer + Publisher pairing.
8. Complete the wizard to generate a supplemental policy.
9. Then, use the wizard again to merge this policy with your existing base policy.

Operational notes

• Start in audit where possible before enforce in production.
• Treat installer temp paths as volatile; build trust from signer/publisher evidence, not one-off path exceptions.
• Validate on a pilot ring before broad deployment.

This approach resolved the install block cleanly while keeping WDAC guardrails intact.