[German]Since August 21, 2019, Microsoft has been testing the KB4512941 cumulative update for Windows 10 Version 1903 with insiders. However, the update causes a high CPU load on a core on some systems.
Update KB4512941: What’s the problem?
Cumulative update KB4512941 is intended to fix some issues in Windows 10, version 1903. Among other things, it is planned that this update will finally fix the issue of the broken sandbox (see my blog post Windows 10 V1903: Update KB4497936 breaks Sandbox).
Microsoft is currently testing this update with Windows insiders only – the first version was released on August 21, 2019. Users who installed the update reported that the search did not work anymore. In addition, Cortana causes a high load on a CPU kernel for some people. I had also reported about this issue within my blog post Windows 10 V1903: Updates KB4512941 and KB4515530. Within this blog post I sketched a workaround (a .reg file to enable Bing search and disable Cortana) that has reduced some people’s core load.
Cause found: Scripts and Cortana Cache
German blog reader Werner B. contacted me 2 days ago by mail and gave me some interesting hints (thanks for that). Werner wrote:
I am a reader of the Windows blog and would like to share some information about a workaround to 100% Cortana CPU load on Windows 1903 KB4512941.
Werner refers to my above mentioned blog post Windows 10 V1903: Updates KB4512941 and KB4515530 where I discussed the high CPU load. During his research, Werner came across a post in the Tenforum that picks up the problem or the cause for the high CPU load. There it says:
Kek. I found what causing problem to Cortana by myself.
The problem is somewhere inside
Some scripts cause loop and Cortana is stuck on initialization as I see through Proccess Monitor logs.
The issue seems to be connected to the cache folder used by Cortana, which causes the high cpu load.
With the above knowledge one could now simply say: Ok, I clear the cache and it’s fixed. Unfortunately this won’t help, because the cache will not be rebuilt if it is deleted or a new cache is created. But there is a workaround that the user has outlined in his comment:
Inserting the folder from prev.version works fine insead of black search window
Btw, looking of meaning “cache”, the folder is not recreated / regenerated by itself after delete
Folder saved from backup of 362.295 build (as I remember): cache.rar – Google Drive
German blog reader Werner confirmed to me that this workaround had helped him:
In a local fresh test installation of 1903 in VMWare the CPU load goes to 100% after installation of KB4512941.
If the cache folder is backed up before installing KB4512941 and the folders are copied back after the update, the CPU load of Cortana (immediately without reboot) goes to 0%.
Werner suggests the following steps to fix the high CPU load issue with update KB4512941:
1. Before installing the KB4512941 update, back up the following cache folder to a local directory (e.g. D:\Backup):
2. Then install the cumulative update KB4512941 and the SSU.
3. After the update installation, open the cmd.exe command prompt by Run as administrator and execute the following command.
xcopy /o /x /e /h /k D:\backup\cache\*
Here I assume that the path to the backed up cache folder is cleanly adjusted with the second command. The xcopy query j/n/ must be confirmed with ‘a’ (for all). Maybe the workaround is helpful for you and Werner asks if someone can confirm the workaround.
Werner sent me the following additional information in the aftermath of the article.
The workaround works with the affected Windows country setting “de-de”, regardless of whether Cortana / Bing search was activated or deactivated by OO Shutup10.
A limitation of the manual overwriting of files in ‘SystemApps’ is that “sfc /scannow” detects and resets the change, whereupon the Cortana bug with high CPU load occurs again.
The cache files of Cortana themselves should not be the sole cause of the error. There is no high CPU load at build 18362.327 if the KB4512941 is directly integrated into an April ISO with 18362.30 using DSIM.
A new installation with such an ISO works without problems. One of the benefits of build 18362.327 is that programs compiled with VisualBasic 6 will work again.
Then there was a hint from Werner about installations where the ‘cache’ folder workaround is active:
Installing install.wim from an ISO with integrated KB451294 (which works for new installations) does not fix the cause of the Cortana bug.
( DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim /LimitAccess).
With ‘sfc /scannow’, the cache data that works on freshly installed systems, but which have been updated step by step through the monthly updates, will become active again and lead to the Cortana bug..
Werner concludes: “There may be a way to bring existing systems up to build 18362.327 without a workaround. Thanks for the addition.
Note: Read also my article Windows 10 V1903: High CPU load from Cortana, Search broken, blame August 2019 Updates dealing with the final version of this update.
Addendum 2: I’ve written a brush up with findings reported from my blog readers – and an addendum from Werner – at Windows 10 V1903: MS investigating the Search/Cortana issue (09/03/2019). There you will find also a confirmation, that Microsoft is investigating the issue and plan a fix in upcoming releases.
Windows 10 V1903: Update KB4497936 breaks Sandbox
Windows 10 V1903: Updates KB4512941 and KB4515530
Windows 10 V1903 Update KB4512941: Workaround for the Cortana high CPU load issue
Windows 10 V1903: High CPU load from Cortana, Search broken, blame August 2019 Updates