cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

@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)...

Highlighted

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

@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

Michael
Highlighted
Level 10
Report Inappropriate Content
Message 163 of 332

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

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.

Highlighted

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

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.

Michael
Highlighted
Level 10
Report Inappropriate Content
Message 165 of 332

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

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.

Highlighted
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 166 of 332

Re: Windows Defender problem reported by MICROSOFT

Jump to solution
@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.

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

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...

 

 

Highlighted

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

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.

Annotation 2019-10-14 094317.pngAnnotation 2019-10-14 094415.png

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... 

Annotation 2019-10-14 095038.png

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...

Highlighted

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

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.

Michael
Highlighted

Re: Windows Defender problem reported by MICROSOFT

Jump to solution

@chealey

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

Michael
You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community