cancel
Showing results for 
Search instead for 
Did you mean: 

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

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
JayMan
Level 10
Report Inappropriate Content
Message 163 of 320

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.

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
JayMan
Level 10
Report Inappropriate Content
Message 165 of 320

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.

Reliable Contributor SWISS
Reliable Contributor
Report Inappropriate Content
Message 166 of 320

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.

Highlighted

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

 

 

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

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

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
More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • 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