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.

Please right-click on the bottom status bar of AIDA64 main window --> CPU Debug --> CPUID & MSR 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 usually don't implement such temperature readings that neither the BIOS Setup or the manufacturer's own software measure and display. Regards, Fiery

We haven't changed the defaults. The default font has always been Tahoma for the LCD module and SensorPanel. Try to set the fonts to Lucida Sans, it looks quite good at size 6.

Thank you for the feedback

The only thing that might cause that is the Dell SMI sensor support, that may interfere with other, non-sensor related SMI calls used by the BIOS. You can disable Dell SMI sensor support in AIDA64 / main menu / File / Preferences / Stability. Let me know if it makes a difference. Thanks, Fiery

Thank you. After upgrading to the latest AIDA64 version of 5.80, did you change anything about your LCD configuration in AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD / LCD Items? Did you change anything else about your Windows setup that may have removed the original font used before? I'm pretty sure it wasn't Tahoma before, since that font doesn't support font size 6. Do you happen to have a previous backup of your AIDA64 settings that may reveal the font used before? BTW, the update wasn't supposed to change any of your existing settings, including your LCD layout. However, in case the font previously configured was removed from your Windows installation (due to e.g. upgrading from Win7 to WIn10), AIDA64 may have reverted back to the default font of Tahoma. And if you change your LCD layout settings after that automatic font change, then AIDA64 would save Tahoma as the font into your LCD layout, effectively removing the name of the font that you used previously

Thank you for checking it out. Do you experience the same stuttering issue (or latency spikes in DPC Latency Checker) when you disable G15/G19 LCD support and you keep AIDA64 opened while its Computer / Sensor page is showing?

Thank you for the feedback!