Fiery

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

Thank you for the info, we've added those O&O software licenses to AIDA64, and fixed the 64-bit Windows issues. Make sure to upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2036mxyv0c7zkwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Regards, Fiery

We've implemented the changes you requested. Make sure to upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2036mxyv0c7zkwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Regards, Fiery

Cca. 70 Celsius is a bit high for core temperature, but not critical. You can check the maximum working temperature (TJMax) on the Motherboard / CPUID page in AIDA64. Regards, Fiery

Thank you for the feedback

What GTX670 and GTX680 cards can measure is not an absolute Wattage value, but rather a "Percentage of TDP" value that is not really easy to fit into the existing hardware monitoring module of AIDA64. We'll work on it though

First of all, please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2029bcq0xs8flwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Then please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> Disk Controllers Dump. Copy-paste the full results into this topic. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> RAID Dump. Copy-paste the full results into this topic. Thanks, Fiery

I'm sorry, but having a very small gauge size plus a different style where red colour would be at the low end of the scale is not something we'd want to do at this time -- unless we get more user requests on the same idea

100 MB/sec is very low difference on modern processors.

I think we've figured out what the reason behind the C-State anomaly. Apparently Intel Turbo Boost only considers a core sleeping (inactive) when it enters either the C3 or C6 state: http://download.inte...nots/320354.pdf (Check 3.3 and 3.4 in the PDF) Hence, if you disable C-States (C3 and C6), Turbo Boost will work less efficiently. And that effectively means that single-threaded performance will suffer when you disable C-States. It is reflected by AIDA64 memory benchmarks which are single-threaded benchmarks. It will not be reflected by multi-threaded benchmarks like AIDA64 CPU and FPU benchmarks -- or Sandra memory benchmarks for that matter. BTW, if you check the measured core clock on the Cache & Memory Benchmark Panel, you may see that with C-States enabled your processor will work at a higher core clock level. On our test system (Core i7-2600 + Gigabyte Z68XP-UD3-iSSD) Turbo Boost could push the CPU up to 3.70 GHz during the memory benchmarks when C-States were enabled, but it managed to push the CPU up to only 3.50 GHz with C-States disabled.

What I meant to say was: the Gadget feature requires the Registry to pass on sensor values between AIDA64 (main application) and the Gadget. Without using the Registry it cannot work at all.

It's a false alarm. But if you're unsure, just let it remove the file, it's mostly not utilized. Regards, Fiery

Yes, it looks fine.

You can check the L3 cache performance using AIDA64 Cache & Memory Benchmark (AIDA64 / main menu / Tools / Cache & Memory Benchmark). In case your processor have L3 cache enabled, you will see it evaluated there

Do you have Asus AI Suite installed?

Please check Q#10 at: http://www.aida64.com/support/knowledge-base Regards, Fiery

Thank you for confirming the bug fix. Hopefully Roblion would also find it stable now

Thank you for the feedback

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

We've fixed the device context leakage issue. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2029bcq0xs8flwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works.

We've fixed the device context leakage issue. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2029bcq0xs8flwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works.

AIDA64 can only detect one O&O product license, SafeErase. Do you mean that software, or some other one by O&O?

It means maybe not the Shared Memory feature itself, but one of the items would cause the handle or memory leak. Can you please check what happens if you enable the Shared Memory feature, disable Registry exporting, and enable all items in the Ext.Apps items list? Then check how many handles does Task Manager show on its Performance tab, and how much memory, threads and handles does AIDA64 use for its main process on the Processes tab (there you may have to enable the Handles and Threads columns from main menu / View / Select Columns). Then play some games, and when AIDA64 or Event Viewer becomes sluggish, check the handles and threads values in Task Manager to see which one is piling up. I'm sorry to request so many test runs, but apparently on our test systems even enabling all Ext.App items, no issues can be found with the AIDA64 Shared Memory + LcdStudio combo And what we've previously thought may be the root cause of the issues is actually done properly, so there must be something else. We suspect it may be something about video driver calls when detecting GPU clocks -- or something like that. It's quite tough to diagnose such bugs

Thank you for the feedback

Yes, that's our suspicion too. We already have a theory about where the Shared Memory feature piles up the handles, but it's not easy to reproduce and verify it. We'll work on it in the upcoming days, collect feedbacks from other beta testers as well, and hopefully we can fix it up soon.