Fiery

Thank you for the tip. At the first look it still doesn't seem to support ATA passthrough, so we'll need to do a bit more research to find out what's been changed. I'll get back to you in this topic once we have an update on this matter. Thanks, Fiery

Thank you for the feedback. We've done several test runs on our nForce chipset based test systems, but found no such slowdowns. However, I can see in your report that you have an USB card reader connected It may cause the slow-down, so we need to skip scanning that device. In AIDA64, please navigate to the Devices / USB Devices page, and press right-click on "USB Devices" in the left menu, and select Quick Report --> Plain Text. Please copy-paste the section (10 lines) relevant to your card reader into this topic. Thanks, Fiery

If you mean Unwinder, then yes

Apparently this issue is due to the usage of synchronization mutexes across those monitoring software. An initiative started to re-standardize the mutexes, using Global namespace: http://www.techpowerup.com/wiki/doku.php/systool/mutexes_to_avoid_collisions Most monitoring software has already been adjusted accordingly, but Rivatuner, MSI Afterburner and EVGA Precision are still behind. We've already contacted the author of those software, and been promised their next release will move to using Global namespace. Until that happens, please try to avoid running those software and AIDA64 simultaneously, if possible. Regards, Fiery

Such weird core temperature readings usually occur when one unlocks disabled cores of an AMD processor, and/or when the ACC feature is activated. Please verify if the core tempeatures are zero in HWMonitor latest version as well.

Thank you for the feature request. We'll try to implement that in the next stable release of AIDA64. Regards, Fiery

We've contaced the authors of EVGA Precision and MSI Afterburner software, and we've been promised they update their software to use Global namespace for synchronization mutexes. I'm not sure when the updated versions of those software would be rolled out though, since we're very close to xmas.

Are you running any other hardware monitoring, overclocking or tweaking software in the background? E.g. Asus PC Probe, Asus TurboV, ASRock OC Tuner, EVGA Precision, AMD OverDrive, Rivatuner, GPU-Z, HWMonitor, etc? Make sure to close all of them, because they may collide with the low-level hardware monitoring module of AIDA64.

Are you sure it's 100% accurate at both idle and under heavy load? We too had DES support, but it wasn't suitable for all motherboards, and it was rather inaccurate at times. Sometimes at idle it produced proper values, but at load things fell apart. Unless Gigabyte is willing to provide us a SDK or other programming manual, we won't risk another try. Mostly because Gigabyte has a habit to revamp the DES support between socket generations and processor families, so even if we would make a working DES for P55 motherboards, it will most likely be useless for P67 motherboards.

We changed the mutex handling in Build 1176. We moved the mutexes to Global namespace to follow the trends of other software: http://www.techpowerup.com/wiki/doku.php/systool/mutexes_to_avoid_collisions (this page hasn't been updated yet to reflect AIDA64 moving to Global namespace) It may affect other software that uses the old synchronization mutexes. Those mutexes are there to assure no conflicts can occur between various applications, when e.g. you're running AIDA64 and EVGA Precision, or AIDA64 and HWMonitor side-by-side. Please clarify whether you are running any other hardware monitoring, overclocking, tweaking or diagnostics software simultaneously with AIDA64.

Due to lack of documentation, the Gigabyte DES support was inaccurate and produced false current & power values. We couldn't get a documentation for DES, so we opted to remove DES support to avoid displaying inaccurate values. Regards, Fiery

I don't think anything changed between Beta 1170 and Beta 1176 that could explain that... So switching back to Beta 1170 may not help about this issue.

Please try to enable the option "nVIDIA GPU SMBus access through nVIDIA ForceWare" in AIDA64 / main menu / File / Preferences / Stability. Let me know if it helps. Thanks, Fiery

Thank you for the feedback

Actually, the problem was that with Logitech v7 software G19 was handled as G15, so colour LCD support was broken. But as DogBite stated, it's all fixed now

Yes, that option is there for troubleshooting. I'm glad it helped in your case as well

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

Logitech specified the version information in their LCD API DLL file wrong in this release, and that broke the LCD support in AIDA64 We've implemented a workaround in the following new beta release of AIDA64 Extreme Edition: http://www.aida64.com/downloads/aida64extremebuild1176sdv5ynm2gczip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works. Thanks, Fiery

1) Please let me know you hardware details, especially the video card (or video cards) model. 2) Which version of AIDA64 are you running? 3) Do you have everything else (except for the GPU temperatures) shown correctly on the Sensor page? Please copy-paste the full content of that page into this topic -- or create a screen shot. Thanks, Fiery

I'm afraid the current solution is the best we can do That board (and actually all EVGA X58 chipset based boards) uses a shared register for NB and CPU temperature, and uses a special register switch to switch between the two readings. AIDA64 does everything "by the book", but still, the switch sometimes does not happen, and so the temperatures got mixed up (e.g. CPU temp is shown as NB temp, and vice versa).

No special fonts used in AIDA64. I guess when you adjusted your regional/language settings in Windows, you didn't configure the language for non-Unicode programs to your language. You can easily change the language in AIDA64. Just click on the first menu (File), then select the first menu item from the File menu, and that will lead you to the language selection list. Select English there, press Enter key, and it should work from there An alternative, more "destructive" solution is to completely remove the non-English language support from AIDA64: navigate to AIDA64 installation folder, and delete all files with a filename that starts with "LANG". Also remove the whole folder named "Language" if it exists. Regards, Fiery

AIDA64 only implements built-in (native) support for Logitech G13/G15/G19 LCDs. But I'm sure every popular LCD solutions will eventually implement support for AIDA64 as a plugin.

AIDA64 features a lot of improvements about RAID controllers and RAID SMART monitoring And more to come

Uncompressing an ASPack compressed EXE/DLL file is not that easy I'm afraid. You have to use Google to find a tool for that -- but those tools in many cases simply fail to work That's for Linux, it's not useful for us

acEverest.dll file is compressed using an executable compressor. I think it's ASPack. In order to give you hints on how you can patch the DLL file to make it suitable for AIDA64, we would need an uncompressed DLL file.