Fiery

I'm the lead developer behind AIDA64, hence I know how that software works and what exactly it does. I'm not the developer behind Windows Task Manager or MSI Command Center, hence I have no idea what they do and how they work. I can only guess, but that's just a guess. I've already told you what I think they do: they measure average CPU clock over a certain period of time (short period, but still a period of time), and not the actual CPU clock frequency at a certain moment. Your CPU will never work at 4022 MHz when you use 100 MHz BCLK, so that single reading alone means MSI Command Center doesn't measure the CPU clock frequency in the proper way. It seems you stick to debating whether "proper" is really the way it should work. AIDA64 has its roots going back to over 20 years. It does it in a way that we believe, according to our over 2-decade experience, is the right way. CPU-Z, HWiNFO and several other monitoring software use exactly the same method to measure CPU frequency. BTW, CPU-Z and HWiNFO are also not exactly newcomers in this business. If you believe MSI Command Center and Task Manager both do a better job than AIDA64, CPU-Z, HWiNFO and other 3rd party monitoring software, then we have to agree to disagree. If this single issue -- where in my opinion you're clearly wrong -- is a make or break issue about using our software, then I'm afraid the only possible solution is for you to request a refund, get your money back, stop using AIDA64, and keep using Task Manager and MSI Command Center instead. Because we cannot and would not switch to using an average CPU clock frequency measurement method. Our method is the best and proper way to do it, and we wouldn't settle with an inferior solution.

In your video I cannot see any miscalculated frequency readings in AIDA64. 4499.8 MHz instead of 4500.0 MHz exactly is due to slight fluctuations in the BCLK (APIC Clock) reading. It's way less than what I've mentioned above. MSI Command Center miscalculated (or incorrectly measured) the core clock frequency by almost 22 MHz. And even if it does that, the BCLK should be adjusted in a similar fashion. "100.0 x 40.0 = 4021.7" is not something you could take as mathematically correct.

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

If you mean you have 2 computers with one PSU each, then it should work of course In which case on the problemous machine (where the +12V reading is missing) 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

Thank you. I have to say, that's quite puzzling. Can you please check what happens if you just start AIDA64, without performing any dumps and without navigating to any info pages? If it works properly that way, then please try to go to the Motherboard / Chipset page. I suppose it would trigger the issue.

We haven't altered the timing settings for Broadwell-E SPD SMBus, so there should be no difference between the way it works since Build 3917. We've seen such timing issues with heavily overclocked DDR4 modules. Can you please check if the memory modules are more stable at DDR4-2400 setting? (which is the default for your CPU) As for the System Tray icon right-click menu, you're right, we'll fix that in the next AIDA64 beta update. Thanks, Fiery

Please note that AIDA64 can only measure and show +12V for a single PSU. If you have issues about your Corsair PSU, please let us know what exact PSU model is it. Thanks, Fiery

Then maybe the issue comes up only while you're playing 3D games. Then it may be related to a video driver issue, a video card failure or a power delivery issue.

That's not necesserily a reliable method, since the manufacturer of the phone could change (update) the chip through the lifecycle of a certain device.

Thank you. The SMBus workaround is working properly, so the culprit is most likely the Embedded Controller. Can you please repeat only the Embedded Controller Dump, and let us know whether or not it triggers the issue? Thanks, Fiery

Try to run only the Cache and Memory subtests for a few hours. It may work best to trigger a potential cache fault. Regards, Fiery

It's not there simply because it's not possible to talk to the GPS chip directly So we cannot extract any information from them. Regards, Fiery

The requested feature will be implemented in the next AIDA64 beta update due in a few days from now. I'll post a message into this topic once the new beta update is available for download. Regards, Fiery

AIDA64 already does everything it could to support hot-swap drives on the SensorPanel and other hardware monitor modules. When a drive is appended to the list of drives when you connect it, it should work fine. However, in case connecting or disconnecting a drive triggers Windows to re-arrange the list of physical drives in the system, AIDA64 cannot do much to get around that issue. If you don't have a RAID array defined, you can try playing with the RAID-related options in AIDA64 / main menu / File / Preferences / Stability, and see if it helps to fix this up. Maybe if you disable both such options, things get a bit better. Regards, Fiery

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. Then right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> SMBus Dump (Full). Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Finally, right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Embedded Controller Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Let me know if you experience any issues after issuing each of those 3 dumps. Thanks, Fiery

We've implemented the requested Hot Keys feature in the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta You can configure it in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Hot Keys.

We've implemented the requested Hot Keys feature in the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta You can configure it in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Hot Keys.

We've implemented the requested Hot Keys feature in the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta You can configure it in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Hot Keys.

We've implemented the requested Hot Keys feature in the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta You can configure it in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Hot Keys.

Such hard-to-explain and temporary issues could happen after moving from an older Windows release to Windows 10 Anniversary Update. I'm glad it works fine now

It's safe to use 500 milliseconds (half a second).

Thank you. The lack of proper sensor readings is due to the fact that AIDA64 is unable to use its kernel driver. That could be because the kernel driver file (KERNELD.X64 or KERNELD.X86) is missing, or your Windows user has no administrator privileges, or a Windows prevents to elevate the security privileges of AIDA64.

Please right-click on the Computer / Sensor page of AIDA64 --> Copy Debug Info to Clipboard. Paste the full results into this topic. Thanks, Fiery

The mentioned new AIDA64 beta update is available for download at: https://www.aida64.com/downloads/latesta64xebeta

Apparently Supermicro X8DAH motherboards use SMBus multiplexing that prevents AIDA64 from reading SPD memory information and DIMM TS thermal readings. We've implemented an experimental workaround for this issue in the latest AIDA64 beta update available at: https://www.aida64.com/downloads/latesta64xebeta Please note that the new workaround may cause system lockup or instability in case it doesn't do what we expect it to do. If it's possible, please submit a new SMBus Dump (Full) dump, as well as an ISA Sensor Dump. The latter would be necessary for us to check what's wrong with the other sensor readings. Thanks, Fiery