Fiery

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.

Yes, that's it.

Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2025y4wsqxjd7hzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps. If not, then please let us know what video card(s) do you have, and whether you have any RAID arrays defined or any external storage devices connected via USB, eSATA or FireWire. Thanks, Fiery

Yes, you need to remove all unwanted sections (AIDA64 information pages) from your RPF file to make sure you only get such details in your reports that you actually want to have there. Using /SAFE a lot of pages get disabled (and so not written into the resulting report file) due to AIDA64 not being able to utilize its low-level features. Prime examples are the Chipset page, Sensor page, SPD page, ACPI page, GPU page, etc.

Thank you. That's quite puzzling, since there doesn't seem to be any direct correlation between the 3 temperatures read from the onboard Fintek sensor chip and the values displayed by MSI Control Center. We'll need to do more research to try finding the logic behind that. Yes, it's normal, and it's due to the fact that GPGPU computations require a lot of traffic between the CPU and the GPU, so even though that's not the point, the CPU also gets stressed.

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

Thank you, but which one is the North Bridge temperature there? And using which method could you identify that reading as the North Bridge temperature? I'm just asking because officially your motherboard is not able to measure that reading...