While that might be desirable if you have to be able to react VERY quickly to something, there's no reason to do that here. #Amd driver uninstaller code#The correct way to implement this code is to either set a time limit for how long the loop should run, or count the number of runs and give up after 100, 1000, 1 million, you pick a number-but it's important to set a reasonable limit.Ī more subtle effect of this kind of busy waiting is that it will run as fast as the processor can, loading one core to 100%. You're probably asking now, "what if the event never gets created?" Exactly, your program will be hung, forever, caught in an infinite loop. Since Windows has no WaitForEventToGetCreated() function, the usual approach is to try to open the event until it can be opened, at which point you know that it does exist. #Amd driver uninstaller driver#I guess that part of the driver does indeed check if Radeon hardware is present, and will not start otherwise. The naming suggests it's related to the ReLive recording feature that lets you capture and stream gameplay. The Task Scheduler entries in the screenshot above do show "StartDVR". This event gets created by a separate, independent, driver component, that's supposed to get loaded on startup, too, but apparently never does. In this case the Radeon Settings program will wait for an event called "DVRReadyEvent" to get created, before it continues with initialization. Events are a core feature of the Windows operating system, once created, they can be set to "signaled", which will notify every other piece of code that is watching the status of this event-instantly and even across process boundaries. In a multi-threaded program, Events are often used to synchronize concurrently running threads. If you're a programmer you'd have /facepalm'd by now, let me explain. I attached my debugger, looked for the thread that's causing all the CPU load and found this: Unless you're a computer geek you'll probably want to skip over the following paragraphs, I still found the details interesting enough to share with you. By the way, all this was verified to be happening on Radeon 20.11.2 WHQL driver, 20.11.3 Beta and the press driver for an upcoming Radeon review. #Amd driver uninstaller software#I got curious and wondered how it is possible in the first place that an utility software like the Radeon Settings control panel uses 100% CPU load constantly-something that might happen when a mining virus gets installed, to use your electricity to mine cryptocurrency, without you knowing. Also, do we really need six entries in Task Scheduler? It would be trivial to add a check "If no AMD hardware found, then exit immediately", but ok. Looks like AMD is doing things differently and just pre-loads Radeon Settings in the background every time your system is booted and a user logs in, no matter if AMD graphics hardware is installed or not.
0 Comments
Leave a Reply. |
AuthorEric ArchivesCategories |