think windows update is a mess on fresh install update tries to install drivers not related to my hardware glad I have Driver Store Explorer handy
Can someone enlighten me as to how the 19042.928 KIR is pushed-down to customers? My Windows Update service was "disabled" and "not running" before and after the KIR was applied. All I had to do was boot my machine while it was connected to the internet. So how is this KIR channeled to customers? The following keys are added after the Known Issue Rollback is applied to 19042.928: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\1837593227 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\194121355 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\4071209099 Spoiler: Before KIR Spoiler: After KIR
I just installed the .962 LCU after the Known Issue Rollback (KIR) was applied to v.928. So the .962 LCU doesn't reinstate the fixes that the KIR rolls back from .928. It will take an LCU later than .962 to reinstate the .928 fixes that were rolled back by the KIR.
In reference to gaming issues with the .906 and .928 LCUs to 1904X, how long do you think it is going to take for someone to figure out how to exploit the Known Issue Rollback process to distribute malware for Windows 10?
Good question, but I'm not sure we know all the "ins & outs" of the KIR process to say this is even remotely possible. I just learned about this myself and it really looks like that this simply forces the kernel to use a previous code path for a non-security-based fix that was included in an update. From a more technical-ish perspective, from what I can tell if this flag in the registry exists, the kernel knows to execute the old code path rather than the new one that is causing the main issue. My gut says the ID is directly tied to a call out in the kernel code itself, so the only ones that know the correlation here is Microsoft. This doesn't seem to really allow anyone to inject new code but forces an IF condition to use existing code. If malicious code isn't already there, malware authors can't just simply inject it or revert to it using KIR. Granted, that's only a surface level understanding of the process so far. Maybe it will turn out to be less controlled after diving deeper, but I doubt it knowing Microsoft's history on protecting the kernel.
This is what happened that got my attention: I deploy Windows Update Blocker (WUP) to toggle Windows Update on and off. I turn off Windows Update (WU) most of the time. So when you run Windows Update Blocker, it keeps the WU service turned off, even when you reboot. I have a PC that I recently updated to Windows 10 19042.928. Then I turned off Windows Update, and I disconnected the PC from the internet. A few days later, I booted it up while still being disconnected from the internet. I took a screen shot of the part of registry that is affected by the KIR. The PC had been untouched by the KIR. Then I reconnected the ethernet cable to the PC while it was running and rebooted. This time it was booted while being connected to the internet, but Windows Update service was still turned off (disabled). To my surprise, the following regkeys were added while Windows Update service was disabled. \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\1837593227 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\194121355 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\4071209099 My conclusion is that KIR uses a different channel than Windows Update to make changes to the registry. Windows Update service is still turned off!! We know that Windows 10 has other channels for communicating with MSFT. Activation and Windows 10 Lockscreen download are examples. But it was a surprise to see that my registry had been altered while Windows Update was turned off. I didn't even know when the changes had been made to the registry by the KIR.
Interesting. I see what you mean here that the Windows Update Service itself doesn't seem to be the mechanism used to identify and deploy KIRs. I'm not surprised honestly since the entire WU ecosystem relies on more than just the WU Service itself. I wonder if its on purpose in case the KIR is needed to fix something that breaks WU itself.
Today a friend called me about his ancient Q9500, the pc was so slow after installing kb5001330, i said to him to just wait for a fix, but now i remember his gfx card is an nvidia, i only have the onboard gfx card from my intel CPU.