Fiery

Thank you!

Thank you. That still seems to be a mysterious issue. It does affect multiple users, not just you, so it should be a bug in AIDA64. Can you please check if HWiNFO64 can read all DIMM temperatures reliably, over a few minutes period of time?

Thank you. The register output seems fine. Are you sure you don't have a custom TJMax value configured in AIDA64 / main menu / File / Preferences / Hardware Monitoring? The TJMax setting there should be set to Automatic, since your CPU can provide the right TJMax value via a CPU register.

That option no longer works, and we'll remove it soon. We're now using a single set of icons. Regards, Fiery

The mentioned new AIDA64 beta update is available for download at: https://www.aida64.com/downloads/latesta64xebeta Let me know how it works.

Yes, it does. It doesn't utilize the middle steps at all. Of course if a certain software doesn't measure the CPU clock the right way, it could show something that your CPU doesn't do at all. If during the CPU clock measurement the CPU switches its multiplier up or down, and the measuring software is not aware of that, the measured CPU clock will not reflect the actual state of the CPU, but something in between the old state (before the software started to measure the clock speed) and the new state (after the software is done with the measurement). The measured MHz value will be in between the old clock and the new clock, so it will reflect a multiplier that the CPU may not switch to, at all, ever. Not to mention the issue that I've mentioned before, ie. when the CPU clock measurement code itself causes the CPU to switch its multiplier up or down (most likely up).

As I've explained above, clearly AIDA64 + CPU-Z + HWMonitor measure CPU clock using a different method than what Task Manager and MSI Command Center use. I still have no other choice but to stick to my stance about AIDA64 (+ CPU-Z + HWMonitor) measuring CPU clock using the right (proper) method. I don't know what exactly the other 2 software do, and frankly I don't care, since I'm 100% sure they do not use a superior CPU clock measurement method than our software. Why do you need your CPU to run at e.g. 3500 MHz when you overclock it? I thought you want it to be quick. It is quick even when it is running at a fixed clock all the time -- as long as that single clock speed level is high enough, of course.

We've just rolled out the first AIDA64 beta with proper handling of DPI scaling, as well as fix for the screen resolution detection issue: https://www.aida64.com/downloads/latesta64xebeta A few icons are left to be updated, and we also have to fix a few issues in the Monitor Diagnostics module. Let me know how it works on your system

We've just rolled out the first AIDA64 beta with proper handling of DPI scaling. In other words, it is fully DPI aware now: https://www.aida64.com/downloads/latesta64xebeta A few icons are left to be updated, and we also have to fix a few issues in the Monitor Diagnostics module. Let me know how it works on your system

We've just rolled out the first AIDA64 beta with proper handling of DPI scaling: https://www.aida64.com/downloads/latesta64xebeta A few icons are left to be updated, and we also have to fix a few issues in the Monitor Diagnostics module. Let me know how it works on your system

What I'm saying is that since on our motherboard -- and also several other motherboards with the same chipset and same CPU -- AIDA64 can track the CPU changing multipliers in the right granularity, there's nothing wrong with the software. There must be a configuration issue or other pecularity on your system that makes your CPU use only a small number of multiplier steps. First, please tell me why would that be beneficial? Your CPU seems to be able to utilize its power management features properly, so at idle it can down-clock itself to save power (it can switch to LFM). It can also switch up to the right high multiplier (it can switch to HFM) when the system is under load. What's wrong with it then? Why would it be beneficial to use the middle multiplier steps? And even if you miss those, what can we as software developers do about it? If there was a simple solution, I'd of course reveal it for you, but I've never seen a LGA2011 CPU behave like yours. To me it seems like a firmware (BIOS) issue or system configuration issue. If one can even call that an issue When both LFM and HFM modes work, ie. the CPU can both provide the expected performance and operate with little power at idle, I'd say it's working properly.

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