IMPORTANT HWiNFO64A_178.SYS driver is being banned under Win11 [10.0.22621.1702] by Hardware-enforced Stack protection

That looks like the Thermaltake uninstall isn't working properly and it didn't remove all files.
Anyway, Thermaltake has already the latest version and should be able to provide a fixed version of their software.
 
After reading some more posts from people with similar problems I updated then I even removed all the Thermaltake software. The problem remained. I then updated iCUE. No joy. I also removed the recently installed HWiNFO. The problem persists. Then I started searching for that file, I found it only in the AppData/local/Temp directory. It had a recent timestamp. I deleted it. I think that solved the problem, now Windows allows me to enable that protection.

I also searched for any files with HWiNFO in the name on my system drive.

Only two files remain:
"c:\Program Files\ASUS\ARMOURY CRATE Lite Service\HWComponentPlugin\HWInfo.ini" (might be unrelated)
"c:\Program Files\Tt\Tool\HWiNFO64.dll" (it seems ThermalTake are not aware that "uninstall" doesn't mean what they think it means, I'll probably delete that directory manually since the "uninstall" failed to do that).
Anyone who is running Corsair iCue, Asus Armoury Crate, and anything made by Thermaltake can expect to have problems. All of these programs are poorly written, buggy, and install multiple background services that put undue load on the system. Armoury Crate is a borderline rootkit and Thermaltake likes to force you to make an account so they can spy on you. You may have to reinstall Windows to completely get rid of this janky software.
 
Anyone who is running Corsair iCue, Asus Armoury Crate, and anything made by Thermaltake can expect to have problems. All of these programs are poorly written, buggy, and install multiple background services that put undue load on the system. Armoury Crate is a borderline rootkit and Thermaltake likes to force you to make an account so they can spy on you. You may have to reinstall Windows to completely get rid of this janky software.
That's more or less true, but unfortunately they are kind of needed if you want to control the LEDs that come with almost all hardware these days. And in case of iCUE, also to control the liquid cooling system. In my case, I use them to turn all LEDs off, and setting them to light up only if the component becomes too hot. Microsoft is working on something that should replace all these LED control apps, we'll see how it goes.
 
That's more or less true, but unfortunately they are kind of needed if you want to control the LEDs that come with almost all hardware these days. And in case of iCUE, also to control the liquid cooling system. In my case, I use them to turn all LEDs off, and setting them to light up only if the component becomes too hot. Microsoft is working on something that should replace all these LED control apps, we'll see how it goes.
I keep a list of software to NEVER install, no matter what. Asus Aura, Armoury Crate, Corsair iCue, and Thermaltake RGB Plus and DPS G App are on that list. I learned the hard way never to install these programs. The biggest problem with iCue is that it does not queue and synchronize hardware polling requests, which is why you can't run iCue with any properly coded program that polls hardware sensors (like HWINFO). Polling collisions will occur, resulting in nonsense data, freezes, and crashes.

There are alternatives.

Open RGB and Signal RGB can control a huge number of 3rd party devices, and they are constantly adding support for new products. SIV can control most Corsair controllers including the Commander Pro, Lighting Node Pro, and Lighting Node Core. It is rock solid and far more efficient than iCue in terms of system load. For a custom loop, Aquasuite is in a class by itself. It is light years beyond iCue in PWM fan control and hardware monitoring. FanControl is an open-source app that is gaining popularity. Like Aquasuite, you can combine hardware sensor data into virtual sensors.

A simple example is subtracting ambient temp from coolant temp and using the difference (delta-t) as the control source for PWM fan curves. The heat transfer efficiency of a radiator does not depend on coolant temp. It depends on the difference between coolant temp and ambient temp. If coolant and ambient temp are the same, no heat transfer will occur no matter how fast the fans spin. If the room the system is in experiences seasonal changes in temperature, when the ambient temp is higher then the starting coolant temp will also be higher. If you base your fan speeds on the coolant temp, they will spin faster and make more noise, but no heat transfer will occur until the coolant temp exceeds the ambient temp. Using the delta-t removes this problem and controls your fans directly with what actually matters - the difference in these 2 temps. This is super easy to do in Aquasuite.

A more complex example - You want your fan speeds to be controlled by coolant/ambient delta-t but you also want them to increase speed if your CPU or GPU exceeds a target temp for a period of time. This is also easy to set up in Aquasuite. If you have a temp sensor at the inlet and outlet of a radiator, and you know the flow rate and the specific heat of the coolant, you can calculate how many watts the rad is dissipating. You can have LED colors change based on system temps. You can wire in an Alarm cable that will shut your system down immediately if the flow rate and/or pump speed drops below a threshold, even if Aquasuite is not running and even if Windows is locked up. Can iCue do that? Aquasuite is an incredibly powerful program and the absolute best for cooling component control.

I would NEVER depend on iCue to control my loop components, but then again I would never buy critical loop components from Corsair. Some of their products (like their rads) are OK, only because they just rebrand products made by others. Things like GPU blocks, pumps, and reservoirs that they have had QC problems with I would not touch. YMMV...
 
I was still receiving the warnings despite upgrading to the latest version. A little more digging revealed that I had multiple versions of the driver on my system. It would seem that for some reason old versions weren't removed when I upgraded.

Code:
BOOTLOG_LOADED \??\C:\WINDOWS\system32\drivers\HWiNFO64A_180.SYS
BOOTLOG_NOT_LOADED \??\C:\WINDOWS\system32\drivers\HWiNFO64A_174.SYS
BOOTLOG_LOADED \??\C:\WINDOWS\system32\drivers\HWiNFO64A_173.SYS
BOOTLOG_NOT_LOADED \??\C:\WINDOWS\system32\drivers\HWiNFO64A_172.SYS
BOOTLOG_LOADED \??\C:\Windows\system32\drivers\HWiNFO64A_161.SYS
BOOTLOG_LOADED \??\C:\WINDOWS\system32\drivers\HWiNFO64A.SYS

All of which were configured in registry to load at startup as a service.

Code:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO]
"DisplayName"="HWiNFO Kernel Driver"
"Type"=dword:00000001
"Start"=dword:00000001
"ErrorControl"=dword:00000001
"ImagePath"=\??\C:\WINDOWS\system32\drivers\HWiNFO64A.SYS

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_161]
"DisplayName"="HWiNFO Kernel Driver (v161)"
"Type"=dword:00000001
"Start"=dword:00000001
"ErrorControl"=dword:00000001
"ImagePath"=\??\C:\Windows\system32\drivers\HWiNFO64A_161.SYS

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_172]
"Type"=dword:00000001
"Start"=dword:00000001
"ErrorControl"=dword:00000001
"ImagePath"=\??\C:\WINDOWS\system32\drivers\HWiNFO64A_172.SYS
"DisplayName"="HWiNFO Kernel Driver (v172)"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_173]
"Type"=dword:00000001
"Start"=dword:00000001
"ErrorControl"=dword:00000001
"ImagePath"=\??\C:\WINDOWS\system32\drivers\HWiNFO64A_173.SYS
"DisplayName"="HWiNFO Kernel Driver (v173)"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_174]
"Type"=dword:00000001
"Start"=dword:00000001
"ErrorControl"=dword:00000001
"ImagePath"=\??\C:\WINDOWS\system32\drivers\HWiNFO64A_174.SYS
"DisplayName"="HWiNFO Kernel Driver (v174)"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_180]
"Type"=dword:00000001
"Start"=dword:00000001
"ErrorControl"=dword:00000001
"ImagePath"=\??\C:\WINDOWS\system32\drivers\HWiNFO64A_180.SYS
"DisplayName"="HWiNFO Kernel Driver (v180)"

To fix this, I deleted all but the latest entry (v180) from registry, rebooted, and then deleted the old files from the drivers folder.
 
Hi - I am seeing two of these "incompatible" HWInfo64 drivers when trying to enable Win11's Hardware-enforced Stack Protection. HWiNFO64A_174.SYS and HWiNFO64A_178.SYS are showing up as incompatible. I am currently running HWiNFO v8.10. Are these drivers still required for my current installation? Or, can they be deleted - And if so ... how?
 
You can delete those drivers. Use the following commands from Admin command-prompt (or Power Shell):
sc stop hwinfo_174
sc delete hwinfo_174

sc stop hwinfo_178
sc delete hwinfo_178
 
Back
Top