Windows Defender problem reported by MICROSOFT

[billmoller]

@meanoldmanning, I had never turned debugging back on... I was living with the double-AV, incorrect reporting issue...

It randomly changed to 397312, then randomly broke itself by changing back to 393232...

Previously, when I did have debug logging ON via policy (using the workaround I wrote about) it immediately set 397312, but then eventually switched back to 393232 (even with debug logging still on).

If I were McAfee, I'd:

1. Not add a duplicate ENS AV provider if one already exists
2. Remove duplicate ENS AV providers if more than one is ever encountered (maybe check during an update)
3. NOT REPORT 393232, THAT AV IS OFF AND OUT OF DATE, WHEN IT'S ON AND UP TO DATE...

Seems like a straightforward fix, but apparently not.  (Though I concede I'm making many assumptions that McAfee engineering likely would have more insight into)...

[meanoldmanning]

@billmollerAh, OK. Yeah, basically the only thing that 'fixes' the incorrect reporting issue on my 4 test systems is to enable logging. Obviously that is not the 'solution' as far as I am concerned. And at this point I am concerned that enabling logging to achieve correct reporting is actually masking other potential issues

[JayMan]

Something I hadn’t mentioned yet, on my system I only have 1 ENS listed in the WMI output... have never seen it list multiples for me.

Clearly there is something causing a lot of inconsistencies here.

[meanoldmanning]

That's interesting. All 4 that I have tested showed multiple entries until I ran the script to clear them out.

Tech reached out to me to gather logs today. Unfortunately due to time zone differences it will have to wait until Monday.

[JayMan]

Yeh its strange... Haven't checked the other machines I've got with the issue, but appears that it doesn't really matter anyway

Fingers crossed a true fix will be found... Normally great start for our migration away from VSE.

[SWISS]

@JayMan,

"Fingers crossed a true fix will be found... Normally great start for our migration away from VSE."

This is just a 1% Detail related to the Risk you have with staying on VSE and NOT moving to ENS.

You will have no chance with VSE These days against Ransomware.

You need to 100% get away from VSE on the CLIENTS. The ENS suite can do so much more. You are at 15% with VSE and will go up to 95%. Do not wait. If you talk about ENS on Server that is something else. But we have smaller customer with around 10 server which fully run ENS on it (Citrix, Veeam, Exchange, File and Printserver) and it works JUST fine.

[billmoller]

Left my PC on over the weekend, productState now randomly back to 397312 while AV on-access still ON and... still... up to date...

Rebooting to see if ENS changes the productState to an incorrect value again...

[billmoller]

Exactly as I suspected, there's about a 2-3 minute period of time after a reboot where WSC indicates it's "getting protection info..." and doesn't show any real status.

I assume this is when AV products check themselves and set WMI accordingly.  That's now completed, and ENS has changed its product state back to 393232, a completely wrong productState.  ENS (on-access can) is still ON, and certainly it didn't become our of date during the 3 minute reboot...

---

productState : 393232
timestamp : Mon, 14 Oct 2019 13:44:28 GMT

---

It's like... if ENS actually has an update (updates AMCore or maybe even DATs) then it properly sets to 397312... 

Yesterday, at about that time indicated in the screenshot, is when WMI reports that the product state was set to 397312.

However, if the computer is rebooted, ENS has no clue what's going on with itself so sets productState back to 393232.  What a nightmare...

[meanoldmanning]

I wound up having to collect logs using the MER tool on a test system with debug logging enable and disabled to upload to support.

As stated previously, my test systems still only report 'properly' if debug logging is enable. In that state I can reboot until the cows come home and it still reports properly. That still doesn't feel like an appropriate 'fix' though.

[meanoldmanning]

@chealey

any updates on this? Or are we basically stuck with the October Update being the 'fix'?