F1-Local

Seems ironic that the AMD processors are the ones suffering from the Microsoft patches to the CPU vulnerabilities that aren't supposed to affect AMD......

You make an interesting point regarding Microsoft's end strategy, however, what are AV vendors 'signing up' to when deciding to add the registry key? Are they effectively 'saying' that they do NOT bypass the KPP - that the doublepulsar.com talks about? Do some AV products actually bypass the KPP? If they do and this practice does cause stability problems with future Microsoft patches (for Meltdown and Spectre) why wouldn't Microsoft just let it happen and have a field day in the press when it occurs and they get to blame the AV vendor(s) for 'dodgy' practices? The bad press would surely cause massive damage to the AV Vendors at that stage, if Microsoft control the narrative? I guess, if a vendor adds the registry key knowing that their product does bypass the KPP, Microsoft potentially have a stronger hand if system's become unstable in the future - by accusing AV vendors of false claims regarding product compatibility? A more subtle (and legal approach) I presume? Are Microsoft imposing these conditions on other rival software or hardware vendors where they share the market? Interesting times...

I tried installing KB4056894 stand-alone and it failed to install and caused a BSOD on restart. Identical behaviour as when installed via WU in the monthly rollup. I then removed ESET from the laptop and installed KB4056894 stand-alone again. Same result and BSOD on restart, confirming it has nothing to do with ESET. No need to submit any memory dumps to you now! From the MS page on KB4056894... https://support.microsoft.com/en-gb/help/4056894/windows-7-update-kb4056894 ...it appears that they have updated advice and have themselves stopped the update rollout to affected AMD devices. I guess this overrides the installed registry key? Q1. Is the registry key merely a simple 'green light' for the MS code to deliver KB4056894 (and all subsequent MS patches)? Or does it have any other impact on the system? Q2. By adding this registry key, are AV vendors effectively saying that their software does NOT bypass Kernel Patch Protection and is therefore compatible? Q3. I assume that an AV product that DOES patch the kernel could possibly cause problems with subsequent MS patches for Meldown and Spectre CPU vulnerabilities - as described in the doublepulsar article above (...changing memory locations etc.)? Q4. What if a PC has NO AV installed, are MS not delivering any new patches to these PCs? Will manually adding the registry key allow future MS patches? Thanks for your patience!

Thanks, I have it downloaded and will try it in the morning.

On further reading (after my second post) I've now realised the minor role that AV vendors play, but thanks for the confirmation. I did read one forum where a user experienced the associated BSOD on their Intel Core i7 machine, hence that's why I'm keen to look at my Intel PCs. This BSOD issue is fairly new, is it likely all CPU types have been isolated? That said, I would expect to see more reports of Intel based systems suffering - by the law of averages. Given that you say that the fault is nothing to do with ESET, is it still OK to submit a memory dump to you, as suggested by Marcos? Do you only need the memory dump prior to the update installing? Mike

Marcos. Since my post, I checked the registry file and the key that Microsoft recommend being installed is clearly showing - hence the delivery of KB4056894 I guess? I will follow your instructions in ESET kb380 on the laptop with the BSOD and try and get the data to you if it helps determine the likely cause of the fault, hopefully not ESETs! I will apply the SP on other PCs of mine to see if I can replicate the problem on Intel CPU systems. I guess I may be getting a lot of phone calls in the coming days.... Many thanks Mike

Hi, I've just repaired a Dell Inspiron laptop (Windows 7 Home Premium 64-bit, AMD Turion X2 DC Mobile RM-74 2.20 GHz) that suffered a STOP 0x000000C4 BSOD message on each Windows restart attempt, with no access to any safe modes, I found a fix online... https://answers.microsoft.com/en-us/windows/forum/windows_7-update/stop-0x000000c4-after-installing-kb4056894-2018-01/f09a8be3-5313-40bb-9cef-727fcdd4cd56?auth=1&rtAction=1515190079156 ...that suggested removing the KB4056894 patch using the dsim command from Windows 7 recovery environment. This fixed the blue screen on re-boot. I've now disabled it's re-installation within the Windows Update settings. On further reading... https://support.microsoft.com/en-gb/help/4056894/windows-7-update-kb4056894 it appears that this fix is only applicable (installed?) to PCs "where the Anti virus ISV have updated the ALLOW REGKEY.". According to the ESET forum page on the Meltdown + Spectre CPU vulnerabilities... https://forum.eset.com/topic/14274-esets-response-to-meltdown-and-spectre-cpu-vulnerabilities/ ...ESET have released module update 1533.3 - "to ensure compatibility with Microsoft's updates to the Windows operating systems". The laptop, while running ESET Smart Security version 8.0.316.0, does have module 1533.3 installed. Q1. Is KB4056894 anything to do with patching Meltdown/spectre CPU vulnerabilities? Q2. If so why does the laptop with module 1533.3 installed suffer the BSOD on restarts? Q3. Will this occur on all my client PCs when KB4056894 is automatically delivered over the next days/weeks? Thanks in advance PS: To double check the error, I repeated the KB4056894 install via WU and it resulted in the same BSOD - just in case the ESET module 1533.3 was not installed prior to the Windows update first occurring (last week). Mike