Fiery

"PCH" and "PCH Diode" are the temperatures of the onboard Intel chipset (PCH), while "Motherboard" is the temperature of the sensor chip. Both the sensor chip and the PCH are integrated on the motherboard PCB, but they're usually far from each other. And while the relatively simple sensor chip always runs quite cool, the very complex PCH could heat up quite heavily when there's a lot of data traffic flowing through it. Regards, Fiery

"CPU" temperature is measured by the onboard sensor chip (onboard = integrated on the motherboard PCB), while the core temperatures are measured by the CPU itself. Under heavy load both temperatures should be reliable, but at idle many modern AMD processors measure unrealistically low core temperatures (e.g. 0 or 5 Celsius with an ambient temperature of over 20 Celsius). As long as all CPU or CPU related temperatures are below 80 Celsius, you're fine.

Thank you for posting that package! Regards, Fiery

I don't think we'd ever had 5VSB reading available for Asus Z87-Pro A different motherboard you used to have may have had that reading, but it's not available on just any motherboard out there, but only on some.

If it's possible, please send us two ISA Sensor Dumps and two Embedded Controller Dumps. One pair of the dumps where the CPU, VRM and PCH (so generally the system) is cool, and one when it's hot (or less cool), so we can compare the various temperature readouts and figure out what could go wrong. If it's possible, please also check whether the problemous thermal readings are stuck in the BIOS Setup too.

What's wrong about them? They aren't reported at all? Are they inaccurate? Are they showing the temperature of each other, so they're swapped? Or ... ?

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. Thanks, Fiery

We will add the requested information to the Motherboard / BIOS page in the next AIDA64 beta update. Regards, Fiery

Thank you, we will fix that issue in the next AIDA64 beta update. Regards, Fiery

We will fix that issue in the next AIDA64 beta update The secondary IMC is because all Ivy Bridge-E/EP, Haswell-E/EP and Broadwell-E/EP processors include two memory controllers, but in many cases only one of them is utilized. Regards, Fiery

Font Resolution is LOGPIXELSY from: https://msdn.microsoft.com/en-us/library/windows/desktop/dd144877(v=vs.85).aspx Pixel Width is ASPECTX from the same call. Pixel Height is ASPECTY, and Pixel Diagonal is ASPECTXY. Regards, Fiery

Under modern Windows systems it could be quite a challenge to pick the actual primary network adapter. AIDA64 relies on Winsock to pick the primary network adapter, and then it will report its IP address. If it's not the IP address you're looking for, then I'm afraid it's not the fault of AIDA64. You can see all network adapters and their IP addresses (+ MAC addresses) on the Network / Windows Network page. Regards, Fiery

"Motherboard" and "CPU" temperatures are both read from the sensor chip that's integrated on your motherboard, while the core temperatures (that CoreTemp as well as AIDA64 measures) are read directly from the CPU. Reading CPU temperature from the motherboard sensor chip however requires sensor chip bank switching which could collide with other monitoring software also doing the same bank switching. So for example, if you have both CAM and AIDA64 running in the background, when they both try to switch sensor chip bank in the same time, one of the reported values (either the one in CAM or the one in AIDA64) will end up in an unpredictable result. In your case I suspect CAM collides with AIDA64. We've already contacted NZXT to convince them to implement the industry standard synchronization mutexes in CAM, in order to avoid such collisions, but we've received no response from them so far. If you can narrow this issue down, and verify my theory on CAM vs. AIDA64 collision, then you as an end-user (and customer) of a NZXT product may also contact NZXT and ask them to team up with us to resolve this issue. We're 100% open and willing to resolve this, but we need NZXT's assistance too. BTW, the mentioned synchronization mutexes are already implemented by a wide range of 3rd party monitoring, tweaking and benchmarking software, including AIDA64, AMD OverDrive, CoreTemp, CPU-Z, EVGA E-LEET, GPU-Z, HWiNFO, HWMonitor, MSI Afterburner, RealTemp, Rivatuner, SIV, SpeedFan, etc.

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. Thanks, Fiery

Please give us a few days to try and figure out what causes the collision between Intel's Turbo Boost Max 3.0 driver and AIDA64. We have a strange suspicion that it's not the CPU diode temperature measurement, but another portion of the AIDA64 hardware monitoring module.

What motherboard do you have? Do you have any other monitoring software installed? Like Asus AI Suite or such? BTW, yes, you're absolutely right, 255 Celsius is obviously an incorrect reading that can and should be ignored.

Yes, as long as you can boot a Windows from that drive, like Windows PE AIDA64 doesn't include a bootable operating system, but can be used directly from a USB flash drive under an already running 32-bit or 64-bit Windows system. Regards, Fiery

What motherboard do you have? Can you see a 5VSB reading in the BIOS Setup, or in the motherboard manufacturer's own sensor monitoring software?

Thank you. Our best guess is that the issue is caused by Intel Turbo Boost Max Technology 3.0. If you can, please try to disable it, and check if it helps.

Thank you, we've added that info bit to the AIDA64 SSD database.

You need to right-click on the incorrect temperature units on the SensorPanel --> Modify, and alter the Unit for each such item.

Please right-click on the bottom status bar of AIDA64 main window --> System Debug --> Battery Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. As for the SensorPanel issue, that could happen when you upgrade from an older AIDA64 version to AIDA64 v5.80. In v5.80 we've enabled DPI scaling, and that includes the SensorPanel too. Text, bars and graphs are automatically scaled, so they don't need any adjustment because of this change. However, gauges and images are not scaled up, so you may need to change them or update them to make sure the SensorPanel layout looks great when it's scaled with DPI.

Thank you for the feedback

UV400 cache size is already reported for the 480GB and 960GB variants on the Storage / ATA page (you need the latest version of AIDA64). Kingston didn't specify the cache size for the 120GB and 240GB variants, so that's why AIDA64 doesn't report it for those SKUs. If you however have got reliable information on the cache sizes for those parts, we would be happy to add it to the AIDA64 SSD database. Regards, Fiery

You can switch the temperature measurement unit in AIDA64 / main menu / File / Preferences / Hardware Monitoring. However, if you already use a fixed label for temperature units (e.g. "C") on your SensorPanel, then you will need to change that to "F" manually.