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!
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
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_HASHload failure) and skip injection attempts into such processesautomatically? 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 everynew process. An opt-in model would fit Windhawk's architecture well:
Includefield.Includetargets and restrict globalinjection to that set automatically (unless the user explicitly overrides it).
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!