Windows Defender problem reported by MICROSOFT

[billmoller]

@chealey, I tried to re-open my support case on the McAfee website, but it indicates:

---

This Service Request is closed.

To reopen this Service Request, please contact your McAfee support technician.

---

So, following the instructions, I reply to any email sent to me by my support technician, and immediately receive an auto-response email indicating:

---

This is a system-generated message in response to your email about SR # <4-20058973171>. This service request is currently closed and this e-mail is not being monitored.
Please do not reply to this email.

---

So... I had to create a new SR 4-20381580551 which exists only to tell McAfee to re-open SR 4-20058973171.

Perhaps the re-opening SR process could be reviewed as well...

[JayMan]

I had the same 'unmonitored' reply... So create a new case... Then later got an email saying 'we've received your request to open the case, so we have now loaded a new case for you...

So although it says it's unmonitored, clearly it's not completely true hah

[chealey]

@billmoller I've reopened your old case. Please upload the originally requested data to your old SR so we can re-engage engineering. 

Upon closure of a case, the emails are no longer monitored however some do get through and are picked up. As a general policy we advise that customers should call to reopen a case or as you've done, you can raise a new SR, asking for the old one to be reopened.

[meanoldmanning]

@billmoller  Just out of curiosity if your systems are managed by ePO change the policy under Endpoint Security Common > Options  that applies to your test computers so that debug logging is enabled. If you change the setting locally and not in that ePO policy then a policy refresh will set it back to whatever is defined in the ePO policy. 

Now, all that said, debug logging still should not be the fix. 

[billmoller]

@meanoldmanning, I've been able to force productState to 397312 in the past by turning debug logging on, but even then, after an update, it would eventually go back to 393232...

Just after reading your post, and before I was about to enable debug logging again, I checked the productState.

After doing literally nothing this morning (except letting an ASCI interval naturally pass/process by checking agent log), the productState changed from 393232 (BAD) to 397312 (GOOD), and it's "working" now...

I'm in the middle of a long operation, and will attempt a reboot soon.

[meanoldmanning]

Pretty frustrating, huh? I'm waiting for the fellow assigned to my case to reply to my updates on my ticket about what I have found so far. As I have stated above, I have tried a few different scenarios so far on 4 different laptops and all have wound up needing to have debug logging enabled eventually to appear to function correctly.

[meanoldmanning]

Oh boy! 4 AV products listed! Now ENS is listed 3 times!

This is on a test computer that had the PoC installed then had the October Update installed over the top of it, so no telling what kind of a mess this system is

PS K:\> get-wmiobject -namespace "root\securitycenter2" -class "antivirusproduct"

__GENUS                  : 2
__CLASS                  : AntiVirusProduct
__SUPERCLASS             :
__DYNASTY                : AntiVirusProduct
__RELPATH                : AntiVirusProduct.instanceGuid="{1006DC03-1FB1-9E52-7C81-F2FAB48962E3}"
__PROPERTY_COUNT         : 6
__DERIVATION             : {}
__SERVER                 : PC----P
__NAMESPACE              : ROOT\securitycenter2
__PATH                   : \\PC----P\ROOT\securitycenter2:AntiVirusProduct.instanceGuid="{1006DC03-1FB1-9E52-7C81-F2FAB
                           48962E3}"
displayName              : McAfee Endpoint Security
instanceGuid             : {1006DC03-1FB1-9E52-7C81-F2FAB48962E3}
pathToSignedProductExe   : C:\Program Files (x86)\McAfee\Endpoint Security\Threat Prevention\AMCFG.EXE
pathToSignedReportingExe : C:\Program Files\McAfee\Endpoint Security\Threat Prevention\mfeensppl.exe
productState             : 397312
timestamp                : Tue, 08 Oct 2019 18:10:27 GMT
PSComputerName           : PC----P

__GENUS                  : 2
__CLASS                  : AntiVirusProduct
__SUPERCLASS             :
__DYNASTY                : AntiVirusProduct
__RELPATH                : AntiVirusProduct.instanceGuid="{D68DDC3A-831F-4fae-9E44-DA132C1ACF46}"
__PROPERTY_COUNT         : 6
__DERIVATION             : {}
__SERVER                 : PC----P
__NAMESPACE              : ROOT\securitycenter2
__PATH                   : \\PC----P\ROOT\securitycenter2:AntiVirusProduct.instanceGuid="{D68DDC3A-831F-4fae-9E44-DA132
                           C1ACF46}"
displayName              : Windows Defender
instanceGuid             : {D68DDC3A-831F-4fae-9E44-DA132C1ACF46}
pathToSignedProductExe   : windowsdefender://
pathToSignedReportingExe : %ProgramFiles%\Windows Defender\MsMpeng.exe
productState             : 393472
timestamp                : Wed, 09 Oct 2019 15:22:44 GMT
PSComputerName           : PC----P

__GENUS                  : 2
__CLASS                  : AntiVirusProduct
__SUPERCLASS             :
__DYNASTY                : AntiVirusProduct
__RELPATH                : AntiVirusProduct.instanceGuid="{9D4501E6-72F6-2877-C789-89AF6F535B2C}"
__PROPERTY_COUNT         : 6
__DERIVATION             : {}
__SERVER                 : PC----P
__NAMESPACE              : ROOT\securitycenter2
__PATH                   : \\PC----P\ROOT\securitycenter2:AntiVirusProduct.instanceGuid="{9D4501E6-72F6-2877-C789-89AF6
                           F535B2C}"
displayName              : McAfee Endpoint Security
instanceGuid             : {9D4501E6-72F6-2877-C789-89AF6F535B2C}
pathToSignedProductExe   : C:\Program Files (x86)\McAfee\Endpoint Security\Threat Prevention\AMCFG.EXE
pathToSignedReportingExe : C:\Program Files\McAfee\Endpoint Security\Threat Prevention\mfeensppl.exe
productState             : 397312
timestamp                : Tue, 03 Sep 2019 16:53:33 GMT
PSComputerName           : PC----P

__GENUS                  : 2
__CLASS                  : AntiVirusProduct
__SUPERCLASS             :
__DYNASTY                : AntiVirusProduct
__RELPATH                : AntiVirusProduct.instanceGuid="{A37DD4B2-BDFF-70DA-DE19-9F9927D6940F}"
__PROPERTY_COUNT         : 6
__DERIVATION             : {}
__SERVER                 : PC----P
__NAMESPACE              : ROOT\securitycenter2
__PATH                   : \\PC----P\ROOT\securitycenter2:AntiVirusProduct.instanceGuid="{A37DD4B2-BDFF-70DA-DE19-9F992
                           7D6940F}"
displayName              : McAfee Endpoint Security
instanceGuid             : {A37DD4B2-BDFF-70DA-DE19-9F9927D6940F}
pathToSignedProductExe   : C:\Program Files (x86)\McAfee\Endpoint Security\Threat Prevention\AMCFG.EXE
pathToSignedReportingExe : C:\Program Files\McAfee\Endpoint Security\Threat Prevention\mfeensppl.exe
productState             : 397312
timestamp                : Thu, 10 Oct 2019 14:09:57 GMT
PSComputerName           : PC----P

[billmoller]

• productState was 397312 (GOOD)
• I rebooted
• productState still 397312 (GOOD)
• within 3 minutes, productState is changed to 393232 (BAD)
• Issue returns...

I'm fairly certain that ENS is setting the productState (and WSC is getting the productState), therefore... ENS is improperly reporting that it is off and out of date and WSC is properly starting WDA in its place...

What a cluster...

[meanoldmanning]

@billmoller 

When it switches back to 393232 if you look at the Settings > Common > Advanced is Debug Logging still enabled or has it toggled back off? Or had you not enabled it to begin with?

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