[Guide] How to control fans on Dell Laptops under Windows

Ok, so, two questions:
1. It looks like everything is working (at least according to the output) as long as you have driver signing verification off? (There is some issue with the system not accepting the signature on the file that I signed in that case.)
2. After you get a successful ec-disable, are you able to control the fans any better with SpeedFan, or is the behavior the same as before?
In the case that SpeedFan control *doesn't* work, can you try with the "alternate" disable method? (That's what they were using in the Linux code you linked before.)

Also:
@MikeR_Va
You've been able to run the tool successfully with Windows in the regular state? (No test signing mode, no driver signature verification off?)

 

@Aaron44126 Yes. The driver is fully compatible with the 9570 it seems. After ec-disable and set both fans to 0RPM with HwInfo the laptop is dead silent and EC doesnt interference anymore, at least with bios 1.6.0. Bios 1.7.0 will mostly break this, unfortunately, I havent tested it yet. So there are several issues here it seems:

- My Windows 10, for whatever reason, wont accept your signed driver, just if I disable driver signed mode (did you maybe add some certificate inclusion on your PC?)
- There is some issue with the service cleanup, mostly some weird bug. It seems the driver isnt properly cleaned up if there is an issue, and then it gets broken. That is why I had a successful sc delete, even I had not run it before manually. And then after deleting "cleaning up", it worked (with driver signed off). How do I now see if I have a "mess" of broken sc driver services maybe? Did your tool use the same name as the original dell tool? Which btw still doesnt work for me, the fan control of it doesnt work for the 9570. It seems to have the same issue, not able to create or run the driver service by itself.

SpeedFan doesnt work for me on the 9570, it shows no fans actually. I dont use SpeedFan also I use HwInfo and I can control the fans perfectly with it (now). Though the fan control is really primitive so far in HwInfo. I asked the dev if he could maybe implement some more "smart" options if he has time. Like time until turn off after one value reached, a delay in time after one was over stepped, and so on.

Another great news: I am in contact with the developer of HwInfo and he was so amazingly nice, to just implement in a few hours the code into HwInfo, and HwInfo now supports natively the same register writes (method1/2 from the github code) for Dell laptops, to turn off the EC auto fan control, and also turn it on again. I am testing a test build since yesterday and it works perfectly so far.

https://www.hwinfo.com/forum/Thread-REQUEST-Write-to-EC-manual-fan-control-on-Dell-XPS-laptops

You can download the test build here: https://www.hwinfo.com/beta/hwi64_601_3636.zip

My settings:

https://i.imgur.com/Hg4DLLT.png fan1 custom auto button
https://i.imgur.com/Kcw4O38.png fan2 custom auto button

I have set a 20 second spin-down.

Auto start custom fan control when starting HwInfo, correct sensors have to be selected and loaded at start:

OpenFanCtrlMin=1

in ini file of the HwInfo folder.

 

I don't have a certificate exclusion for this. Also, Windows won't check certificate exclusions when it comes to loading kernel-mode code. (Tried that before )
I'll check on another system that I had that failed to load the driver and see if it is the same problem.

My command-line tool and the GUI tool it is based on use the same service name when loading the driver. Both seem to clean up properly on my system. You can see a list of services installed in the registry (Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services). Type = 1 means kernel drivers.

Just to be sure, did you visit SpeedFan configuration and check the box for Dell system support? It is off by default and required to even see the fans. (Restart the app afterwards.)

Glad to see support is on the way to HwInfo, so it seems. I might check that out. (Really happy with my SpeedFan config though )

 

@Aaron44126 I added the link to the HwInfo test build up in the post. Basically, it is 100% the same as the driver does, same ASM code from github with method1/2. The advantage here is, it works properly because of the HwInfo driver is signed and works.

I havent done that actually in SpeedFan so that might be why it didnt show fans. I dont want to use too many tools though, and each has its own kernel driver, adding up latency maybe. If it could be done in one tool like HwInfo I dont want to use SpeedFan next to it which has again a kernel driver.

Would be nice to find out though, why your signed driver wont load for me. Could you also maybe add another command line argument? That ec-disable doesnt set the fans to 100%. Maybe add a ec-disable-fans100 which does that, or vice versa.

If I have entries in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services does that mean they are loaded automatically? Do I have to remove the entries manually? Shouldnt it have no entry if it was cleaned up properly?

 

You are correct, if you see an entry in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services then it was not properly cleaned up. (I'm not sure why it would not clean up properly, I haven't run into this.) It only starts automatically though if "Start" is set to 0, 1, or 2.

My tool does attempt to set the fans to 100% (using the same method the GUI tool used). Again, it works as expected on my system. If it doesn't actually happen for you, I'm not sure what else I could try...

 

Yes I dont want that though. So I suggest to add a separate option for that.

DellFanCmd ec-disable (default sets fans to 0)
DellFanCmd ec-disable-set-fans100 (whatever naming you want)

or vice versa

DellFanCmd ec-disable (default sets fans to 100)
DellFanCmd ec-disable-set-fans0 (whatever naming you want)

So yes, I have an issue that there remains entries in the controlset, and that causes it become broken the next time I want to start it. There are other entries btw I noticed which I disabled, like one driver from RWEverything, or an old i8k driver, which both are not installed anymore, yet the control entries still exists...

https://i.imgur.com/CcNAa9s.png
https://i.imgur.com/CajWzg1.png (is set to 3 so no autostart I guess?)

 

1. I will add an option to disable EC control without messing with the fan speed.
2. I believe that I may have identified the service clean-up issue. In the case that DellFanCmd tries to load the driver and it *fails*, it does not clean up properly. I will address this. (The fanio.sys one in your first screen shot, I don't think that I have anything to do with that.)
3. My Precision 7530 is reporting the same thing as your system when I try to load the driver, complaining about the digital signature. So, now at least I have a reproduction that I can dig into. (Hoping it is not because I just got the certificate from the cheapest source that I could find that promised Windows kernel-mode signing support; not sure why it would be accepted on some systems but not others.)

 

It looks like there are additional rules regarding driver signature acceptance.
https://blogs.msdn.microsoft.com/wi...r-signing-changes-in-windows-10-version-1607/ ("...In addition, if Secure Boot is set to OFF, then drivers signed with existing cross-signed certificates will continue to be valid.")
Basically, it says that you need to submit your driver to be tested and signed by Microsoft before it will work; your own purchased code-signing certificate is no longer fully adequate. However, the rule doesn't apply if secure boot is disabled, and a cross-signed certificate will be fine.

@MikeR_Va Can you confirm to me whether or not you have secure boot enabled or disabled, at present?
@maffle Similarly, can you try turning secure boot off but leaving everything else (test signing / disable driver signature enforcement) in the regular state and see if the driver can be loaded?

Funny thing is, I have secure boot turned *on* on my M6700. (I'll actually have to double-check this but I am 99% sure this is the case.) However, the M6700 did not originally ship with the secure boot feature, it was added after launch via firmware update. I know it works because I have had to disable it to load bootable tools (disk cloning / memory check / Linux / etc. from before they started mostly coming with the needed certificates). But, I'm wondering if the implementation is incomplete and if there is something different, preventing Microsoft from detecting that secure boot is enabled on my system. This might be why I haven't had to disable secure boot in order to enter test signing mode, when I have heard other users complaining about having to do this.

 

@Aaron44126 Yepp. Was secure boot on (I had activated it again actually after I set driver sign on again), which blocked the (even) signed driver. So with secure boot off and yet nointegritychecks off, it loads fine. If it goes though until the end, with no failed during it, the controllset entry is also properly deleted afterward.

 

Ok, so that seem to be it. It wants an Microsoft EV certificate for the driver and it won't accept my (valid) cross-signed certificate. This is a new requirement as of Windows 10 1607. And it just "happens" to work on my M6700 likely due to incomplete secure boot implementation. (Man, I thought that was too easy...)

Haven't heard back from @MikeR_Va but I strongly suspect that he just never bothered to turn secure boot back on during the testing that we've been doing.

Looking at ways around the "secure boot off" requirement. Turns out that Windows 10 will accept cross-signed drivers if any one of the following apply:
* The driver is signed with a certificate that was issued before 29th of July 2015
* The driver is a boot up driver
* Secure Boot is Off
* The Windows 10 version 1607 System was upgraded and not directly installed
* A secret registry key is set that allows cross-signed drivers to load even on systems with Secure Boot enabled
(Source: https://superuser.com/questions/111...drivers-in-windows-10-version-1607-with-secur)

Targeting one of the latter two seems to be the best way around this. There's got to be a way to put a registry key in for the system to "think" that it was upgraded from an earlier version of Windows. (I'm not going to spend the effort trying to get an actual EV certificate at this time... However, if anyone else wants to take that up, cool beans.)

I found this page which has a bunch of usual information that is going to take some time to digest. And I actually need to do regular work now. So I'll come back to this later but if anyone wants to look this over and try anything... Let me know what you find.
https://www.geoffchappell.com/notes/security/whqlsettings/index.htm

[Edit]
The keys in the "Restoration (1607)" section look most likely to be what we want. Or maybe the "Original Exceptions" ones right above would be better, if they still work.