Messages

If you are interested, the code that combines CPU/GPU detection into one query. It seems to create an executable that shows about 1K smaller.

https://www.dropbox.com/s/juf1pi0hqifncel/NewVersion-02.zip?dl=0

Hi again Fred! Here is what I came up with. It's been too long since I coded in C++, so while I suspect that m_sHardware[m_iHardwareCount][2] = L"-1"; has something to do with marking the end of valid data in the array, I am not sure. Information about hardware is now in hardware data structures while information about sensors is in sensor data structures. Each has their own array and an array to link the two. As I have set it up now, only one hardware query statement is really needed for CPU/GPU discovery, but I left it as is because I wasn't sure if you wanted them separate. A sensor query is now in the Init() to record info about those sensors that belong to the CPU/GPUs for use in later temperature updates.  GetID now returns a string containing the hardware Identifier, hardware Name and sensor Name. ReadTemperature mostly works the same, but now searches through the sensors for those matching the sensor identifiers that we are interested in updating.  GetTemperature also works mostly the same, it just reads data from m_iSensor instead of m_iHardware. Hopefully I haven't screwed up your code too badly.

https://www.dropbox.com/s/erv7my61ond68v0/NewVersion-01.zip?dl=0

Hi Fred! I think I have found the issue. While each sensor has only one piece of parent hardware, each piece of hardware can have more than one sensor. I did not know how you handled internal data access, so my example code just printed out the sensor data as it found it. It looks like the array you set up to store temperature data, m_iHardware, assumes that there is only one temperature reading per piece of hardware. If there are more than one, then each new find will overwrite the previous one. In my case, I have always seen the package (Tdie) temperature being displayed before the Tctl one, though I imagine that it would not be wise to assume that that is always the case.

It looks like you are presenting people with a list of hardware to choose from, when it appears that what is needed is a list of senors. (No criticism intended.) I will be contemplating the code further to see if I can come up with a way to modify things such that GetID will return a string containing the hardware Identifier, hardware Name and sensor Name for user selection, and GetTemperature will return the desired temperature sensor reading, in both cases not changing the signature.

Hmmm... Here is a screenshot, via Dropbox, of the output of that code I sent you on my system. The three line groups are the Hardware Name, the Sensor (temperature) Value, and the Sensor Name taken once per second for 10 seconds. This is the Dropbox link:

https://www.dropbox.com/s/307m8p8ukug33nd/Screenshot%202020-08-26%2000.01.10.png?dl=0

When I am running Open Hardware Monitor on my system, the user interface for Open Hardware Monitor does not even show the Tctl temperature, only the package (Tdie) one. I only found out that it was reporting the Tctl temperature when during code development I was listing all of the temperature sensors found and I saw it.

Hi Fred! I downloaded and installed TThrottle 7.73. When I ran my test app on my system, a Ryzyn 7 2700x, I got two temperature readings for the CPU. One corresponded to HWiNFO64 Tdie (CPU Package) which is the true temperature of the CPU chip, and the second corresponded to HWiNFO64 Tctl (CPU Tctl) which is higher, in my case by 10 C, and intended by AMD to provide a consistent fan response across their various products. The only CPU option right now seems to be for CPU Tctl, with no way to select CPU Package. Was this intended?

Hi Fred! Thank you. Yes, I would enjoy being added. After looking at the about again, I think that "pcook" should work just fine.

Hi again! Here is what I came up with. It is a little console app that finds out what CPUs/GPUs are in the system using OpenHardwareMonitor WMI, then displays some temperature data for them. The code is based on the WMI sample code found here:

https://docs.microsoft.com/en-us/windows/win32/wmisdk/example-creating-a-wmi-application

The app WMI Code Creator v1.0 was used to inspect the OpenHardwareMonitor WMI namespace. It can be found here:

https://www.microsoft.com/en-us/download/details.aspx?id=8572

I was going to attach the code and exe, but adding attachments does not seem to be an option.

I hope this helps. It ran on my system, but only further testing will tell how well it does on others.

Hmmm.... The first thing I did was check out the hwinfo.com forum, where I found that other people have been having problems with the sensor readings of ASUS motherboards. (2020 thread.)

https://www.hwinfo.com/forum/threads/frozen-values-in-hwinfo.6495/

I checked on the Corsair forums and found talk of the issues of using HWiNO and iCUE together. (2018 thread.)

https://forum.corsair.com/forums/showthread.php?t=180150&t=180150

I tried disabling HWInfo's monitoring of Corsair devices, but that didn't seem to work.

And here on an ASUS forum, I found where they talk about a bug with the ITE IT8665E (the Super IO chip that the motherboard uses for fan/temperature sensors and fan control) and how it reacts to getting polled a lot by software like hwinfo. (2018 thread.)

https://rog.asus.com/forum/showthread.php?102138-CPU-and-case-fans-mysteriously-stopping-on-the-ASUS-Prime-X470-Pro

Open Hardware Monitor seems to be accessing CPU, GPU and hard drive temperature data directly. If the  ITE IT8665E is available, Open Hardware Monitor will show it under ASUS ROG STRIX B450-F GAMING and show the motherboard sensor data, ie. temperatures (CPU, Socket, Chipset, etc.) fan speeds, memory temperatures, etc. If the ITE IT8665E is hot feeling sociable, then it doesn't even show, in fact nothing shows, under the motherboard entry.

Since finding out all of this info, I have been looking into writing a little app as a test of how to access Open Hardware Monitor's sensor readings via WMI as they suggest. What language is TThrottle written in?

Hi! I also have been seeing a sawtooth pattern in TThrottle's graph of the cpu temperature data. In my case it IS a problem with HWiNFO64. My motherboard, an ASUS ROG STRIX B450-F GAMING, uses an ITE IT8665E Super IO chip for temperature sensing and fan control. This chip apparently has a history of not being happy if more than one application is accessing it at the same time, causing it to eventually, any where from hours to days, stop responding to data requests. This causes HWiNFO64's sensor readings to lock and Tthrottle to oscillate between what it natively sees, in my case 15 C, and the last value HWiNFO64 presented at the time of lockup. The other application in my case is iCUE from Corsair used for controlling the lights on my Corsair memory. Once this issue is triggered, it takes a system reboot to get access to the data again. Would it be possible for you to add OpenHardwareMonitor to the list of external temperature sources? It seems to be able to sense my AMD Ryzen 7 2700X with no problems when this happens, showing the same temperature data under AMD Ryzen 7 2700X/CPU Package as HWiNFO64 shows for the cpu die reading. It publishes its data through WMI.