At first I blamed NVIDIA, however after I opened Task Manager I observed one in every of my cores sitting at 100%—that may’t be proper.
Digging a bit additional into this, it seems like RadeonSettings.exe is utilizing one processor core at most 100% CPU load. Ugh, however there is no such thing as a AMD graphics card put in proper now.
Once that course of was terminated manually (proper click on, choose “End task”), efficiency was restored to anticipated ranges and CPU load was regular once more. This confirms that the AMD driver is the rationale for the excessive CPU load. Ideally, earlier than altering graphics card, it’s best to uninstall the present graphics card driver, change {hardware}, then set up the brand new driver, in that order. But for a fast take a look at that is not what most individuals do, and others are merely not conscious of the truth that a factor referred to as “graphics card driver” exists, and what it does. Windows is sensible sufficient to not load any drivers for units that are not current bodily.
Looks like AMD is doing issues otherwise and simply pre-loads Radeon Settings within the background each time your system is booted and a consumer logs in, regardless of if AMD graphics {hardware} is put in or not. It can be trivial so as to add a examine “If no AMD hardware found, then exit immediately”, however okay. Also, do we actually want six entries in Task Scheduler?
I bought curious and puzzled how it’s attainable within the first place that an utility software program just like the Radeon Settings management panel makes use of 100% CPU load continuously—one thing that may occur when a mining virus will get put in, to make use of your electrical energy to mine cryptocurrency, with out you realizing. By the way in which, all this was verified to be occurring on Radeon 20.11.2 WHQL driver, 20.11.3 Beta and the press driver for an upcoming Radeon assessment.
Unless you are a pc geek you will most likely need to skip over the next paragraphs, I nonetheless discovered the small print attention-grabbing sufficient to share with you.
I hooked up my debugger, seemed for the thread that is inflicting all of the CPU load and located this:
Hard to learn, translated it into C code it would make extra sense:
If you are a programmer you’d have /facepalm’d by now, let me clarify. In a multi-threaded program, Events are sometimes used to synchronize concurrently working threads. Events are a core characteristic of the Windows working system, as soon as created, they are often set to “signaled”, which is able to notify each different piece of code that’s watching the standing of this occasion—immediately and even throughout course of boundaries. In this case the Radeon Settings program will look forward to an occasion referred to as “DVRReadyEvent” to get created, earlier than it continues with initialization. This occasion will get created by a separate, unbiased, driver part, that is imagined to get loaded on startup, too, however apparently by no means does. The Task Scheduler entries within the screenshot above do present “StartDVR”. The naming suggests it is associated to the ReLive recording characteristic that permits you to seize and stream gameplay. I suppose that a part of the motive force does certainly examine if Radeon {hardware} is current, and won’t begin in any other case. Since Windows has no WaitForEventToGetCreated() perform, the standard method is to attempt to open the occasion till it may be opened, at which level that it does exist.
You’re most likely asking now, “what if the event never gets created?” Exactly, your program might be hung, ceaselessly, caught in an infinite loop. The appropriate solution to implement this code is to both set a time restrict for the way lengthy the loop ought to run, or depend the variety of runs and quit after 100, 1000, 1 million, you choose a quantity—but it surely’s necessary to set an inexpensive restrict.
A extra refined impact of this type of busy ready is that it’s going to run as quick as…
