Environment:  Windows 7 Professional SP1 64-bit, .NET 3.5.1, 4.5.2, SEP 14 MP2

Has anyone noticed any issues with the 2018-01 .NET Security Only Update (or the 2018-01 .NET Rollup)  specifically KB4054172 which is the security patch containted the the 2018-01 .NET Security Update, et. al.?   https://support.microsoft.com/en-us/help/4055269/security-only-update-for-net-framework-3-5-1-4-5-2-4-6-4-6-1-4-6-2-4-7

We don't know as of yet if it impacts SEP 14 MP2.  There is language in the Microsoft KB4055269 referencing the registry entries to be provided by the antivirus vendor similar to that needed to install the Meltdown/Spectre patch in the Windows 2018-01 Security Only (and rollup) for Windows.  We are assuming that the potential is there to cause issues with the .NET patch like the Windows Meltdown/Spectre patch(es).

The current issue that we have specifically is that after installing KB4054172 a machine won't successfully RESTART.  It will go through Logoff and Shutdown and then go dormant, like it was in Sleep mode, but unable to wake up.  The only way to revive a machine is to manually power it off and back on.  We've checked the KB4054172 install logs and don't see any installation errors.

We are unaware of any SEP issues at this point.  We stopped pushing out the .NET maintenance until we can figure out what's going on.

KB4056897 containing the Meltdown and Spectre patch is installed with no apparent issues, SEP 14 MP2 or otherwise.

***************************************

3/6/2018 update -   The RESTART issue is not related to either SEP or KB4054172.    It is related to the January, 2018 Security update - either KB4056894 or KB4056897.  This may not be the appropriate place to post this, but we do want to share our experience as this is a problem with an obscure workaround.    It appears to affect Windows 7 Professional SP1 64-bit machines with older CPUs - i.e. Gen 3 Ivy Bridge and others.   The workaround it to disable all or part of the Intel C-state feature in the affected machine's BIOS.     After that the system will RESTART normally to allow Windows maintenance to be successfully installed. 

Here's a link that describes the workaround that others have used.  https://answers.microsoft.com/en-us/windows/forum/windows_7-performance/windows-7-hangs-on-reboot-after-applying/ea13e25f-f41c-4067-93c0-f249857ed018?auth=1 . 

Disclaimer - use at your own risk.  

Patches will not be detected as applicable if reg keys are not present, all the AV vendors verified their compatabilty and updated the reg key via defs,

Microsoft Software Update release for January 2018

https://support.symantec.com/en_US/article.INFO4782.html

See our 3/6/18 update in the problem description above.  We acknowledge that that may not be the appropriate venue for this post, but hopefully it will save someone a lot of time trying to debug this issue.   The workaround is somewhat obscure.

The RESTART issue is not related to either SEP or .NET.   It is related to the 2018-01 Windows security patches, either KB4056894 or KB4056897.  The affected systems are running Windows 7 Professional SP1 64-bit on older machine with Intel Gen3 Ivy Bridge processors and others.  The workaround that seems to consistently work is to disable all or part of Intel C-state in the machines BIOS settings.  That will allow the system to successfully restart after applying maintenance with out any manual intervention.

https://answers.microsoft.com/en-us/windows/forum/windows_7-performance/windows-7-hangs-on-reboot-after-applying/ea13e25f-f41c-4067-93c0-f249857ed018?auth=1
 

Disclaimer:  Use at your own risk.  Test thoroughly.

Hi Folks,

To add to Rafeeq's comment, I have just spent almost the last 4 days banging my head on a Windows Update issue that related to the above registry key.  I was going to raise this as an informational post to all, but it seems to fit here.

While looking at deploying this months Windows security updates from WSUS, a noticed a bunch of servers not showing any updates available.  Plenty of other servers were showing the correct updates being available.  VERY strange.

Initially I thought this was a mix of SEP and non-SEP Windows machines, but further checks showed only those systems without SEP were detecting zero updates.  I ran several of the problem systems via proxy so they could get to the Windows Update site to see the difference.  Well bugger me - the only important update detected from the Windows Update site was the Malicious Software Removal Tool - none of the important security patches.

The WindowsUpdate.log showed nothing out of the ordinary, and also showed it was indeed detecting zero updates from WSUS.  I ran through the normal processing of resetting WSUS components on several servers - stil no joy.  A couple of the systems showed some component corruption with SFC /scannow so I cleaned these up with Dism.exe - still no joy.

Then it dawned on me that all the problem systems did NOT have SEP installed.  I tested this by installing SEP on one of these systems...magically WSUS updates are working correctly again.  I then took another problem system and instead of installing SEP, I just added the registry key and value as described in the link Rafeeq posted (as well as KB4056898).  Magic - this works too, although that key is only supposed to be added by AV vendors when needed.

Nowhere in the Microsoft article does it say all security updates will stop working without this registry setting.  After solving this issue by myself (Google was no help with this particular problem), I checked the Endpoint Protection forum to see if anyone else was reporting it and found this post.  I re-read the article Rafeeq linked to above (I had skimmed it previously), and found that this is mentioned in one bullet point under the side effects:

• If the managed end-point has no AV software the registry key check detailed above will fail and the updates will not target

The article also says that you should NOT create the registry entries if there is no AV installed as you may end up with a BSOD.  In my case, I've proved that it can be done, but test and do it at your own risk.  I've done this with Server 2008 R2 64-bit and Server 2012 R2 64-bit (all VMware VM's) with no issues (although those servers are now getting AV installed).

Hope this helps someone,

Steve