Fiery

CPU Package is the total consumption of the whole CPU package, including the x86 CPU cores ("IA Cores") and -- if available -- the iGPU shaders/cores ("GT Cores") as well.

1) Only the first 4 cores are automatically assigned as temperature slots in the AIDA64 System Stability Test. You can use the Preferences button to change the temperature slot assignments to display the rest of the cores on the Temperature graph as well as among the thermal readings in the Statistics list. 2) TSX is not listed on any processors as part of the Instruction Set list on the AIDA64 CPUID Panel.

I know, it's a complicated issue, since the frame still works well under Windows XP... And probably under Windows Vista as well.

You can use the right-click context menu on the Computer / Sensor page --> Extended Labels to help you understand where one or more of the generic sensor readings (like Temperature #1, Fan #21, etc) comes from.

Are you sure the device cannot switch to Mini Monitor Mode? I'm just asking because when AIDA64 says it cannot find libusb0.dll, it usually means the device is ready (in Mini Monitor Mode), and the issue is on the DLL side. You can then download and install the Samsung SPF LibUSB driver from the following link: http://download.aida64.com/resources/lcd/samsung_spf_lcd_driver.zip

We will fix the issue in the next AIDA64 beta update. I'll post a message into this topic once the new build is available for download.

1) The GPU stress test relies on the OpenCL subsystem that seems to be broken on your system. Try to uninstall your video driver and install the latest WHQL one to fix that up. 2) Saving the stress test history or statistics to text file is not supported. You can however use the Logging facility to save your selection of sensor readings into a CSV or HTML file. Go to AIDA64 / main menu / File / Preferences / Hardware Monitoring / Logging to configure that feature.

I'm afraid we cannot find the reason why AIDA64 holds lock on such folders. We've implemented a more modern save file dialog to the debug dump window, but it works the same about holding the lock.

Does TACH(0) always provide the correct RPM when your fan is spinning at various non-zero RPMs?

We've tried it with the default 20 seconds poll rate as well as with 1 second.

AFAIK with Asetek-compliant liquid coolers the issue is that the fan controlling logic could get reset when AIDA64 and iCUE collides while reading the liquid cooler measurements. It results in the fans spinning up to 100% speed, which could be quite annoying. If you can live with that limitation, then it's safe to leave the Asetek liquid cooler module enabled in AIDA64.

It will be implemented in the next AIDA64 beta update.

Awesome, thank you for your feedback. Can you please post a screenshot or report or copy-paste of the Display / GPU page?

I don't think it's our responsibility to be frugal on network requests when the traffic is initiated by the user by clicking on a link in our software. We'll alter the most clicked links, but the sheer number of URLs (over 1100) makes it a difficult task to leaf through all of them using manual review.

Make sure to upgrade to the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it works better than the previous builds

Yes, but we're unable to reproduce the issue on our own Z10 keyboard Are you using the latest firmware on your keyboard?

After VHD creation please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> SMART 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. Also right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> Disk Controllers Dump. 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 --> Disk Debug --> RAID Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Thanks, Fiery

I don't know... It depends on the information reported in the ATA ID block..

Thank you. We'll try to find out how can that tool do what it does.

We've tried to replicate the issue on our own NVMe drives (using the latest AIDA64 beta build), but with no luck. So I cannot check whether there's a difference between the latest stable build (4900) and the latest beta build (4992), since they both work properly for us. But it would be important to find out whether the issue is related to the recent changes that are only available in the last few beta builds.

Please avoid being arrogant with us on this forum. Please also try to enable the SensorPanel, and check if the Lock panel position option works the way you expect (but for the OSD Panel). If yes, then we can implement that behavior for the OSD Panel as well.

Thank you for your feedback! We'll add "Water #2" to the language modules in the next AIDA64 beta update

Our P106 board arrived. Apparently the standard nVIDIA GPU detection API (called NVAPI) doesn't support mining adapters. It may be possible to poll the card using another nVIDIA API called NVML, but that API cannot be called from 32-bit applications, so we cannot support it at this time.

1) Can you see the same issue with AIDA64 v5.99.4900, the latest stable release? 2) Are your NVMe drives part of a RAID array?

OSD Panel is supposed to be a quick & easy solution to display sensor readings. If you need a more advanced solution, try AIDA64 SensorPanel which -- among many other things -- supports locking its position and window size.