Fiery

1) What motherboard do you have? 2) What happens if you click on the Motherboard / ACPI page in the left menu, without creating a report?

We've added support for Matrix Orbital EVE2 color graphical LCD displays. The only connection method currently supported is USB, via Matrix Orbital's own USB2SPI converter board. You can enable the LCD device from AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD / Matrix Orbital EVE. You need to have the appropriate Matrix Orbital USB LCD drivers installed, and the LCD to be connected to a USB port. AIDA64 uses LibMPSSE-SPI API to communicate with SPI devices. You need to copy the 32-bit libMPSSE.dll file from the latest LibMPSSE-SPI ZIP package into the AIDA64 installation folder. In the LibMPSSE-SPI ZIP package you can find that file in the Release/lib/windows/i386 folder [Note: Since AIDA64 v5.98.4810 build AIDA64 uses FTD2xx library to talk to EVE2 LCDs. LibMPSSE-SPI API is no longer used, and so its DLL module is no longer necessary] You can find the new AIDA64 beta update at: https://www.aida64.com/downloads/latesta64xebeta Please let us know if you find any difficulties enabling or using this new feature. Also let us know if you've got another kind of LCD device that is currently unsupported by AIDA64. Regards, Fiery

What motherboard do you have? Is it made by Asus?

Sensor logging can be activated in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Logging. You may also find Alerting a suitable feature for your needs. You can activate that in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Alerting.

In such situations when the multi-monitor configuration changes between AIDA64 launches, such mixup can occur. AIDA64 has a built-in protection against such issues. It should move its main window automatically to the top-left corner (x = 0 / y = 0) when it detects that its main window falls out of the visible area of all monitors. But in some cases that mechanism fails to work. If you could describe both the old and new configuration of the 2 displays you've got (resolution for each, their position realtive to each other in Windows multi-monitor configuration), we can try to replicate the issue and improve on the existing mechanism to make it suitable for such special situations.

Please note that it's not possible to diagnose such issues remotely. You may want to take your phone to a local specialist and have it checked out.

As long as the server is running Windows, it can be a valid usage scenario.

AIDA64 displays all NVMe thermal readings on the Storage / SMART page.

AIDA64 Business uses a proprietary protocol with proprietary encryption. We do not publish the protocol details.

Please 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. If the problem persists, please right-click on the bottom status bar of AIDA64 main window --> System Debug --> USB 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. Also 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

-10000 indicates a measurement issue. It could be due to excessive overclocking, but it can also be completely unrelated. Can you see such "hiccups" in current measurement when the CPU is not overclocked or less overclocked?

Task Manager shows an average CPU clock speed measured through a period of time, while AIDA64 shows the CPU clock speed as it is provided by the CPU, at any given time point.

Here's the proper fix for the Windows Explorer issue: https://www.aida64.com/downloads/latesta64xebeta

Meanwhile, we've made a change to AIDA64 to exclude Adafruit UF2 bootloader equipped USB devices from the external storage device scan. It may or may not help though. We'll only be able to check it out once our device arrives. If you or one of your customers can test the new build, and report us back whether it makes any difference, it would be appreciated. https://www.aida64.com/downloads/latesta64xebeta

Thank you

We've tested RemoteSensor with Bitdefender Total Security 2019, both under Windows 7 64-bit and Windows 10 64-bit, and couldn't reproduce the issue you've described. It must mean that the firewall configuration is to be blamed on your system. Make sure to browse through the firewall settings in Bitdefender configuration, and also check if Windows Firewall is enabled and how it is configured.

It comes from the battery, but not directly. AIDA64 measures that value using the standard Android Battery API, and applies no conversion on the raw value that is provided by the Android platform.

Yes, the next beta should be fine as long as you're on 4691 right now.

The latest 2 beta builds of AIDA64 have an issue about auto-update. It will be fixed in the next AIDA64 beta. Make sure to upgrade to it manually, and from then on everything will be fine again. I'm sorry for the troubles.

Thank you! We've ordered an ItsyBitsy M0 as well as an ItsyBitsy M4 to help us track down this issue. I'll let you know once we have the fix ready.

The latest beta update (Build 4691) messed up the automatic update facility. It will be fixed in the next AIDA64 beta. You will need to manually update to the new beta in case it fails.

What you're looking for is not supported by AIDA64 for Android at this time. We may implement that feature next year.

Thank you for contacting us. Please let me know what Adafruit product can we order to diagnose this issue in our own labs.

I'm glad you've managed to work it out. Thank you for letting us know about the resolution.

All NVMe SSDs (and most SATA SSDs, and most HDDs as well) have a primary thermal reading that is shown and monitored by basically all hardware monitoring software, and used as a basis of thermal throttling by SSD controllers. Certain NVMe SSDs (like Samsung 960 and 970 Series) have additional thermal readings (e.g. "Temperature Sensor 1" and "Temperature Sensor 2") that -- as some folks claim -- show the temperature of the memory and memory controller components of the SSD. Before Beta Build 4678 AIDA64 used the primary thermal reading as the temperature of the device. Following a user request, in Beta Build 4678 we've switched to using the highest thermal reading of them all as the device temperature. Then some users started to complain and argue about the validity of that solution, and expressed their concerns that all other software use the primary thermal reading. It's something that you can debate, of course. But since we've got one request (one vote basically) for the highest reading solution and many requests (votes) to switch back to the old solution, we've opted to go with the masses and put things back as they were in AIDA64 Beta Build 4681.