Finally, a fix for Microsoft’s draconian block on Win7 updates for recent processors

Topic

New Reply

Remember Microsoft’s not-so-subtle hint that it won’t support Win7 on newer processors? Remember how the April security and Monthly Rollup patches kno
[See the full post at: Finally, a fix for Microsoft’s draconian block on Win7 updates for recent processors]

Reply | Quote

Replies

Woody

I know that we are still at MS Defcon   2 .  I am running Windows 7 and got my updates today. I have two updates one of them is the Windows Malicious Software Update.

In the past you said it was OK to run that update, but to hold off on the rest of them.

I would like to know if that is still the case or should I hold off on that one also until I get the word and you change the MS DEfcon level to update .

If this is the case and it is OK to update that one only if that will always be the case or not.

Thanks

Sam

 

Reply | Quote

You can run the MSRT any time it appears. But realize that it almost never does anything. Personally, I don’t worry about it until I install the whole month’s patches.

2 users thanked author for this post.

HiFlyer, Sam

Reply | Quote

The Intel Xeon (E3 v6) unwanted blocking on Windows Server 2012 R2 has also been fixed in the relevant June 2017 monthly rollup and also security-only update. Source: https://support.microsoft.com/en-us/help/4019215.

The AMD Carrizo DDR4 blocking issue also occurs for Windows 8.1 and Windows Server 2012 R2, and is also fixed by the relevant June 2017 monthly rollup and also security-only update. Source: https://support.microsoft.com/en-us/help/4019215.

1 user thanked author for this post.

woody

Reply | Quote

Thanks Woody If it’s good enough for you then it’s good enough for me. I ll wait until you give the word to go ahead with the updates.

Reply | Quote

Took them long enough to do something simple ask remove the block.

Reply | Quote

If they weren’t trying to block updates in the first place then this never would have been a problem. But I do agree, It took them way too long to fix this issue. Say for Ryzen and Kaby Lake and any future chips couldn’t you theoretically uninstall the rollup each month and install the new rollup? Like say for example I have a Ryzen chip. If I uninstall the June rollup wouldn’t that unblock updates and then allow to install the July rollup?

Reply | Quote

That method has been discussed here and in several other topics on this site.

3 users thanked author for this post.

HiFlyer, woody, MrBrian

Reply | Quote

Gees simple DLL changes got you back to normal two minutes after the “Kaby Kill Update” was installed two months ago.

Reply | Quote

Just to alert readers, KB-4022719 breaks iframe printing from Internet Explorer.

Edit to remove HTML

Reply | Quote

Does https://github.com/zeffy/wufuc modify files on disk or just in memory?

Reply | Quote

It uses an injection technique to patch wuaueng.dll ‘on the fly’, no Windows files are modified:

“How it works

At system boot the wufuc scheduled task runs as the NT AUTHORITY\SYSTEM user.
wufuc determines what service host group process the Windows Update service runs in (typically netsvcs), and injects itself into it.
Once injected, it applies a hook to LoadLibraryEx that automatically patches wuaueng.dll when it is loaded.
Any previously loaded wuaueng.dll is also patched.

Several improvements over my batchfile method:

No system files are modified!
Heuristic-based patching, which means it will usually keep working even after updates.
C is best language.
No external dependencies.”

1 user thanked author for this post.

Hugo

Reply | Quote

anonymous wrote:

Does https://github.com/zeffy/wufuc modify files on disk or just in memory?

The original patch in April modifies the necessary files to achieve the “unblock”, but now it seems that the new version of the patch does the patching “on the fly” so that no system files on disk are actually modified.

I will do a test on my VMware Kaby Lake virtual machine later to see if the new patch works.

Hope for the best. Prepare for the worst.

Reply | Quote

James Bond 007 wrote:

I will do a test on my VMware Kaby Lake virtual machine later to see if the new patch works.

I have confirmed that the new patch appears to do what it said will do.

(1) I installed KB4022719 (Windows 7 June Rollup) on the Windows 7 Kaby Lake virtual machine and rebooted it.

(2) I launched Windows Update and instructed it to check for updates. The “Unsupported Hardware” message immediately appeared and Windows Update eventually gave the error 80240037.

(3) I installed the wufuc patch by running install_wufuc.bat as administrator, and as a precaution restarted the VM.

(4) I launched Windows Update and instructed it to check for updates. This time Windows Update proceeded to give me a list of updates and I was able to install the May .NET Rollup KB4019112 from Windows Update.

(5) I then uninstalled the wufuc patch by running uninstall_wufuc.bat as administrator, and restarted the VM. Launching Windows Update and instructing it to check for updates immediately generated the “Unsupported Hardware” error message.

Hope for the best. Prepare for the worst.

Reply | Quote

The accidental WU incorrect CPU block fix looks to have been done via changes in the WU related DLL’s .  For Windows 7 after the June 2017 Sec Only or Rollup installs all 8 WU related DLL’s

wu.upgrade.ps.dll
wuapi.dll
wuaueng.dll
wucltux.dll
wudriver.dll
wups.dll
wups2.dll
wuwebv.dll

have been changed to version 7.6.7601.23806.

If you had previously killed the Kaby Lake block, by whatever method you used, these new DLL’s will certainly re-instate the Kaby Lake, and possibly add a Skylake, CPU WU block for these CPU’s when used with Windows 7.  You will need to repatch or roll these DLL’s back (copy over actually) to tha Kaby Lake friendly, Pre-April WU, version 7.6.7801.23453 to kill the Kaby update block again.

Viper

 

Reply | Quote

I tried this method on 7 July 2017, to unlock a Kaby Lake Intel CPU: It doesn’t work.

Reply | Quote