It is something iCue could cause. Corsair refuses to use or respect hardware sensor mutex locks, so it can and does cause polling collisions, which can result in erroneous sensor readings, freezes, high CPU usage, and in some cases, crashes. Corsair was shown how to poll sensors correctly, and they did implement a mutex in iCue for awhile many years ago. For some reason, they stopped doing it. iCue is like a drunk with a machinegun, spitting out sensor polling requests with no regard for the state of the sensor, or other software that may be polling it. Here is a quick description of how programs responsibly poll hardware sensors, which iCue does not do.

1. When two programs both use a mutex to poll a hardware sensor, they coordinate their access via the mutex.
   
2. Program A attempts to poll the sensor and, as part of this process, locks the mutex associated with the sensor. This mutex lock signals that Program A has exclusive access to poll the sensor.
   
3. Program B then tries to poll the sensor as well, but before it can proceed, it encounters the locked mutex.
   
4. Because Program B is also programmed to respect the mutex, it will enter a waiting state. This means Program B will not complete the sensor poll until the mutex is unlocked.
   
5. Once Program A has completed its polling and releases the mutex, Program B can then acquire the lock, allowing it to proceed with its own sensor polling.
   
6. This mutual respect for the mutex ensures that only one program polls the sensor at a time, preventing polling collisions and ensuring data integrity.
   

This blatant disregard for proper sensor polling is one of the reasons that I refuse to install Corsair iCue on any of my systems. It can do some RGB things that Aquasuite cannot do, but those things are not worth the headaches.