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

@Aaron44126 I actually know, that under Linux you can easily modify the fan curve and literally alter the fan just how you want it to work, even for the 9570. So it is possible, and the driver already exists in open-source form for Linux. If the driver exists for Linux, it should be possible to port it to Windows too, no? I actually asked about it before on the Linux Dell thermal github, but no one answered me on there back...

 

Indeed, there is no reason that it should work on Linux but not be possible on Windows. It's a matter of gathering knowledge and figuring it out — and depending on how deep it goes, that might require driver/ASM code.

Part of the problem might be, it is already possible to adjust the fans on Windows (SpeedFan can do it), but something else also controlling the fans that needs to be shut off. Have you looked into disabling the Intel thermal framework stuff? A driver gets installed for that. (I remember reading about this when I was looking into stuff with my current project, but haven't dug into it at all because the Intel thermal framework isn't present on older systems like my M6700.)

 

Aaron:

Thanks a whole lot for the effort -- this is going to be really good if it works -- and is should. It's going to take me a bit, but I'll sort your instructions, do some testing and report back. And, though I can't seem to find a PM function on the board, and your profile now seems restricted, I'm happy to buy you a beer or two. Just point me to the PM function or some such, and I'll make contact.

Re: the fan profiles -- Dell's documentation suggests that some of the workstation-like laptops, unlike my XPS 13, may run as many as five fan levels. Seems to depend on what our hardware is. In case that helps.

Maffle:

Well, heck. I'll look back over my reading to see if anybody got this to work on newer machines just to be sure, but Aaron's testing suggests that Dell has indeed been up to further locking down the fans. That's just . . . annoying.

Seems pretty clear now that you were doing all the right things, just as you suggested -- they just made it more "idiot proof" while we were out, preventing us for now from having control on newer machines. Which, given that even the most aggressive fan profiles I've tested from Dell seem to weigh heavily in favor of silence even at temps that look scary to me, isn't really a good thing for those that would like to change them.

The "best" solution to this would be a DELL BIOS that allows you to set any fan break points you want below Dell's least aggressive option. By definition, if they don't go to 50% fan until 78C, and 100% at 85C (just for example), they're making a judgment that this is safe, so if you or I want more cooling at the expense of noise, why not allow that? If they're going to keep playing cat and mouse locking down the fans, I do wish they'd do that. So far, even the max performance profile lets the machine get way too hot.

Sorry man. Hope there's a solution for you. If not, happy to join the petition drive . . . I get that this has to be done cautiously, but I don't see how allowing more aggressive use of fans could do much damage. You might wear the fan out sooner if you ran 100% all the time, but come on -- that's not much of risk, is it?

Mike

 

You can start a private conversation from the "Inbox" option at the top right of the forum. I think you might have to have 10 posts before the function is available (almost there?).

 

Almost . . . hehe. OK, that should be 10.

 

Aaron:

First Beta test report follows:

Either I'm doing something wrong, or maybe we're not quite there yet.

1. Unzipped your file to a new folder c:\Utilties\AaronFanUtil . . .

2. Set up, maybe too soon, an elevated prompt on Task Manager. Set the argument in the separate space for "arguments" in taskman -- looks right when you're done. Specified the above as working folder

Cold boot -- no result. No error, no control.

3. Installed C++ Runtime -- maybe the wrong one? Same result on boot.

4. Disabled Task, rebooted and tried a manual run with elevated command prompt.

5. No joy, but now useful info.

First, you need to run from the working directory -- pretty much as expected.

Once there, the command attempts to execute. This produces three error messages, looking for the following missing dlls. vcruntime140D.dll; ucrtbased.dll, and msvc140D.dll.

6. Errors suggest a reinstall -- so I ran a repair on the same C++ Runtime. Shut down and cold boot. Same result.

7. Tried the alt disable command even though I was pretty sure it wouldn't work -- same basic result at 5, though I didn't think to recheck the individual dll names to be sure they were identical.

Thinking maybe you work this these dlls on your machine all the time, and maybe they're not in the C++ indicated? Or did I screw it up some other way?

Ready to try again when you are.

Mike

 

@ Aaron44126 Tried your program but several DLLs are missing, I have installed the vc_redist.x64.exe though. These are installed: https://i.imgur.com/O4oU8aX.png

Edit: Googling about it, it says the missing DLLs are debug versions (D) at the end, so you didnt compile it properly in retail mode. Please do so and provide new version.

 

I'm attaching a release mode build. Let me know if it is any difference. Tomorrow I will try running it on a machine that *doesn't* have Visual Studio installed so I can see what is actually needed.

[Edit] Binary removed, see https://github.com/AaronKelley/DellFanCmd/releases

 

@Aaron44126 of course it is, I already said where the issues was, the needed DDLs (D) at the end are not included in the VC releases, just in the debug environment you have installed. So I could test it now on the 9570, this is what happens:

DellFanCmd.exe ec-disable
DellFanCmd PRE-RELEASE BUILD
Loading SMM IO driver...
Failed.

Run as admin of course. Secure boot normal driver signed requested ect all on default.

I found this debate, which might be a hint why it doesnt work? This driver is based on this old i8k Linux driver anyway, no?

https://patchwork.kernel.org/patch/10701619/

There is the talk about a force=1 option for the Linux i8k driver, does this exist on Windows version too?

I also found this Linux too to deactivate EC fan control for the 9560 without even a driver?

https://github.com/TomFreudenberg/dell-bios-fan-control

Could it be ported to Windows maybe?

As I see it, they all use the same registers:

windrv-dell-smm
#define SMM_DISABLE_BIOS_METHOD1 0x30a3
#define SMM_ENABLE_BIOS_METHOD1 0x31a3
#define SMM_DISABLE_BIOS_METHOD2 0x34a3
#define SMM_ENABLE_BIOS_METHOD2 0x35a3

TomFreudenberg/dell-bios-fan-control
#define DISABLE_BIOS_METHOD2 0x34a3
#define ENABLE_BIOS_METHOD2 0x35a3

I guess these didnt change for the 9570, so not sure why the driver fails to load. It should be trivial to port this to Windows sending just a EC register, no?

 

Sorry for the mixup, I normally work with C#/.NET and debug builds work fine on other machines without extra libraries in that case. Anyway...

That code you pointed to uses ioperm which does not have a Windows equivalent. I discussed this a couple of pages back, there is a possible alternate solution. Otherwise it appears to be exactly the same as every other method that I have seen, except for it uses the “alternate method” command to tell the EC to give up fan control. Hmm.

The output of the app on your system (driver failing to load) is the same as what happens on my Precision 7530. I’ll look into switching to the “giveio” driver which is more generic and might work. Not sure if I will have any time to work on it this weekend. I don’t have access to my 7530 until Monday in any case.

Anyway, that is for a 9560 XPS which has 7th gen CPU? I think 8th gen might be where they changed things up so it might still not work.

 

I dont think so. Please look into the Linux kernel patch debate link I gave: https://patchwork.kernel.org/patch/10701619/

Just read through the comments if you have 10 minutes of time, it is not that much. It gives a few clues actually. Seems Dell just changed a few temperature names but that is it, as I see it? The register to deactivate fan control should still be the same, or at least in there for the 9570. This i8k driver works it seems under Linux if you start it with a force=1, so that maybe skips something, which is implemented in this driver, which doesnt load? Also what do the "a3" mean for these registers? Arent registers like "0x34" and not "0x34a3"?

 

Indeed, this seems to indicate that a small tweak is needed get the Linux code to support the 9570.

There is a patch in the discussion that applies to dell-smm-hwmon.c ( https://github.com/torvalds/linux/blob/master/drivers/hwmon/dell-smm-hwmon.c), towards the bottom where they basically have a list of Dell devices or classes of devices spelled out. Unfortunately, the code for the Windows Dell SMM IO driver that we have ( https://github.com/424778940z/bzh-windrv-dell-smm-io/tree/master/bzh_dell_smm_io) doesn't seem to have anything that corresponds to this.

I'm mostly stringing together work done by others here, I've never done any low-level driver stuff, so I'm basically at a loss.

 

@Aaron44126 I spoke to a Linux 9570 owner, the one from the patch discussion link, and he says, that the dell-smm-hwmon works fine under Linux to disable the EC fan control on the 9570, but only if you use the "force=1" option, which this Windows driver seems to lack.

I looked into the windows driver port, and I guess this part fails:

https://github.com/424778940z/bzh-w...aster/bzh_dell_smm_io/bzh_dell_smm_lowlevel.h

// did it work ?
if ((sc->cmd == cmd && sc->data == data && sc->stat1 == stat1 && sc->stat2 == stat2) // function not supported
|| ((cmd & 0xffff) == 0xffff)) // or invalid device
status = 0;

maybe? So it thinks the 9570 is not a supported device, for whatever reason maybe and doesnt load the driver, even it might work? Could you maybe implement a force option to skip this check?

 

I haven't tried to build the driver yet (I've just been working with the binary files attached to the very first post of this thread). But, I see there is a Visual Studio solution file there, so assuming that I can just open it up and easily build it from source, I can produce a version that skips this check entirely and we can see how that goes.

[Edit]
It's not a clean open-and-build. I got through the first few build errors (having to include Windows Driver Kit stuff) but more keep coming. Currently blocked on one claiming that I do not have Windows kernel-mode driver build tools installed, even though I do have the WDK installed. Not sure how deep I'll go with this.

 

Scheduled tasks for automatic fan control.

This is what I have found that works...

1. Disable EC fan control at login.
I made a task with "At log on" of "specific user" (myself). It runs this script.

Code:

@ECHO OFF

ECHO Waiting for SpeedFan...
START "" /B "C:\Program Files (x86)\SpeedFan\speedfan.exe"
sleep 75
DellFanCmd.exe ec-disable
pause

This basically starts SpeedFan, waits 75 seconds (plenty of time for it to load all of the sensors and get ready to go), and then disables EC fan control. SpeedFan takes over right away. I have SpeedFan configured to start minimized.
Note, the "sleep" command is not built in to Windows. You can get it by installing the Windows Server 2003 resource kit. https://www.microsoft.com/en-us/download/details.aspx?id=17657
The "pause" command just adds a "press any key to continue" prompt before the command window goes away. So, I can see the output of DellFanCmd before it automatically disappears.

The solution survives sleep but it does not survive hibernate. So...
2. Disable EC fan upon resume from hibernate.
I made a task with "On an event" trigger. It is set to run only if I am already logged in. The event is, Log: System, Source: Kernel-Power, Event ID: 107. It just runs: DellFanCmd.exe ec-disable
(SpeedFan is already running.)

3. Return fan control to the EC upon logout.
The trickiest one. There's no clear event to trigger off of for logout. Also, I want to make sure that it is only when *I* log out and not other users (I'm not the only one who uses my laptop).

I ended up with this. A task set to run "whether or not I am logged in", with a custom event filter trigger:

Code:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">
        *[System[Provider[@Name='Microsoft-Windows-Winlogon'] and (EventID=7002)]]
        and
        *[EventData[Data[@Name='UserSid'] and (Data='S-1-5-21-1686773459-1707497739-4133313906-1001')]]
    </Select>
  </Query>
</QueryList>

This captures a logout event entered by Microsoft's Windows telemetry service. The Data='S.....' is my Windows account SID. You'll have to adjust it for your own SID.
It just runs: DellFanCmd.exe ec-enable


When setting up scheduled tasks, pay attention to the option that is enabled by default which prevents them from running if the system is on battery power. All tasks need to be set to run with "highest privileges".

[Edit]
For #3, I also added it to the "Shutdown script" (gpedit -> Windows settings -> Scripts) because the scheduled task will (sometimes?) fail when the system is shutting down or rebooting.

 

Gentlemen:

Sorry to be behind here -- have errands/chores today. When I get back, I'll try the new version on mny 9360 (i7 8550 -- 8th Gen, I believe, but in the older Dell chassis . . . and mainboard?). I can also test this on my 9560, which is one generation older than Maffle's machine (7th Gen, I think, i7 7700HQ).

Will report as soon as I do so. Meanwhile, best of luck with the 70 series fix. It'd sure be nice if that proves to be possible.

Mike

 

I just tried it on a Dell Precision 7510 (6th gen) and was not able to get the driver to load. Cut-off point may be older than I thought... I reviewed the thread again and found @alexhawker's comment that it hasn't worked with any machines in the last six years, but then I saw other posts stating that it works with the Precision 5520 and XPS 9550, which aren't that old.

Side note, if anyone finds that the "Dell fan utility" (GUI app) works but the console app doesn't, then there is still some sort of bug in the console app, I'd be interested to know that.

 

Aaron:

Second Beta Report -- based on the second command line utility posted.

Overall, tantalizingly close . . . but not yet.

First, I ran the utility manually this time with admin privileges with testsigning off, and it does both grab control of the fans, and does run them up to 100% (using the first ec-disable command).

Here's the cmd line story:



It looks like success, particularly if the error is because there's only one fan in the machine.

But, Speedfan not only doesn't grab control, it seemed to go rouge -- it lost track of everything, dumped the existing fan profiles and reported a temp of 88c -- Throttlestop said 26. Here's a shot of that strange abomination:



Notice that you don't see any of the usual stuff here -- no cpu temps, not fan control option, no up/down arrows. The green temp is Throttlestop package temp -- the 88c is Speedfan gone wild.

Couple of reboots and some work with the old GUI with testsigning on recovered more useful control of the fans (i.e., not continuously running at 100%), and some checking in Speedfan revealed the the "Dell Control" check box in options had been cleared. What?? How'd that happen?

It's vaguely possible that I somehow screwed that up, but I don't think so. I did turn off debug and uncheck ISA yesterday, as neither seemed to be needed (just experimenting around). MAYBE I had a slip of the mouse? Didn't notice it in use this AM, so I don't think it was me, but it's not beyond possibility -- the machine was mostly at idle. Took a while to rebuild the fan profiles and such from scratch, so I'll wait to hear from you before I try again. I'm well out of my depth here on causes, though I'm enjoying your exchange with Maffle on the general topic. But if I just need to try again, I'm game.

Given that we now know you can grab control and run the 9360's fan up to 100%, I think this is successful as proof of concept, and a learning step on the exchange/interface with Speedfan -- whether for you or for me is not yet clear. Entirely possible I did something stupid. Should be around tomorrow with a cold rain out -- so will await word and then get at it.

This looks very much like it can be made to work up to at least the 9360 (Fall 2017) with the i7 8550 U Quad Core. Once we get that working, I'll try the 9560 for you.

Best,
Mike

 

Oh wait . . . I forgot. I uninstalled the C++ setup yesterday just to get back to the initial condition. Should I try again with that?

Also, Speedfan had accurate temps for each core before, tracking HWMon. Now it's reporting individual core temps like 11 C, which is way off. I could set offsets, but that's another oddity.

Hmmm . . .rechecked ISA and debug options again in speedfan, and I see Speedfan apparently making use of them -- so maybe I did something dumb here, and then just didn't notice?

Embarrasing . . . shouldn't mess with things I don't understand?

Could always just blow Speedfan away, reinstall and reconfigure . . .

Mike

 

First off, it shouldn't matter if you uninstalled the Visual C++ runtime, if there was an issue with that then the program would not even run.

Next, if the program goes out of whack, a full shutdown should reset everything back to normal. Also, visit Windows Power Options / "Choose what the power buttons do" (on the left) and make sure that fast startup is disabled while working on this. If you don't do this, a shut down actually just performs a logout+hibernate and it could leave behind some residual stuff.

The only thing that I can think of, really, is that issuing a command regarding the non-existent fan threw things out of whack somehow. I didn't really think about the fact that some of these systems are single-fan. All of the systems that I have access to are dual-fan.

So, here is what I suggest. I'm leaving a build here that will leave the second fan alone. Give it a try and see if things are different. If you run into the same problem, fully shut down the system (not just a reboot). Try again with the "alternate" method. If either method works, I'll see about either dynamically detecting how many fans there are or adding a command line option to specify it if I can't figure that out. (Curious, what does the GUI app look like in your case, does it indicate that the second fan is missing?)

Not sure what to make of SpeedFan temperature reporting. Obviously, other apps are able to read the proper temperature. I've been messing with it lots today, including doing things like turning EC control on and off on the fly while SpeedFan is attempting to manage the fans, and I haven't run into anything like this.

[Edit] Binary removed, see https://github.com/AaronKelley/DellFanCmd/releases

 

Morning Aaron:

This is excellent. I have a new test subject, and useful experiments to work on. Will do as you advise. And will likely conduct some experiments to see if something I did screwed up Speedfan somehow (following which I pledge to stop introducing stray variables into the experiment until we're done).

After a first test on the one-fan variant, I'll likely reinstall Speedfan and see what happens. Set up offsets for the fans last night (I often find the Speedfan reports different values than the BIOS does on desktop machines, so that's familiar). Everything seems to work fine. But the result when I ran your second version was . . . out there.

Therefore, after I do all that, I'll run the dual fan version again and see if the error is repeatable. That should tell us what we need to know. That may also take a bit of time, as I could well have to rebuild Speedfan profiles a couple of times.

Will report back when that's all done. And if the "one fan" version works, I'll give you and early report on that just so you know where we're headed.

 

@Aaron44126 Any news on building the driver? I actually hate it btw, if devs put up crippled projects and you cant compile it and have to find out why. Especially c++ Windows projects are mostly a mess. Also I dont think it has to do with "cut off time", if it works on the 9560.

 

I haven't had time to dig any deeper (probably will be a couple of days there). It's kind of sad that it isn't set up for "open and build" but I think the expectation here is that you would know a thing or two about driver development before you make the attempt (which I don't, really) ... It's more a matter of getting Visual Studio set up properly with the WDK than anything else. In any case, if we didn't have this code, this project wouldn't have gotten off the ground.

I was wondering if you could attempt this. This is manually loading and starting the driver from outside of the app. It probably won't work on your system but I'm wondering if any additional interesting error information will pop out. (If you're using the bzh_dell_smm_io_x64.sys file that I signed, you don't need to be in test signing mode or anything.)

Open an administrative command prompt and run the command:
sc create dellsmm type=kernel binpath=" C:\Full\path\to\bzh_dell_smm_io_x64.sys"
(replace the underlined bit)

Then:
sc start dellsmm

You're supposed to get output like:

Code:

SERVICE_NAME: dellsmm
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 0
        FLAGS              :

...But I expect that it will error on your system and I want to see if it gives any error details.

To clean up afterwards:
sc stop dellsmm
sc delete dellsmm

 

Aaron:

Check your PM. Your one fan version appears to work. Longer report there so we don't overly clutter the thread.

Oh, and in answer to your earlier question, I'll check again, but my recollection is that the second fan slider just bounces back to the left (much as I described to Maffle up the thread) and does nothing. But the CPU fan slides normally and controlled the fan. Don't take that to the bank until I check. If useful and I forget, feel free to remind me . . .

Mike

 

It would be odd if my app kills SpeedFan but the GUI app doesn't. I was wondering if I should borrow its "detect second fan" logic if it has any... I don't remember seeing anything like that though.

 

@Aaron44126 It says, it cant start the service because there is something wrong with the digital signatur, error 577 ( Windows cannot verify the digital signature for this file):

C:\Programme (frei)\DellEC>sc start dellsmm
[SC] StartService FEHLER 577:
Die digitale Signatur dieser Datei kann nicht überprüft werden. Möglicherweise wurde durch eine kürzlich durchgeführte Hardware- oder Softwareänderung eine falsch signierte oder beschädigte Datei oder eine Datei, bei der es sich um böswillige Software aus einer unbekannten Quelle handelt, installiert.

Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software form an unknown source

So it doesnt even try to load it, because of the signatur not being trusted. Didnt you say you signed it? Right click on it it says it is signed by Aaron Kelley.

https://i.imgur.com/4GINvtE.png

Disabling signed driver check it starts and just says:

C:\WINDOWS\system32>sc start dellsmm
SERVICE_NAME: dellsmm
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :

Didnt change anything though

C:\Programme (frei)\DellEC>DellFanCmd.exe ec-disable
DellFanCmd PRE-RELEASE BUILD
Loading SMM IO driver...
Failed.
C:\Programme (frei)\DellEC>DellFanCmd.exe ec-disable-alt
DellFanCmd PRE-RELEASE BUILD
Loading SMM IO driver...
Failed.

 

Strange on the signature thing. You are right, I had the file signed, and I'm not having any trouble loading it with the same command (and also not in "test signing" or "disable driver signature enforcement" mode).

So it works if you load it manually but not if the program tries to load it. (Signature issue aside.) It might be possible to manually load the driver and then have the program use that. (It does not attempt that right now, it will bail if the load fails.)

 

I'm now suspecting that the driver is loading but some step that the program attempts after the driver load is failing. I produced a new build with more verbosity around the SMM IO driver loading. Can you please try it and let me know what the output is. Depending on how far you get before things differ, that will give a hint of where to check next. (Do it in "disable driver signature enforcement" mode because there appears to be an issue with the signature on your system.) Here is the output from a successful run:

Code:

DellFanCmd PRE-RELEASE BUILD (verbose)

Loading SMM IO driver...
    Check to see if driver is running already
    Load driver
      Remove previous instance
      Create service
    Start driver
      Open SC manager
      Open service
      Start service
    Get handle to driver
    All good!
 ...Success.
Attempting to disable EC control of the fan...
 ...Success.
Setting fan 1 speed to maximum...
Setting fan 2 speed to maximum...
Unloading SMM IO driver...
 ...Done.

Also, to be clear, are you using Windows 10 or something older?

[Edit] Binary removed, see https://github.com/AaronKelley/DellFanCmd/releases

 

@ Aaron44126 C:\Programme (frei)\DellFanCmd-Verbose>DellFanCmd.exe ec-disable
DellFanCmd PRE-RELEASE BUILD (verbose)
Loading SMM IO driver...
Check to see if driver is running already
Load driver
Remove previous instance
Create service
Failed.

Yes, run as admin. Windows 10 64bit (1809) of course.

 

Ok, interesting. To be clear, you tried that with test signing on or driver signature enforcement disabled?

Please try these commands.

sc create BZHDELLSMMIO type=kernel binpath=" C:\Full\path\to\bzh_dell_smm_io_x64.sys"
sc start BZHDELLSMMIO
DellFanCmd ec-disable

The first two are the same as before but with a different service name. This is the name that the app uses when it loads the driver. It will detect that it is already running and won't try to start it again. I tested this on my machine and it worked. It shortcuts a good bit of the driver load procedure.

Code:

Loading SMM IO driver...
    Check to see if driver is running already
    All good!
 ...Success.
Attempting to disable EC control of the fan...
 ...Success.
Setting fan 1 speed to maximum...
Setting fan 2 speed to maximum...
Unloading SMM IO driver...
 ...Done.

If it does not work, please clean up afterwards with:
sc stop BZHDELLSMMIO
sc delete BZHDELLSMMIO
(A successful run will actually stop and delete the driver/service automatically, even if it was already running before you started.)

 

C:\dellfan>DellFanCmd.exe ec-disable
DellFanCmd PRE-RELEASE BUILD (verbose)
Loading SMM IO driver...
Check to see if driver is running already
Load driver
Remove previous instance
Create service
Start driver
Open SC manager
Open service
Start service
Failed.
C:\dellfan>sc delete BZHDELLSMMIO
[SC] DeleteService ERFOLG

Doesnt seem so. Why doesnt it clean up afterwards? So I have like a couple of broken driver services registered? Why does the signed driver does not work though for me, I have to disable secure boot again and disable driver check first.

So after disabling secure boot and driver check... and manual service creation...

C:\dellfan>sc create BZHDELLSMMIO type=kernel binpath="C:\dellfan\bzh_dell_smm_io_x64.sys"
[SC] CreateService ERFOLG
C:\dellfan>sc start BZHDELLSMMIO
SERVICE_NAME: BZHDELLSMMIO
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
C:\dellfan>DellFanCmd ec-disable
DellFanCmd PRE-RELEASE BUILD (verbose)
Loading SMM IO driver...
Check to see if driver is running already
All good!
...Success.
Attempting to disable EC control of the fan...
...Success.
Setting fan 1 speed to maximum...
Setting fan 2 speed to maximum...
Unloading SMM IO driver...
...Done.
C:\dellfan>

Ec auto control is now off it seems, so it looks like the driver worked all the long on the 9570, but not creating the service through the tool... and through yours too. Just manual creating seems to work. Controling the fans though through the tool also doesnt work.

C:\dellfan>DellFanCmd.exe ec-enable
DellFanCmd PRE-RELEASE BUILD (verbose)
Loading SMM IO driver...
Check to see if driver is running already
Load driver
Remove previous instance
Create service
Start driver
Open SC manager
Open service
Start service
Get handle to driver
All good!
...Success.
Attempting to enable EC control of the fan...
...Success.
Unloading SMM IO driver...
...Done.
C:\dellfan>DellFanCmd.exe ec-disable
DellFanCmd PRE-RELEASE BUILD (verbose)
Loading SMM IO driver...
Check to see if driver is running already
Load driver
Remove previous instance
Create service
Start driver
Open SC manager
Open service
Start service
Get handle to driver
All good!
...Success.
Attempting to disable EC control of the fan...
...Success.
Setting fan 1 speed to maximum...
Setting fan 2 speed to maximum...
Unloading SMM IO driver...
...Done.
C:\dellfan>

That is working too now.

 

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.

 

@ Aaron44126

I can confirm the "self-signed" / bought certificate driver loads correctly even with secure boot on if you set

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy]
"UpgradedSystem"=dword:00000000

The question then is if you need secure boot on anyway, if it is "pass by". Secure boot is false security anyway as I see it.

The self signed driver is though just valid for 1 year?

 

Thanks for that discovery.

Secure boot is indeed a bit of a false sense of security. This setting change allows you to load (signed) kernel code into the system that isn't necessarily "trusted" by Microsoft (that is what the EV certificate is for). However, leaving secure boot on will still have the BIOS check the signature on the Windows bootloader and the bootloader will check the signature on the kernel, so, malware targeting those should still be thwarted. Driver files are signed so they can't be modified without being re-signed (and that means an attacker at the very least would have to pay for a certificate or compromise a CA). And indeed, this is how things worked prior to Windows 10 1607.

It's sort of a trade-off, but in my case I plan to leave it in this configuration (allowing cross-signed drivers without requiring EV certificate), because if I want to load my own custom driver on my own computer, I should be allowed to do so.

(I have another custom driver that I have recently produced for an old piece of USB audio input equipment that doesn't work on newer versions of Windows, and it will be subject to the same rules. I still haven't written driver code, this one involved copying/signing old Windows XP USB driver system files and packaging them up to work with Windows 10.)

The driver is not self-signed, I did purchase a certificate from a CA so it is properly signed. (A terminology thing, "self-signed" refers to a certificate/signature that doesn't have any trust from a CA.) The certificate is valid for one year. This only means that once the year is up, I will not be able to use it to sign files anymore. Files already signed will still be trusted and continue to work, because they also contain a trusted signed timestamp. (That is the "countersignature" thing you may see if you look at the file properties in Explorer.)

 

Gents:

My apologies for not checking in to answer, but as it happens, I've been testing this morning. It my continuing role as the dedicated clueless user in the crowd, here's what I believe I have established.

1. The initial problem I had with Aaron's 2nd beta (the one that fixed the missing *.dlls issue) was entirely my fault, as you'll see here in a sec.

2. Suspecting my own foolishness, I restored the "stupid user" settings back to their standard set up -- in Speedfan's "options" tab, DO NOT uncheck the ISA communications box -- unchecking debug seems OK. And since whatever I did kicked Speedfan out of "Dell Mode," I rechecked that box. Further testing this AM clearly establishes that this allows Speedfan to see multiple additional sensors, so if Maffle is testing with Speedfan for diagnostic purposes, be sure to check that.

3. Because Aaron was kind enough to immediately provide a "one fan" version, and because we wanted to use that diagnostically, I tried that first, starting Speedfan, then running the ec-disable command manually in an elevated prompt. Worked first time.

4. Then came my trial. I now re-ran the second beta (the two fan version) to see if that would break Speedfan now that I had it back to standard configuration. Nope. Runs perfectly. Running it manually, it reports an error on the second fan (the 9360 only has one fan), but it still works perfectly. For now, I'm using the one fan version just to eliminate the additional variable, but both versions work perfectly.

5. This morning I uninstalled Speedfan, cleared related registry values manually (just to be sure), and reinstalled. I did this because after my self-imposed Speedfan crash, Speedfan, which had always tracked perfectly with the HWInfo tool before, now suddenly started reporting temps that were low by about 15 C. This is for the individual cores reported by what appear to be Intel sensors. And I could now see (after re-checking the "Dell" box in options) SSD and a DIMM sensors, but SSD temp was also low by a what appeared to be a slightly greater margin.

Upon reinstall, I got exactly the same result as that prior to the reinstall. But Speedfan has the ability to set offset temps under "configure" on the "advanced" tab, so I just fixed it that way. No idea why it's suddenly needing the correction, but once you make the adjustments, everything seems to work normally.

6. I have set up and tested the first Task Aaron specified for Task Manager for the log-on case (that much I figured out for myself), and can confirm that it works perfectly. Still going to test the others, and will report back.

7. As luck would have it, I was just testing modes before checking in here. I can confirm that the tool works in Windows "normal" state -- test signing off, etc. And, better yet, I just turned secure boot back on that that works too.

8. At present the only remaining glitch on my hardware is the stupid backlight level bug. ClickMonDDC, reported as a workaround on the first couple of pages of the thread, is a nice little piece of work, and works -- for a while. Then it fails. Here's the whacky thing with that. When I figured out that you could use the GUI tool, then disable testsigning and warm reboot to normal mode without re-running the Dell Gui Tool, EVERYTHING worked.

So I temporarily disabled the taskmanager task that runs Aaron's tool at log in, and warm rebooted -- just to check. And guess what -- that still works. F11/F12 now control fans, and though I'll continue testing, that control seems not to fade with time and sleep evolutions. So if you're willing to boot twice . . . which is ridiculous.

Would love to help chase and squash this bug, but am enjoying watching you guys wrestle the 9570 to the ground, so I'm happy to wait. Looks like you've made a great deal of progress.

Let me know if you need me to check anything else. Can check the 9560 when that makes sense, but as there seem to be plenty of dual fan machines about, I'm guessing that can wait.

Will try to check this a tad more often so that I don't hold up progress.

Mike

 

I have published the code at https://github.com/AaronKelley/DellFanCmd.
There is a final release available, you can download the binary at GitHub under "Releases".

A few changes:
* An additional option to leave the fans alone (ec-disable-nofanchg, ec-disable-alt-nofanchg) — A warning will be printed instead
* Attempt to clean up the driver after a failed load
* Better error messages regarding driver load failure or second fan not present

I'm going to make some setup directions and I will post those later in a new thread.

 

So does that mean you and Maffle managed to beat the 9570 issues? Looked like you were close, at the very least. This is great work as is, but it's going to get more traction, particularly over time, if it works on Dell's latest.

Mike

 

Yes, it is working on the 9570.

I made this thread specifically for this tool, with full setup information.
http://forum.notebookreview.com/thr...ual-custom-control-of-the-laptop-fans.827106/

 

Aaron: Nice work. Great to hear that it works for all concerned. Will test the production version when I get a sec.

 

I have a question, does this program require any dependencies (eg runtimes) for it to function?

I'm currently interested in testing it for the Latitude E6540 running on Windows 10 1803. In addition, I've added the register key mentioned in the guide posted above and have disabled UEFI secured mode in the bios for the measure.
The current observation is the following: When trying to launch it, using admin privileges ofcourse, it closes immediately. I have no clue what the cause might be.

 

It is a command line app and you must run it from the command line (or you will not be able to see anything).