Get CPU Fan Speed and CPU Temp

  • Thread starter Thread starter Mike C#
  • Start date Start date
M

Mike C#

Hi all, anyone know if there are any Windows functions to retrieve CPU Fan
Speed and CPU Temp? Or if it's a BIOS-level call, or something else? If
someone out there could just point me in the right direction it would be
appreciated.

Thanks!
 
William DePalo said:
Windows Management Instrumentation (WMI) may help you. Go here

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_classes.asp

and then scroll down to the Win32_Fan class. Good luck.
Click to expand...

Thanks Will, I was just browsing the WMI and ACPI documentation. I'll have
to do some more research, as this has to be done in both unmanaged code and
must be backwards compatible with some older systems we seem to have lying
around here. I wish it were just a simple BIOS or Windows INT call to get
this info!

Thanks
 
Mike C# said:
Thanks Will,
Click to expand...

You are welcome.
I was just browsing the WMI and ACPI documentation. I'll have to do some
more research, as this has to be done in both unmanaged code and must be
backwards compatible with some older systems we seem to have lying around
here.
Click to expand...

I should point out that I have no idea if the .Net framework has any support
for WMI. But if it turns out you need to access a COM based API from managed
code you'll find there is enough expertise to help you with that in this
group.
I wish it were just a simple BIOS or Windows INT call to get this info!
Click to expand...

I wish Ferraris were cheap. :-)

Seriously, I've not had an on-the-job need to use WMI, but my experiments
with it have resulted in less than stellar results. I suggest that you try
on your systems some samples known to work elsewhere before you start
writing code.

Regards,
Will
www.ivrforbeginners.com
 
William DePalo said:
I wish Ferraris were cheap. :-)
Click to expand...

But then we wouldn't want them :)
Seriously, I've not had an on-the-job need to use WMI, but my experiments
with it have resulted in less than stellar results. I suggest that you try
on your systems some samples known to work elsewhere before you start
writing code.
Click to expand...

Yes, this is my first foray into WMI as well. I've found that you do need
COM to access it in unmanaged code, and I've built a little sample that
allows me to use WQL (WMI Query Language) to retrieve some data. I created
a little C++ wrapper class that creates the COM object and initializes WMI
in its constructor, and gets rid of it in the destructor. Then I figure I
can expose some methods that return exactly what I want (fan speed, CPU
temp., etc.) I've tested it with a few WQL queries and can retrieve some
information like printers, logical disk drives, etc., etc.

So far so good.

The issue now is that, while I can get all this other information I don't
need, I can't seem to get the information I actually do need :) I've tried
querying Win32_Fan, Win32_TemperatureProbe, CIM_Sensor and
CIM_NumericSensor. It doesn't error out, but it consistently fails to
return any results. I think it may be a security issue? But not sure...

I'm going to post this response over to the WMI groups as well, in the hopes
that someone out there might have an idea. I can post my code if necessary
also (about 150 lines).

Thanks!
 
William DePalo said:
You are welcome.


I should point out that I have no idea if the .Net framework has any support for WMI. But
if it turns out you need to access a COM based API from managed code you'll find there is
enough expertise to help you with that in this group.
Click to expand...

Yes, .NET exposes WMI through the System.Management namespace.
But, in order to expose such system properties via WMI you need a WMI provider in the form
of a WMI compliant OEM device driver, MS does not provide any such drivers. Some high-end
system vendors provide this as part of their system management software, but most others (if
not all) system vendors do not provide such driver.
I wish Ferraris were cheap. :-)

Seriously, I've not had an on-the-job need to use WMI, but my experiments with it have
resulted in less than stellar results. I suggest that you try on your systems some samples
known to work elsewhere before you start writing code.
Click to expand...

Each windows system since W2K, comes with a UI based utility called wbemtest.exe which
allows you to query the WMI namespace without you writing a single line of code.


Willy.
 
Willy Denoyette said:
Each windows system since W2K, comes with a UI based utility called
wbemtest.exe which allows you to query the WMI namespace without you
writing a single line of code.
Click to expand...

Hi Willy,

I've tested with wbemtest.exe and I get the same results I get in my code.
I can query some WMI objects like disk drives, printers, etc., but not the
ones I need like fan speed and cpu temp. Querying the latter doesn't error,
but it returns no results.

Thanks
 
Mike C# said:
Hi Willy,

I've tested with wbemtest.exe and I get the same results I get in my code.
I can query some WMI objects like disk drives, printers, etc., but not the
ones I need like fan speed and cpu temp. Querying the latter doesn't
error, but it returns no results.

Thanks
Click to expand...

You might want to see if speedfan gives you the right results.
(http://www.almico.com/speedfan.php)

It uses giveio.sys to access the hardware directly and retrieve the results.

Fact is, it really isn't more difficult than a BIOS call (ACPI supports some
monitoring, for example) or I/O, but those operations are forbidden to
Windows applications. You need a device driver to run privileged code.
 
Mike C# said:
Hi Willy,

I've tested with wbemtest.exe and I get the same results I get in my code. I can query
some WMI objects like disk drives, printers, etc., but not the ones I need like fan speed
and cpu temp. Querying the latter doesn't error, but it returns no results.

Thanks
Click to expand...

Mike,
That's exactly what I was expecting, most system vendors (or MOBO vendors) do not provide a
device driver that exposes these properties to WMI (stuff like temperature probes, current
and voltage probes etc...), the classes are in the repository but the implementation is
missing. Some of them provide NON WMI compliant device drivers and most, if not all, do not
publish the BIOS API's.

Willy.
 
Ben Voigt said:
You might want to see if speedfan gives you the right results.
(http://www.almico.com/speedfan.php)

It uses giveio.sys to access the hardware directly and retrieve the
results.

Fact is, it really isn't more difficult than a BIOS call (ACPI supports
some monitoring, for example) or I/O, but those operations are forbidden
to Windows applications. You need a device driver to run privileged code.
Click to expand...

Thanks Ben, I looked at SpeedFan, MBM5, and a few others. Unfortunately it
appears the authors don't like to release their source code.
 
Willy Denoyette said:
Mike,
That's exactly what I was expecting, most system vendors (or MOBO vendors)
do not provide a device driver that exposes these properties to WMI (stuff
like temperature probes, current and voltage probes etc...), the classes
are in the repository but the implementation is missing. Some of them
provide NON WMI compliant device drivers and most, if not all, do not
publish the BIOS API's.

Willy.
Click to expand...

Well that's a kick in the pants. I was sort of hoping this would be one of
those nice and easy things, but it seems like nothing in Windows ever is...
 
Mike C# said:
Thanks Ben, I looked at SpeedFan, MBM5, and a few others. Unfortunately
it appears the authors don't like to release their source code.
Click to expand...

You might also check whether there is a linux driver for your motherboard,
the source code for that would be available. Or you might ask on the
lm_sensors mailing list whether anyone has the datasheet information and is
not bound by a non-disclosure agreement.

The source code for giveio.sys is available I think, and even if not you
should be able to find the API. The problem is that there may be multiple
incompatible versions of giveio floating around the 'Net.
 
Ben Voigt said:
You might also check whether there is a linux driver for your motherboard,
the source code for that would be available. Or you might ask on the
lm_sensors mailing list whether anyone has the datasheet information and
is not bound by a non-disclosure agreement.

The source code for giveio.sys is available I think, and even if not you
should be able to find the API. The problem is that there may be multiple
incompatible versions of giveio floating around the 'Net.
Click to expand...
I actually found some Linux sample apps, problem is that Linux has built-in
functions for retrieving this information and apparently Windows doesn't.
So now I'm trying to locate the Linux source code for those built-in
functions :)

I'll also look around for giveio.sys.

Thanks!
 
Mike C# said:
I actually found some Linux sample apps, problem is that Linux has
built-in functions for retrieving this information and apparently Windows
doesn't. So now I'm trying to locate the Linux source code for those
built-in functions :)
Click to expand...

Which particular chip is it?
 
Ben Voigt said:
Which particular chip is it?
Click to expand...

Which one? I have about 2,000 machines with different motherboards,
different CPU's and different versions of Windows (2000, 2000 Server, XP,
2003 Server; even some NT 4).
 
Which one? I have about 2,000 machines with different motherboards,
different CPU's and different versions of Windows (2000, 2000 Server, XP,
2003 Server; even some NT 4).
Click to expand...

Here's the problem: there's NO standard for that info. Every MB
maker does things differently. Only if MS tossed their monopoly powers
around and said "we're going to need this info - write a driver that
provides it or you don't get to put 'Ready for Windows' on the box"
would there be a chance of this being easily queryable. In things
that would be *useful*, MS won't do this. (See also: caps bits in
DirectX 1-9, when they should have been forced out a long time before
DX10).

Nathan Mates
 
Nathan Mates said:
Here's the problem: there's NO standard for that info. Every MB
maker does things differently. Only if MS tossed their monopoly powers
around and said "we're going to need this info - write a driver that
provides it or you don't get to put 'Ready for Windows' on the box"
would there be a chance of this being easily queryable. In things
that would be *useful*, MS won't do this. (See also: caps bits in
DirectX 1-9, when they should have been forced out a long time before
DX10).

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Click to expand...


This is not only a MOBO issue, all CPU's (say Intel, AMD, ...) may expose things
differently, some CPU models have a temperature probe on-die, others do not, some have one
probe per core. Some CPU models do expose the temperature and trip points, some do only
expose the trip points, this can even change from one rev. to another (same CPU SKU). This
is especially troublesome for the BIOS vendors and you should not rely on them to keep pace
with all this.
So the only way to get at the info is to read the CPU registers from within a device driver,
but now the driver implementer has to deal with all these issues. Most system vendors like
HP, IBM etc..., have this pretty well under control for their high end and their portable
system , but don't care that much for their consumer products.

Willy.
 
Willy Denoyette said:
This is not only a MOBO issue, all CPU's (say Intel, AMD, ...) may expose
things differently, some CPU models have a temperature probe on-die,
others do not, some have one probe per core. Some CPU models do expose the
temperature and trip points, some do only expose the trip points, this can
even change from one rev. to another (same CPU SKU). This is especially
troublesome for the BIOS vendors and you should not rely on them to keep
pace with all this.
So the only way to get at the info is to read the CPU registers from
within a device driver, but now the driver implementer has to deal with
all these issues. Most system vendors like HP, IBM etc..., have this
pretty well under control for their high end and their portable system ,
but don't care that much for their consumer products.
Click to expand...

Too bad the worst-case scenario isn't just a standardized BIOS call.
Digging up all the info on these different mobos is going to be tough,
although finding the tech. specs. on the CPU's themselves shouldn't be *as
hard* since there are far fewer processor manufacturers and processors than
there are mobos. Well, I guess it's time to start doing all that crazy
research I was trying to avoid in the first place :(
 
This is not only a MOBO issue, all CPU's (say Intel, AMD, ...) may
expose things differently, some CPU models have a temperature probe
on-die, others do not, some have one probe per core. Some CPU models
do expose the temperature and trip points, some do only expose the
trip points, this can even change from one rev. to another (same CPU
SKU). This is especially troublesome for the BIOS vendors and you
should not rely on them to keep pace with all this.
Click to expand...

That's what I said in my previous email. I also noted that if
someone (Microsoft, with a little legitimate and useful use of its
monopoly powers) would crack heads, the BIOS venders would do this
work. Even if you think that reading in CPU temps changes "too much"
(something I disagree with -- it's not too hard to support every CPU
available on release), reading in fan speeds is something that BIOS
makers *SHOULD* have 100% control over. The # of fan connections on
a MB doesn't just up and change behing the BIOS maker's back.

Nathan Mates
 
Nathan Mates said:
That's what I said in my previous email. I also noted that if
someone (Microsoft, with a little legitimate and useful use of its
monopoly powers) would crack heads, the BIOS venders would do this
work. Even if you think that reading in CPU temps changes "too much"
(something I disagree with -- it's not too hard to support every CPU
available on release), reading in fan speeds is something that BIOS
makers *SHOULD* have 100% control over. The # of fan connections on
a MB doesn't just up and change behing the BIOS maker's back.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Click to expand...


You seem to over-estimate MS powers, and under-estimate the costs of this all.
Anyway, it's not enough to support CPU's at release, what if someone replaces a CPU with
another CPU type on the same MOBO- most new mobo's can accommodate different CPU's types
that weren't even available at the release date of the mobo/BIOS- this requires a BIOS
upgrade to be made available for each new CPU type and possibly each revision level .
As an example take the AMD Athlon X2, the first revs. did not expose the temperature counter
in one of it's registers (see CPUID), only some of the tripping points. The temperature
probe was directly diving the CPU fan circuitry, the tripping points being used to lower the
core voltage or break the power, later revs. did expose the temperature in one of the
registers (a couple of bits), that means you have to upgrade the BIOS with this new CPU rev.
But who's gonna make such upgrade available in a timely fashion? (again don't over-estimate
the powers of MSFT), another point is that the vendors drivers (smbios.sys or Acpi drivers)
must also be made available for this new CPU/BIOS tandem. Now take Vista as a sample, most
mobo vendors did not (yet?) port their drivers to Vista, the result is that you can't get at
the temperature on Vista unless you buy a Vista ready mobo/system.
As I said previously, some system vendors have this pretty much under control, for their
high-ends (workstations/server), and provided you are covered by a maintenance contract, but
at the low-end you are nowhere unless you are willing to develop your own drivers (you don't
need the BIOS after all).


Willy.
 
Back
Top