Replies

I’ve started a thread on this issue on the McAfee ENS forum:

https://community.mcafee.com/t5/Endpoint-Security-ENS/Outlook-2016-and-chart-dll-error/m-p/651239

Let’s see if other corporate users are having the problem.

1 user thanked author for this post.

D Hensley

Further to my Twitter comment, we support a few thousand PCs running Mcafee ENS 10.6.1 and 10.7. My PC is one of the few which has the Feb build of ENS 10.7, and I think that I’m the only one who who has seen it (I’ll check with my desktop support colleagues tomorrow). If it’s only ENS users seeing it, build numbers could be important.

Phil

2 users thanked author for this post.

D Hensley, woody

[philrandal]

We saw it too on a bunch of 2012 (not R2) servers.  The Safe Mode boot worked for us.

• This reply was modified 5 years, 5 months ago by philrandal.

They need to get rid of the brownie points / reputation flagging.

The end result of such schemes on the technet forums was point-seeking dimwits copy-paste spamming the same inaccurate unhelpful garbage all over the forums.

2 users thanked author for this post.

LoneWolf, woody

Seen that here as well.

For the moment I’ve unapproved those updates in WSUS

columbia2011 wrote:

The .NET Update is available by manual download only via Microsoft Update Catalog.

WSUS has a facility to check patches in from the update catalog(ue).  That’s what I was referring to.

Released to the update catalog, but not to WSUS.

Manual downloads (and / or manual checkin to WSUS) required.  Why?

Also,  in the KB articles for some of the updates: “We recommend that you exit all .NET Framework-based applications before you apply this update.”

Microsoft really haven’t got a clue, have they?

The “fixes” for the July .NET updates are out:
https://blogs.msdn.microsoft.com/dotnet/2018/07/30/net-framework-july-2018-update/

You have to manually download or check in to WSUS.

And asking us to close all .NET apps before applying?  Cripes, Microsoft

Microsoft released an updated .NET patch yesterday.  Not sure if it is metadata only.

 

Phil

Mele20 wrote:

WhooWeee! Back to normal!…well not completely..the new cert expires in THREE MONTHS? Why is that? The cert is NOT HSTS according to Qualys ever a problem again. (But then I don’t think the expired cert was HSTS as it was not in my SiteSecurityServiceState.tx file in my Fx profile).

HTBridge’s ssl checker repors a weak Diffie-Hellman parameter:

https://www.htbridge.com/ssl/?id=ZQ6FWeVA

 

The metadata updates seem to have fixed the problem

KB4088881 causes the same crashes as KB4088875/8 on Windows 2008 R2 Terminal Servers, alas

1 user thanked author for this post.

MrBrian