Idle CPU usage ~40% after update to 1803

vanished · June 10, 2018

It's definitely fixed now. I don't believe it, this is finally over

The solution was to kill that process I mentioned. Foolishly however I didn't write down the name, and strangely it hasn't returned after a reboot. All I know is it was WMI(something).exe and had something about throttling in the description. Maybe @GoodBytes knows?

Whatever it is, it should not exist. Whoever made that should be fired and prohibited from ever writing software again.

Thanks for the tip about procmon. In theory I could have spotted this just going through task manager, but procmon is what led me to it!

Edit: Did a search through C:\Windows for WMI*.exe and found it. WMIADAP.exe That's the... *contains swearing* one.

Edited June 10, 2018 by Ryan_Vickers

GoodBytes · June 11, 2018

That is correct.

I suspect the problem to come back as whatever driver or software doing this will redo the call eventually.

WMI is great tools for developers, but if miss used, it can be taxing. I just expected to see something from Task Manager in terms of usage... but I guess it calls more interrupts than anything, or plays with the process scheduler, cutting process time, and hence the drop in performance.

If it was my guess onto why it happened only on this new version of Windows 10. The usual culprit (as in common mistake), is that you have a version check in the code of whatever software/driver. But this being a new version of Windows, the code wasn't updated to add this new version in the if condition, and jumps to some 'else' statement, executing some wrong code.

For example, to make it simple:

if (OSName == "Windows 10" && OSVersion <= 1709) {
  // Windows 10 specific action
} else if (OSName == "Windows 8" || OSName == "Windows 7"  || OSName == "Windows Vista") {
  // Windows Vista, 7 and 8 specific action
} else {
  // User is on Windows XP! Do XP stuff.
}

Possibly the logic (which is flawed, if that was the case), is that "We don't know how future version of Windows 10 will act, so we check its version, and if it is the same as before, we will update the driver", sadly the dev has no assurance that he will be able to change that later on, company might go "Too old hardware, so gets updated last", and that means months delays for a patch, or "Too old, no more support", and you are stuck with that bug. Of course, I am all assuming here. This is just guess work on my part. I could be (and most likely) was off, and that it ends up in some call to WMI that expects to end to get the result and finish the driver setup, but there is a bug in Windows 10 with that specific call, and never ends, and the call creates the issue you are having.

vanished · June 11, 2018

3 hours ago, GoodBytes said:
That is correct.

I suspect the problem to come back as whatever driver or software doing this will redo the call eventually.

WMI is great tools for developers, but if miss used, it can be taxing. I just expected to see something from Task Manager in terms of usage... but I guess it calls more interrupts than anything, or plays with the process scheduler, cutting process time, and hence the drop in performance.

If it was my guess onto why it happened only on this new version of Windows 10. The usual culprit (as in common mistake), is that you have a version check in the code of whatever software/driver. But this being a new version of Windows, the code wasn't updated to add this new version in the if condition, and jumps to some 'else' statement, executing some wrong code.

For example, to make it simple:
if (OSName == "Windows 10" && OSVersion <= 1709) {
  // Windows 10 specific action
} else if (OSName == "Windows 8" || OSName == "Windows 7"  || OSName == "Windows Vista") {
  // Windows Vista, 7 and 8 specific action
} else {
  // User is on Windows XP! Do XP stuff.
}
Possibly the logic (which is flawed, if that was the case), is that "We don't know how future version of Windows 10 will act, so we check its version, and if it is the same as before, we will update the driver", sadly the dev has no assurance that he will be able to change that later on, company might go "Too old hardware, so gets updated last", and that means months delays for a patch, or "Too old, no more support", and you are stuck with that bug. Of course, I am all assuming here. This is just guess work on my part. I could be (and most likely) was off, and that it ends up in some call to WMI that expects to end to get the result and finish the driver setup, but there is a bug in Windows 10 with that specific call, and never ends, and the call creates the issue you are having.

Speaking of the old version, given that it worked, but also didn't work on 1709, I figure it's possible the same is or would be true for 1803, and as such I'm doing some experiments. I'll update this once I have the full story.