Fiery

The issue seems like a collision between the manufacturer's own monitoring software and AIDA64. Have you tried to uninstall ASRock's own monitoring utility?

We still believe the issue is with the video driver (ForceWare) and not AIDA64. Try to downgrade to an older ForceWare release, and check if it helps. I know you've mentioned that you've tried that path with no success, but maybe you've downgraded to a too recent version that already has the bug? For others 388.31 solved the issues:

Thanks for the feedback

Please let me know what motherboard, CPU and video card(s) do you have, and whether you're using the latest Windows 10 build (17134).

Thank you for your feedback. The test is the same as before, it's only the amount of memory to be stressed that you can now adjust.

We've implemented the requested Memory allocation % option in the Preferences of the AIDA64 System Stability Test. https://www.aida64.com/downloads/latesta64xebeta Let me know how it works

Thank you, that's a very useful breakdown of the labelling issues. Please upgrade to the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta Let me know how it works

Thank you. Please upgrade to the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta Let me know how it works.

I'm sorry, I messed up the info on the alphabetical order. It is sorted, but since the drives are numbered with indexes, those indexes override the model ID of each drive. So if we gloss over the 3 groups issue (since your system only has drives in the first group), the order is the order that is dictated by the physical order of drives, as they are connected to their respective drive controllers, as well as the order of controllers. Since Windows may or may not enumerate drive controllers in the same order as AIDA64, only the order of drives connected to a particular drive controller should match between AIDA64 and Windows. Renaming of labels is available in OSD Panel, Desktop Gadget, SensorPanel, and external LCD modules.

We've tried to reproduce the issue on our own Ryzen test systems, but with no luck. Please do the following: 1) Before sleep, when benchmark scores are normal (lower), 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. 2) After waking from sleep, when benchmark scores are higher, please create a second CPUID & MSR Dump, and copy-paste the full results into this topic, or attach the results as a TXT file to your post. For those test runs, make sure to use the latest AIDA64 beta build: https://www.aida64.com/downloads/latesta64xebeta Thanks, Fiery

I'm afraid on some Asus motherboards the activity that AIDA64 needs to communicate with the EC (Embedded Controller) causes latency spikes. So far we haven't been able to solve the issue on our end So if you want to avoid the sound glitches, you need to disable EC support in AIDA64.

Thank you for the dumps. To me it looks like as if some of the GPUs in your system simply went to sleep after a while, due to lack of activity or load. Have you tried to disable ULPS?

Thank you for the details. We suspect it can be due to the video driver, so if it's possible, please try to downgrade ForceWare, to a late-2017 WHQL release, 388.31 for example. Let me know if it makes a difference. If not, please post a screen shot showing the error message that comes up when AIDA64 crashes.

We suspect it can be due to the video driver, so I'd try to downgrade ForceWare, to a late-2017 WHQL release, 388.31 for example.

I don't think so

What Windows version+build are you using?

You have too much free time

Exactly

Very strange. We've tried, but were enable to reproduce the issue with our SQL databases. Can you please check what happens if you purge your database (with either AIDA64 Database Manager or using a custom SQL query), and insert the report files to your database using the AIDA64 Database Manager?

Please avoid posting a single issue into multiple topics. I've replied you in your other topic.

The order is alphabetical, but it has 3 groups, and the alphabetical order is only valid inside each group. 1) First group is the internally connected drives (IDE/ATA/SATA drives) that are not enumerated by the AIDA64 RAID module. Usually those are the regular drives that everyone's got. 2) The second group is the internally connected drives that are either part of a RAID array, or not picked up by direct enumeration but only by the RAID module. It's important to note that those drives are not necesserily part of a RAID array, and may not even be connected to a RAID controller. I know, it's weird 3) The final group is the external drives (FireWire, USB, eSATA, Thunderbolt, etc). If you post a current ATA Dump and SMART Dump, I can tell you more about the why's of the ordering. Not really a good idea, since then the driver may override the otherwise more explanatory model ID with something useless. In your particular case (of the 280GB Optane 900P drive) it indeed would be useful though, but then again, it would be useful for many other SSDs that have no such "nice" model ID that can be understood by a glance, like for certain Samsung SSDs.

We'd rather wait for a public BIOS release for Prime X299-A. It's an essential machine in our test fleet (due to AVX-512 support and many CPU cores), so we'd try not to mess it up with a test BIOS

That spike was probably just a glitch in the communication between AIDA64 and the EC (Embedded Controller) chip of your motherboard that provides the "CPU" current and "CPU" power readings. While the "CPU Package" and "CPU IA Cores" readings are provided directly by the CPU, and there's no communication issue possible there, fortunately.

I'm not sure if you mean that the indication of thermal throttling is a bug in AIDA64 or something else. If you're doubtful about the validity of the throttling reporting, you can check it with alternative monitoring software as well. I'm sure they all will report the same amount of throttling though

It means whatever you've done to your system made things worse