#1061·windhawk

CodeIntegrity Event 3033 spam: engine repeatedly tries to inject into processes with signed-image mitigation policies

Author: karayelxyzCreated Aug 24, 2026Updated Sep 18, 2026
Labelsbugpre-release

When Windhawk runs with its default global injection configuration, processes that enforce Microsoft signed-image mitigation policies (e.g. Chrome-based browsers like Helium/Brave, some svchost.exe instances) repeatedly attempt to load windhawk.dll, fail the signing level check, and generate CodeIntegrity Event ID 3033 entries in Microsoft-Windows-CodeIntegrity/Operational.

On my system this produced ~150+ events within minutes of boot:

Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\imput\Helium\Application\chrome.exe) attempted to load \Device\HarddiskVolume3\Program Files\Windhawk\Engine\1.7.3_1\64\windhawk.dll that did not meet the Microsoft signing level requirements.

The DLL load always fails (the process is never modified), but Windhawk keeps retrying on every relevant process start, flooding the event log. This also makes legitimate security auditing harder, since real CodeIntegrity events get buried under noise.

Environment

  • Windhawk version: 1.7.3_1 (valid signature)
  • OS: Windows 11 26H1
  • Mods installed: start-menu-open-location, win-d-per-monitor (both target explorer.exe only)

Current workaround

Setting the engine advanced settings to include-only mode stops the noise completely:

HKLM\SOFTWARE\Windhawk\Engine\Settings Include = explorer.exe Exclude = *

After restarting Windhawk, zero new 3033 events are logged, and both explorer-targeted mods continue working fine.

Suggestion 1: Detect and skip mitigated processes

Would it be possible for the engine to detect that a target process has an image-load mitigation policy restricting DLLs to Microsoft-signed images (or detect the repeated ERROR_INVALID_IMAGE_HASH load failure) and skip injection attempts into such processes automatically? Alternatively, suppressing retries after the first failure per executable path would already eliminate most of the log spam.

Suggestion 2: Opt-in whitelist as a safer default model

My mods only need explorer.exe, yet by default the engine attempts injection into every new process. An opt-in model would fit Windhawk's architecture well:

  • Each mod already declares its target processes via its Include field.
  • The engine could derive a union of all enabled mods' Include targets and restrict global injection to that set automatically (unless the user explicitly overrides it).
  • Users who genuinely want all-process injection (e.g. for wildcard-target mods) could keep the current behavior via an explicit setting.

This would reduce event log noise and antivirus/EDR friction by default, while keeping full flexibility for power users. Thanks for the great tool!