Optional updates dont really matter that much.
Security updates is what mainlly matters.
I think there is a certain update you could install manually,
that should fix the long search for updates issue.
But i forgot the exact KB number, i have to look it up.
No problem and thanks for that.
Yeah that's what i thought about the Optional updates.
So it seems that the update blocking aren't affecting only the newest processors.
I have a Z97 motherboard as well which multiboots from Windows 7/8 and Mac and never had any issues retrieving updates on that platform. I highly doubt M$ is blocking updates on that platform.
I have not tested it, but it looks like there is a workaround on github that involves xdelta patching the windows update engine DLL (wuaueng.dl) to bypass the processor detection code.
It is actually just a batch script. Here is the core logic:
net stop wuauserv
takeown /F "%WUAUENG_DLL%" /A
icacls "%WUAUENG_DLL%" /save "%ACL_TEMP_FILE%"
:: Administrators group SID
icacls "%WUAUENG_DLL%" /grant *S-1-5-32-544:F
move "%WUAUENG_DLL%" "%BACKUP_FILE%"
"%XDELTA3_EXE%" -d -s "%BACKUP_FILE%" "%DELTA_FILE%" "%WUAUENG_DLL%"
if errorlevel 1 (
set "THERE_WAS_AN_ERROR=%errorlevel%"
move /Y "%BACKUP_FILE%" "%WUAUENG_DLL%"
)
:: "NT Service\TrustedInstaller" SID
icacls "%WUAUENG_DLL%" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
icacls "%SYSTEM32_DIR%" /restore "%ACL_TEMP_FILE%"
net start wuauservSo stop Windows Update service, take ownership of the file, patch it, restore permissions and then start WUS again. There's some error detection to improve reliability as well. The .bat could easily be modified to make patching automatic instead of requiring user input since it soft-fails.
So... maybe running the code in a .bat every time the computer starts up would negate the existence of KB4012218 in a way that is transparent to the end user?