Skip to content

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

Description

@karayelxyz

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingplannedThe issue is planned to be addressed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions