Fiery

Thank you for posting that idea. It looks like it's a very specific usage scenario, so I'm not sure if AIDA64 should provide a ready solution for that. Let's wait and hear if others would like to have it implemented as well. Regards, Fiery

1) Which version of AIDA64 are you using? 2) If it's possible, please export the LCD settings, and attach it to a message in this topic, so we could check it out. Thanks, Fiery

Thank you. Your monitor will be added to the next AIDA64 release due October 29th Regards, Fiery

Close AIDA64, launch Registry Editor (REGEDIT.EXE), navigate to ... HKEY_CURRENT_USER\Software\FinalWire\AIDA64 ... and remove all keys there that starts with OSD. Then start AIDA64 again, and hopefully OSD will revert back to its default position of right edge of the primary monitor. Regards, Fiery

Thank you. Your monitor will be added to the next AIDA64 release due October 29th. Regards, Fiery

I'm sorry, but the whole AIDA64 hardware monitoring module works together, "moves" together, so it's not possible to pick an item and make it update faster than the whole big module

Thank you. We've checked, and unfortunately this is not an easy one Apparently a lot of things have changed internally in AVG 2013. We'll need a bit more time to investigate and try coming up with an anti-virus database detection for the new AVG release. I'll let you know in this topic once we have an update to this matter.

Thank you for the feedback. +3.3V, +5V and +12V are not supported, because of ECS's decision. Any sensor chips could monitor those rails.

I'm glad you managed to work it out

That means AIDA64 may show its main window outside the Windows Desktop for some reason, or on a secondary display that is not connected or somehow misconfigured. Please try to close AIDA64, and remove the following Registry path (and everything inside it) using REGEDIT.EXE: HKEY_CURRENT_USER\Software\FinalWire Also, go to AIDA64 folder, and if there's an AIDA64.INI file, make sure to delete it. That should revert all AIDA64 settings back to default. If it still doesn't work, then please check if there's anything you can configure about multi-display support in Windows to make AIDA64 display its main window properly.

Thank you. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2160fptz1dcy6xzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works.

Since it's quite hard to debug this issue (due to the BSoD takes at least several hours typically to come up), the best way is to try downgrading to an older RSTe release, in a hope that they're more stable...

Because in such case no calls are made for the ATA layer of Intel RSTe drivers. But the bug is still in the RSTe drivers.

When both RAID options are disabled, AIDA64 will use standard Windows API calls to detect ATA devices and to acquire SMART attributes list incl. disk temperature (if available). It means, if that causes a BSoD, it is caused by the storage controller driver, so it should be the fault of Intel RSTe drivers rather than AIDA64's.

AIDA64 v2.60.2153 (latest beta release) should be fine for your motherboard. Please try to uninstall AIDA64 completely, restart Windows, install v2.60.2153 Beta, restart Windows again, and try AIDA64. If it still doesn't work, then please let us know exactly what happens after clicking on the AIDA64 icon, and also let us know if you've got any Asus software or other hardware monitoring, tweaking, overclocking or stress testing software installed. Thanks, Fiery

There's no clear formula, especially since there are command delays, data throughput, data latency and a lot of other factors involved.

Since there're several other factors (like memory controller's own latency), it's not possible to directly translate clocks+CL/RCD/RP/RAS timings into memory latency. Please note that clocks and CL/RCD/RP/RAS latency values are detected, while memory latency is measured.

That's normal, and it is caused by the low-level EC (Embedded Controller) access features of AIDA64. You can simply ignore those warnings, they're just notifications by the ACPI EC driver of Windows. Regards, Fiery

When you've got a Logitech LCD keyboard, there're two methods of starting AIDA64 at Windows bootup. First is the classic method of using the option in AIDA64 Preferences / General page, which starts AIDA64 from either the Registry's relevant Run section (under Win2000/XP), or using the Task Scheduler (of Vista/Win7/Win8). Using this startup method may cause issues when bootup order of software and drivers get mixed up. Second method is using the Logitech LCD Manager to launch AIDA64 when it starts up the applets. I suppose in your case this option should be used, and the classic startup method in AIDA64 Preferences should be disabled. That way LCD Manager will launch AIDA64 when it initializes the LCD applets. Regards, Fiery

I'm afraid it's not possible, since the underlying hardware monitoring module has such parts that take 200 to 500 milliseconds to complete, hence a sub-second refresh rate would mean a constant polling of sensors that would put high load on the system and may cause unexpected issues Regards, Fiery

I'm afraid not yet We haven't been able to reproduce the issue on our test systems. We'll do more test runs soon, but first we need to get more test boards, more specifically one that is identical to yours

Actually, using custom gauge states is already supported by the latest AIDA64 Extreme Edition beta. So you can use Photoshop to design your own gauge states, and add them to the SensorPanel.

Scripting in AIDA64 Business Edition is available only for reporting and network audit purposes. The Disk Benchmark and System Stability Test modules are not automatized in either editions. With HDDs you can use any tests in AIDA64, they will not shorten the lifespan of the drives. Solution a) is a good one to stress multiple HDDs, but it can also be used to stress all local disk drives in parallel, incl. any SSD+HDD combinations.

666 MHz means your memory cycle time is 1.5 ns, which equals to 1T. The memory chips are made of a matrix of cells, where there are a certain number of columns and rows. The 4 timing values represent the time your memory chips will take to access a row, a column, and then finally the actual data. The first 9 means CAS Latency = 9T = 9 x 1.5 ns in your case. The second 9 is for RCD, the third 9 is for RP, and the 24 is for RAS. It's quite a complex method, but you can read more about it at: http://en.wikipedia.org/wiki/Memory_timings Regards, Fiery

1) System Stability Test stresses all local disks simulatenously, but only as long as they contain a partition table and they have files on them. This is because that test is a file system test, so it relies on the existence of files on the tested drive(s). 2) It's not recommended to use the write tests on SSD drives, due to them wearing out SSD flash memory cells. You can however use the new Linear Write + Verify test (of AIDA64 Disk Benchmark) once on each new drive to see if it has proper data integrity. That will only consume 1 write cycle for each cell, so it's not excessive in terms of wearing the memory cells out. 3) Another alternative is using the read tests of AIDA64 Disk Benchmark in a loop to drive them all night long. The only limitation is that you can only stress a single drive at once, so you need 3 nights to test 3 drives. I'm afraid AIDA64 has no more advanced features than the ones above. No offense, but your application scenario is quite unique It's not everyday an AIDA64 user buys 3 new drives that he/she wants to burn-test simultaneously and quickly. Regards, Fiery