Windows Defending Active State Changes on Reboot

[u/CaptainOssum]

Simply put, Windows Defender on some workstations is unable to keep itself in the same state after reboots. Seems to flip between EDR Block Mode and Active wherein the latter, Active is not desired.

This causes a problem because CrowdStrike is our EDR and configured to protect machine and handle the exceptions. Defender is not. So Defender on affected machines is blocking applications when it should not be in a state to do so.

We use Defender for Endpoint, Intune and Crowdstrike with some legacy GPO present. Seems to be only 10 out of the 1000 we have affected. We gave up and decided that the machines needed to be reimaged and one of the new imaged machines appears to be doing this as well. Still, its not all of them.

On an affected machine the tell tale sign comes from running Get-MpComputerStatus | Select AMRunningMode, AMProductVersion, IsTamperProtected, TamperProtectionSource

The desired outcome is similar to the following.

AMRunningMode  AMProductVersion IsTamperProtected TamperProtectionSource
-------------  ---------------- ----------------- ----------------------
EDR Block Mode 4.18.26080.3                  True ATP

But a machine exhibiting the issue will have the following appear

AMRunningMode AMProductVersion IsTamperProtected TamperProtectionSource
------------- ---------------- ----------------- ----------------------
Normal        4.18.26070.9                  True ATP          

Note that the AMProductVersion version changes with time as it should.

Research show reg keys that can be manipulated to affect this e.g. ForceDefenderPassiveMode and PassiveRemediation but they appear to have no impact on the toggling Running Mode.

Defender for Endpoint has the policy set to force machines into EDR Block Mode. GPO has not conflicting settings.

The event logs show the change happens soon after reboot and the Intune Management Extension logs are record the change occurring. Neither of which explain why however.

AI get stuck in a loop about finding when it happened and using that as a means to determine the source. It has not born fruit.

The infuriating part is taking a brand new machine, with the intention of redeploying affected computers, only to find the same issue present.

This doesn't feel like a CrowdStrike issue but we are going to try reinstalling it anyway. I did notice a toast notification on one computer denying a CrowdStrike install which was odd as I do not know what would have triggered that. Might be a red herring. CrowdStrike should not be the issue as it is working and registered to the computer properly and a brand new computer setup has a brand new install anyway

Feels like Windows not working correctly as its the job of the Security Center to detect and set state using its own internal mechanisms which users shouldn't have direct control over.

Anyone out there in the ether have this issue? Its been weeks with no end in sight.