Installing WindHawk causes the SentinelOne antivirus to report shell commands as suspicious.

[glorifyday]

I have a Windows 11 Pro PC with the SentinelOne (S1) antivirus installed.

The S1 allows the WindHawk (WH) to be installed and run and it does not report it as a threat.
However, as soon as WH is installed, the S1 starts being oversensitive when shell commands are run in the console (e.g. cmd, powershell) in an admistrative mode.

Namely, it reports certain commands as suspicious and it even sometimes quarantines system components.

Here is the list of commands that I found out to be treated as suspicious (I doubt it is complete, though):
fsutil dirty set C:
chkdsk /F C:
sfc /scannow
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
ipconfig /flushdns
gpupdate /force

I don't know why this happens and how can this be resolved. I cannot use WH and this is a bad news for me, because I loved the tweaks.

I described the problem in more detail on ServerFault:
https://serverfault.com/questions/1162325/can-sentinelone-act-in-a-different-way-on-a-windows-10-than-on-windows-11/1162752#1162752

[m417z]

There's not much Windhawk can do here. Windhawk is known not to play along with some antiviruses, as Windhawk injects code into all running processes, which is not something an average program does, and is a technique that's often misused.

You can try excluding some processes in Windhawk, such as cmd.exe, powershell.exe, and the processes you listed, or maybe all C:\Windows\System32\*.

Also, depending on the mods that you're using, you can exclude all processes but the ones you want to customize. You can configure it in the advanced settings. You can set * - all processes - in the exclusion list, and e.g. explorer.exe in the inclusion list. Note that this will cause mods to be injected with a slight delay, which may break some mods, therefore I'd suggest to only use this option as a last resort.

[glorifyday]

Hi, thanks for your answer.

I wanted ONLY:

• the Taskbar to be thin, like in Windows 10 with small icons,
• the windows without rounded corners.
  So all my mods were related just to the UI, nothing more.

I achieved this with two or three plugins and was quite happy with the results, but then I found that I had problems with executing shell commands and with installing certain software, for instance OpenVPN. Sentinel was blocking certain actions.
At the beginning I didn't think this was related to WindHawk at all... Sentinel never reported any problem related to the WindHawk itself.

What you suggest about excluding all processes and including only the ones I need seems promising, although I'm not sure if I want to risk bricking my system again, should anything go wrong. I'll think.

Maybe the default WindHawk setting should be to exclude everything and the plugins should publish their inclusion lists in their documentation?

I was also thinking that the problem could be reported to Sentinel for analysis. Maybe they could do something about it?

[m417z]

The reason for injecting code into all processes is to be able to intercept the creation of new processes, and load mods before a new target process starts running.

Maybe the default WindHawk setting should be to exclude everything and the plugins should publish their inclusion lists in their documentation?

I addressed this in a recent release blog post. I agree that it's not ideal, but it's tricky to find a balance between compatibility and functionality that works for everybody.

[dimateos]

I was affected by this, although I first found #198 and used the inclusion/exclusion list to fix it...
It took me a few hours to realize windhawk could be the issue, in my case there was no antivirus reports but some scripts were seemingly doing nothing (probably blocked by antivirus but silently?)

TBH I'm only interested in mods for the taskbar/explorer too, and my guess is that is the case for most users.
I get your point about a bad user experience when a mod does not work out of the box but injecting to ALL processes still feels like an overkill with potential unforeseen issues: antivirus, anticheats...

⚠️ For me a worse user experience is having windhawk being injected in all processes without a warning/info in the website/app (like under the featured mods). I naively assumed that given the @include target those were the only touched processes.
Also it wasn't easy finding about this online and then searching for the setting inside two layers of settings.

Since every mod explicitly states the process it wants to modify, why can't Windhawk just compile a superset of those and only inject to them? That's actually how I thought it works, just like Browser-Extensions tell you which sites they want to have access to and the Browser makes sure they can't access anything else.
@Plunts #198 (comment)

^ Apart from giving the users a warning for now, I think this should be the way to go.

• Join all @include targets, if there are no wildcards etc then only target that subset.
• If some complex mods also require to be injected in all/early processes to "be able to intercept the creation of new processes, and load mods before a new target process starts running" those could have a new tag @permissions injectAll injectEarly ... or something in the header like a manifest.
  • Then if you have one of those in your set of active mods, target all you need and inject as early as you can Early injection helper #197
  • But some sets of simple mods may not need it e.g. my current mods work perfectly with only "explorer.exe" being targeted.

Then based on the active mods:

• Ask the user for a windhawk restart if necessary
• I would even keep a warning in the home tab when the current set of mods require the injection in ALL processes
  • Similar to the "SAFE MODE" warning, but to notify potential incompatibilities.
• Or the other way around: have a setting (not buried inside advanced settings) to disable the injection to ALL processes and a warning to inform the user that this current setting may impact some mods. Probably makes more sense at this point, if the user is properly informed about the current early/all injection need before using the software.
  • Basically the same as "SAFE MODE" but with limited injection? could be "LIMITED MODE"...
  • ⭐ Maybe, right now, this is the simplest addition that could address the frustration I had with my initial user experience.
  • Then the following step could be the procedure I mentioned before: detect when set of active mods can be run with "LIMITED MODE" and do so automatically (without a warning or a different text, even if the setting is set to off, etc)

---

Anyway that was long... thanks a lot for you efforts in Windhawk, the few mods I use are very nice!

Just wanted to share my opinion on the current default injection and the frustration about the lack of a warning :)
BTW I can open a separate issues or whatever you prefer: warning info / simpler injection for simple mods

[RobbyMeeker]

The reason for injecting code into all processes is to be able to intercept the creation of new processes, and load mods before a new target process starts running.

Maybe the default WindHawk setting should be to exclude everything and the plugins should publish their inclusion lists in their documentation?

I addressed this in a recent release blog post. I agree that it's not ideal, but it's tricky to find a balance between compatibility and functionality that works for everybody.

Have you given any thought to adding a toggle in advanced settings to enable an injection whitelist mode instead of blacklist? Seems like that would help the people who care enough to dig through settings, and wouldn't bother the normal folks. Not a perfect solution but a good band-aid imo.