 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / April 2007Get CPU Fan Speed and CPU Temp
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! > 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/default.asp?url=/library/en-us/wmisdk/wmi/win3 2_classes.asp and then scroll down to the Win32_Fan class. Good luck. Regards, Will > Windows Management Instrumentation (WMI) may help you. Go here > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win3 2_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 > 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 > 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! 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 > > I wish Ferraris were cheap. :-) > [quoted text clipped - 25 lines] > that someone out there might have an idea. I can post my code if necessary > also (about 150 lines). >I tried to play with WMI to get the fan and probe info but got nothing from > attempt. [quoted text clipped - 19 lines] > 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. >> Thanks Will, > [quoted text clipped - 7 lines] > 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! > [quoted text clipped - 3 lines] > 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. > 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 >> Each windows system since W2K, comes with a UI based utility called >> wbemtest.exe which allows you to query the WMI namespace without you [quoted text clipped - 8 lines] > > 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. > You might want to see if speedfan gives you the right results. > (http://www.almico.com/speedfan.php) [quoted text clipped - 5 lines] > 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 want to see if speedfan gives you the right results. >> (http://www.almico.com/speedfan.php) [quoted text clipped - 9 lines] > 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. > 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 [quoted text clipped - 4 lines] > 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! >> You might also check whether there is a linux driver for your >> motherboard, the source code for that would be available. Or you might [quoted text clipped - 8 lines] > 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! > 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). >> 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 >>> Which particular chip is it? > [quoted text clipped - 17 lines] > # 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. > 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, [quoted text clipped - 8 lines] > 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 :( >This is not only a MOBO issue, all CPU's (say Intel, AMD, ...) may >expose things differently, some CPU models have a temperature probe [quoted text clipped - 3 lines] >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 >>This is not only a MOBO issue, all CPU's (say Intel, AMD, ...) may >>expose things differently, some CPU models have a temperature probe [quoted text clipped - 19 lines] > # 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. >> 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 [quoted text clipped - 4 lines] >> 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. >>> 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 [quoted text clipped - 20 lines] > 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, 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. > 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 [quoted text clipped - 4 lines] > 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. >> 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. [quoted text clipped - 6 lines] > > 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, > That's exactly what I was expecting, most system vendors (or MOBO vendors) [quoted text clipped - 5 lines] > > 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... > > Mike, > > That's exactly what I was expecting, most system vendors (or MOBO vendors) [quoted text clipped - 8 lines] > 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. > 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 [quoted text clipped - 4 lines] > 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. > 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 [quoted text clipped - 10 lines] > > 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. 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/ > Unfortunately many of the CIMv2 classes on MS platforms do not have > underlying instrumentation providers associated with them. However, [quoted text clipped - 3 lines] > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.