Fan Control (Rem0o/FanControl.Releases): a Windows fan curve tool with a closed-source core

What Fan Control actually solves on a Windows desktop

Motherboard fan headers on Windows are usually governed by firmware curves that respond to one sensor, often the CPU package, and that you cannot edit from the operating system. The result is a machine that ramps to audible speeds under a short burst and stays loud afterwards, or that lets a GPU or an NVMe drive cook because the board curve never looks at them. Fan Control exists to take that decision away from the firmware and put it in a Windows application where you choose the sources, the curve shape and the response behaviour.

The audience is narrow and specific. It is people running Windows on desktop hardware with controllable headers: gamers who want a quiet idle, workstation owners with several drives and a hot GPU, and tinkerers who already know which header feeds which fan. It is not a server tool. It is not a laptop tool in general, although the plugin list includes a Dell plugin for laptops and some towers, which suggests the maintainer treats some laptop models as in scope. The README describes the software as "a focused and highly customizable fan controlling software for Windows" and states plainly that the sources are closed.

How the control loop is put together

The architecture visible from the repository is a single Windows executable, FanControl.exe, plus an updater and a plugin directory. Sensors come from a LibreHardwareMonitor build, and since V238 that build uses PawnIO rather than WinRing0, which the announcement says removes the anti-virus problems associated with the older driver. Plugins extend the sensor set: the README lists official ones for Intel ARC GPUs, HWInfo data import and Dell hardware, and a longer community list covering Thermaltake, liquidctl-based AIOs, ASUS WMI, Aquacomputer, Corsair, Razer, NZXT Kraken and Home Assistant sensors.

The data flow is sensor to curve to fan. You pick one or more temperature sources, apply a curve function, optionally mix curves or sensors with max, min or average, then bind the result to a controllable fan output. The tuning layer sits on top of that: steps, start percentage, stop percentage, response time and hysteresis. Those five parameters are where most of the practical work happens. Hysteresis and response time decide whether the fan reacts to a spike or ignores it, and start and stop percentages decide whether a fan can spin down entirely or must stay above a stall threshold. The curve editor is graphical, and the newer calibration avoid points let you exclude a percentage range where a particular fan rattles.

Installing Fan Control and building a first curve

The README gives three routes. You can download the archive and extract it, or take an installer from the releases page. Package managers are also supported, and the README documents the exact commands for Scoop, Winget and Chocolatey. For a normal desktop, the Winget route is the least ambiguous because it installs the packaged build rather than leaving you with a folder you have to remember to update.

winget install Rem0o.FanControl

If you prefer Scoop, the package lives in the extras bucket, so the bucket has to be added before the install will resolve.

scoop bucket add extras
scoop install fancontrol

After the first launch, the README says a guided setup process runs. That is where you confirm which fans are detected and which sensors are readable. The thing to check at this stage is whether your board exposes controllable headers at all; detection is hardware dependent, and the README points hardware compatibility questions at the issues section rather than promising universal support. Once setup finishes, you create a curve, assign a temperature source, and bind it to a fan. Save it as a profile, because profiles are the unit you reload when you change workloads.

One more command matters if you ever remove the portable build. The README warns that the app can register a Windows Task Scheduler task to start with Windows, and that uninstalling the portable version means either unticking the checkbox inside Fan Control or deleting the "Fan Control" task manually.

The closed-source core and the driver history

The most consequential fact about this project is that the release repository is not the source repository. The README says the sources are closed, and the repository contents match that: a zip, an installer, an updater, images and a licence file, with no application code. For a tool that reads hardware sensors and writes fan speeds, that is a real trade-off. You are trusting a signed binary with low-level access to your machine, and you cannot inspect how it decides what to write to a header.

The driver history explains why this matters in practice. The announcement states that V237 and below shipped WinRing0, that Windows Defender flagged it as Trojan:Win32/Vigorf.A, and that this caused sensors to stop being detected. V238 and later ship the PawnIO build of LibreHardwareMonitor instead, and the README calls updating to V238 or later the recommended fix. There is also a note that a FaceIT conflict was resolved with the 2.1.0 PawnIO version. If you are running an older build because it worked, that is the specific failure mode waiting for you: a Defender signature update can silently break sensor detection rather than crashing the app.

Where Fan Control is the wrong choice

The first boundary is the operating system. This is Windows software, and the repository offers nothing for Linux or macOS. On Linux the equivalent work is normally done through the kernel's hwmon interface and a userspace daemon, which is a different design with different failure modes but no closed binary.

The second boundary is the machine class. On servers and on many workstations, fan policy belongs to the BMC, which keeps cooling under control when the operating system is not running. Replacing that with a Windows application means cooling depends on a user session, a service, or a scheduled task being alive. The README does note that Fan Control can now start on boot as a service without any user session, which narrows the gap, but it does not make the tool equivalent to firmware-level control.

The third boundary is hardware coverage. Support is mediated by LibreHardwareMonitor and by plugins, so a board or cooler that neither recognises is simply not controllable. The README handles this by pointing to the issues and hardware compatibility section rather than publishing a compatibility matrix, which means you find out by trying. Laptop owners should treat the Dell plugin as the exception it is described as, not as evidence of broad laptop support.

Alternatives and how they differ in approach

The natural comparison is the motherboard vendor's own Windows utility, such as the ASUS, MSI or Gigabyte tuning suites. Those are also closed and also write to fan headers, but they are tied to one vendor's boards and typically expose a fixed set of sensors and curve presets. Fan Control's difference is breadth: it mixes sources across CPU, GPU, motherboard and hard drives, and it accepts plugin sensors, so a Home Assistant temperature reading or an HWInfo value can drive a fan. If you own one vendor's board and only ever want a CPU curve, the vendor tool is less to install and less to maintain.

The other real alternative is not a fan utility at all but a hardware fan controller, a separate box with its own temperature probe and knobs. That removes the operating system from the loop entirely and cannot be broken by a driver signature update. It also cannot react to a GPU hotspot or an NVMe sensor, and it costs a piece of hardware instead of a download. The choice between them is really a choice about whether you want software-defined curves that can see every sensor, or a controller that keeps working when Windows does not.

Maintenance, updates and licence position

The repository is a release channel, so its activity is measured in releases rather than commits. The last push was on 2026-09-19, and the three most recent releases are V278 on 2026-09-19, V277 on 2026-09-13 and V276 on 2026-09-12. That is a rapid cadence, and it is the practical argument for installing through a package manager: Winget, Scoop and Chocolatey give you a path to the current build without watching the releases page yourself. The repository also ships Updater.exe and a version.json, which suggests the application checks for its own updates, though the README does not document the updater's behaviour or whether it can be disabled.

On licensing, the repository carries a LICENSE file but the metadata reports NOASSERTION, and the README states the sources are closed. That combination means you should read the LICENSE file in the repository yourself before redistributing anything. Nothing here tells you whether the binary may be bundled into a system image, and the presence of donation links to PayPal and Stripe says the project is funded by users rather than sold as a product. Treat the licence as something to verify rather than assume.

Editorial conclusion

Adopt Fan Control if you run Windows and want temperature-driven fan curves across CPU, GPU and motherboard sources without writing your own controller, and if you accept a closed-source binary that asks for low-level hardware access. Skip it on Linux, on servers where a vendor BMC already owns fan policy, and on any machine where you cannot install a signed third-party driver or run the app as a boot service. Before rolling it out, verify on one machine that your board exposes controllable headers, that the installer or archive version you pick matches the updater you intend to use, and that the Fan Control scheduled task is removed if you later uninstall the portable build.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Rem0o/FanControl.Releases on GitHub