Get CPU Fan Speed and CPU Temp

[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 [MVP VC++]]

"Mike C#" <xy*@xyz.comwrote in message
news:em**************@TK2MSFTNGP03.phx.gbl...

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.

Windows Management Instrumentation (WMI) may help you. Go here

http://msdn.microsoft.com/library/de...32_classes.asp

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

Regards,
Will

[Mike C#]

"William DePalo [MVP VC++]" <wi***********@mvps.orgwrote in message
news:ex**************@TK2MSFTNGP02.phx.gbl...

Windows Management Instrumentation (WMI) may help you. Go here

http://msdn.microsoft.com/library/de...32_classes.asp

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

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

[William DePalo [MVP VC++]]

"Mike C#" <xy*@xyz.comwrote in message
news:OR****************@TK2MSFTNGP06.phx.gbl...

Thanks Will,

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.

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!

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

[Mike C#]

"William DePalo [MVP VC++]" <wi***********@mvps.orgwrote in message
news:eO***************@TK2MSFTNGP04.phx.gbl...

I wish Ferraris were cheap. :-)

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.

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!

[Willy Denoyette [MVP]]

"William DePalo [MVP VC++]" <wi***********@mvps.orgwrote in message
news:eO***************@TK2MSFTNGP04.phx.gbl...

"Mike C#" <xy*@xyz.comwrote in message news:OR****************@TK2MSFTNGP06.phx.gbl...

>Thanks Will,

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.

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.

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 it were just a simple BIOS or Windows INT call to get this info!

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.

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.

[Mike C#]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:Oz*************@TK2MSFTNGP06.phx.gbl...

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.

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

[Ben Voigt]

"Mike C#" <xy*@xyz.comwrote in message
news:Of**************@TK2MSFTNGP03.phx.gbl...

>
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:Oz*************@TK2MSFTNGP06.phx.gbl...

>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.

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

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.

[Willy Denoyette [MVP]]

"Mike C#" <xy*@xyz.comwrote in message news:Of**************@TK2MSFTNGP03.phx.gbl...

>
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:Oz*************@TK2MSFTNGP06.phx.gbl...

>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.

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,
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.

[Mike C#]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>
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.

Thanks Ben, I looked at SpeedFan, MBM5, and a few others. Unfortunately it
appears the authors don't like to release their source code.

[Mike C#]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

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.

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...

[Ben Voigt]

"Mike C#" <xy*@xyz.comwrote in message
news:OH**************@TK2MSFTNGP02.phx.gbl...

>
"Ben Voigt" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>>
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.

Thanks Ben, I looked at SpeedFan, MBM5, and a few others. Unfortunately
it appears the authors don't like to release their source code.

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.

[Mike C#]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:ec****************@TK2MSFTNGP05.phx.gbl...

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.

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!

[Ben Voigt]

"Mike C#" <xy*@xyz.comwrote in message
news:uU**************@TK2MSFTNGP03.phx.gbl...

>
"Ben Voigt" <rb*@nospam.nospamwrote in message
news:ec****************@TK2MSFTNGP05.phx.gbl...

>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.

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 :)

Which particular chip is it?

>
I'll also look around for giveio.sys.

Thanks!

[Mike C#]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:eh**************@TK2MSFTNGP04.phx.gbl...

Which particular chip is it?

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).

[Nathan Mates]

In article <O1*************@TK2MSFTNGP04.phx.gbl>, Mike C# <xy*@xyz.comwrote:

>Which particular chip is it?

>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).

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

[Willy Denoyette [MVP]]

"Nathan Mates" <na****@visi.comwrote in message news:12*************@corp.supernews.com...

In article <O1*************@TK2MSFTNGP04.phx.gbl>, Mike C# <xy*@xyz.comwrote:

>>Which particular chip is it?

>>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).

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

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.

[Mike C#]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

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.

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 :(

[Nathan Mates]

In article <#L**************@TK2MSFTNGP04.phx.gbl>,
Willy Denoyette [MVP] <wi*************@telenet.bewrote:

>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.

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

[Willy Denoyette [MVP]]

"Nathan Mates" <na****@visi.comwrote in message news:12*************@corp.supernews.com...

In article <#L**************@TK2MSFTNGP04.phx.gbl>,
Willy Denoyette [MVP] <wi*************@telenet.bewrote:

>>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.

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

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.

[Ben Voigt]

> 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.

The BIOS maker isn't what you think, the company whose name is on it, like
AMI or AWARD. All BIOSes are customized to support the particular hardware,
and reading temps and stuff is part of that. Probably the only standard, is
the API for putting the readouts on the "hardware monitoring screen". So
the only "BIOS maker", as far as sensors are concerned, is the mobo
manufacturer. And yes, they usually do have some sort of standardized
protocols good for maybe several dozen models of motherboard, because the
vendor hardware monitoring software usually is the same download for quite a
few boards.

You should be able to read temps from the CPU in a fairly portable manner,
as there are only a couple different protocols -- but only the most recent
CPUs implement that at all. Hardware monitoring chips have to be dealt with
independently. It's probably going to be far cheaper for you to throw a few
grand at the developers of speedfan or mbm and license their existing code,
than to duplicate that effort yourself -- especially as that development is
probably going to mean a bunch of NDAs and non-competes that will cost you
just as much with lawyers.

[Willy Denoyette [MVP]]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:us**************@TK2MSFTNGP04.phx.gbl...

>> 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.

The BIOS maker isn't what you think, the company whose name is on it, like AMI or AWARD.
All BIOSes are customized to support the particular hardware, and reading temps and stuff
is part of that. Probably the only standard, is the API for putting the readouts on the
"hardware monitoring screen". So the only "BIOS maker", as far as sensors are concerned,
is the mobo manufacturer. And yes, they usually do have some sort of standardized
protocols good for maybe several dozen models of motherboard, because the vendor hardware
monitoring software usually is the same download for quite a few boards.

You should be able to read temps from the CPU in a fairly portable manner, as there are
only a couple different protocols -- but only the most recent CPUs implement that at all.
Hardware monitoring chips have to be dealt with independently. It's probably going to be
far cheaper for you to throw a few grand at the developers of speedfan or mbm and license
their existing code,
than to duplicate that effort yourself -- especially as that development is probably going
to mean a bunch of NDAs and non-competes that will cost you just as much with lawyers.

Ben, I'm not sure why you are replying to me, I'm not the OP and have no issues with this.
I'm working at HP, and I know perfectly well were to get the info from, I also know what a
"BIOS maker" is. But I also know, from my CPQ period, that things aren't that simple, during
a couple of years it was part of my job to keep track of this (ACPI and SMBIOS specs, Power
Management stuff) in order to develop CPQ's management suite for servers and networks. I'm
no longer a member of that team after the CPQ/HP merge, so I can't accurately comment on the
latest evolutions, all I know is that we extend the BIOS to publish this info (following the
smbios specifications through the smbios.sys driver interface) to the management software
that uses CIM (WBEM), or through direct access.
As I said earlier, we (and most other system vendors) do expose the counters to user space
for the latest system (PIV and later).
However, some counters are only available in some product lines, some counters are only
relevant for some systems depending on a number if criteria (especially power and thermal
zone management) , but also economic laws play an important role.

Willy.

[Ben Voigt]

Ben, I'm not sure why you are replying to me, I'm not the OP and have no

issues with this.

Sorry if I confused you, I was replying to the thread in general, not you in
particular. Looking back, I don't even think I quoted any of your text in
my post, so I should have replied to the parent.

[Mike C#]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:us**************@TK2MSFTNGP04.phx.gbl...

You should be able to read temps from the CPU in a fairly portable manner,
as there are only a couple different protocols -- but only the most recent
CPUs implement that at all. Hardware monitoring chips have to be dealt
with independently. It's probably going to be far cheaper for you to
throw a few grand at the developers of speedfan or mbm and license their
existing code, than to duplicate that effort yourself -- especially as
that development is probably going to mean a bunch of NDAs and
non-competes that will cost you just as much with lawyers.

Wow, now that's absolutely ridiculous that I need to "throw a few grand" at
some third party company or hire a bunch of lawyers and sign a bunch of NDAs
and non-competes just to write a very simple program that reads the CPU fan
speed and thermal probes.

Nah, I think I'll just research it myself.

Thanks.

[=?Utf-8?B?bHlubmNo?=]

"Mike C#" wrote:

>
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

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.

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...

In following this thread, I'm left with a big question: If it is available
in Linux, why can't we access it in windows? They solved the problem of
different MB, chips, Bios.

In looking at the Linux code, which I haven't completely examined, it
appears that they have simply developed a flat database that identifies where
to access the information.

I too thought this would be a simple process. I have found a commercial
program that accoomplishes this feat, but I have not been able to find the
info. for implimenting in visual studio.

If you find it please post it.

[Ben Voigt]

In following this thread, I'm left with a big question: If it is available

in Linux, why can't we access it in windows? They solved the problem of
different MB, chips, Bios.

In looking at the Linux code, which I haven't completely examined, it
appears that they have simply developed a flat database that identifies
where
to access the information.

There's still a fairly large amount of chip-specific code in lm_sensors.
All the drivers expose the same API though, so userspace tools just lookup
the units in that database you've noted, in order to do the correct
conversions.

[Mike C#]

"lynnch" <ly****@discussions.microsoft.comwrote in message
news:2E**********************************@microsof t.com...

In following this thread, I'm left with a big question: If it is available
in Linux, why can't we access it in windows? They solved the problem of
different MB, chips, Bios.

In looking at the Linux code, which I haven't completely examined, it
appears that they have simply developed a flat database that identifies
where
to access the information.

I too thought this would be a simple process. I have found a commercial
program that accoomplishes this feat, but I have not been able to find the
info. for implimenting in visual studio.

If you find it please post it.

From what I've found so far, Linux exposes a function (or more) that runs in
kernel mode. NT apparently doesn't, so the first hurdle is to write a
kernel-mode driver (or user-mode driver that can provide access to kernel
mode I/O like giveio.sys). This is fairly well-documented (though it's a
pain in the @!#$%), and from what I've read you have to pay MS to digitally
sign your driver for Vista (could be wrong, just what I've been reading).

But once you have kernel mode access via your own custom driver, then it
appears you have to gather all the info for the umpteen hundreds of
motherboards and processors out there, which is quite a pain too. I'm
actually going dig through lm_sensors and see if I can use that as a
starting point, so I don't have to duplicate all the research that's been
done on it already.

[ChristophGraham]

Unfortunately many of the CIMv2 classes on MS platforms do not have
underlying instrumentation providers associated with them. However,
for HP commercial platforms sensor information is published into WMI
via the HP Client Management Interface. This interface surfaces BIOS
settings, sensor, and alert information for use by IT professionals
and programmers familiar with WMI. For more information, a technical
whitepaper and sample scripts can be obtained from http://www.hp.com/go/hpcmi/

[Willy Denoyette [MVP]]

"ChristophGraham" <ch**************@hp.comwrote in message
news:11**********************@q40g2000cwq.googlegr oups.com...

Unfortunately many of the CIMv2 classes on MS platforms do not have
underlying instrumentation providers associated with them. However,
for HP commercial platforms sensor information is published into WMI
via the HP Client Management Interface. This interface surfaces BIOS
settings, sensor, and alert information for use by IT professionals
and programmers familiar with WMI. For more information, a technical
whitepaper and sample scripts can be obtained from http://www.hp.com/go/hpcmi/

Exactly what I said before, but I don't believe this will be of great help to the OP as this
is only available for selected HP/Compaq business line of systems.

Willy.

[=?Utf-8?B?TmF0aGFu?=]

I tried to play with WMI to get the fan and probe info but got nothing from
attempt.
I used the WMI Object Browser from WMI Tools and the response was something
along the lines of there not being any instances.

However, I know my motherboard has sensors. I've used MSI's own monitor tool
as well as Speedfan which collected everything.

I also used pcpbios to dump out smbios info and there was no info on the
fans or probes. I thought I'd use WMI to get the raw smbios data and
enumerate through it based on the smbios spec and it showed the same info as
the pcpbios. In other words, no fan or probe info.
SMBios contained Types 0,1,2,3,4,5,6,7,8,9,11,12,13 (refer to the smbios
spec).

I think speedfan uses giveio.sys to get to the hardware info. I was
wondering if that is the only way. What is needed to get the info?

Thanks,
Nathan

"Mike C#" wrote:

>
"William DePalo [MVP VC++]" <wi***********@mvps.orgwrote in message
news:eO***************@TK2MSFTNGP04.phx.gbl...

I wish Ferraris were cheap. :-)

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.

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).

[Mike C#]

"Nathan" <Na****@discussions.microsoft.comwrote in message
news:5C**********************************@microsof t.com...

>I tried to play with WMI to get the fan and probe info but got nothing from
attempt.
I used the WMI Object Browser from WMI Tools and the response was
something
along the lines of there not being any instances.

However, I know my motherboard has sensors. I've used MSI's own monitor
tool
as well as Speedfan which collected everything.

I also used pcpbios to dump out smbios info and there was no info on the
fans or probes. I thought I'd use WMI to get the raw smbios data and
enumerate through it based on the smbios spec and it showed the same info
as
the pcpbios. In other words, no fan or probe info.
SMBios contained Types 0,1,2,3,4,5,6,7,8,9,11,12,13 (refer to the smbios
spec).

I think speedfan uses giveio.sys to get to the hardware info. I was
wondering if that is the only way. What is needed to get the info?

Thanks,
Nathan

The general consensus seems to be that hardware vendors don't care to
provide us with a standardized interface, or standardized WMI drivers, for
retrieving fan speeds, voltages, CPU temp, etc. Doing it yourself appears
to involve a lot of painstaking research and corporate lawyers.