Fiery

Such USB connected displays appear as regular monitors under Windows. You can extend your Windows Desktop onto the secondary monitor and move any windows of any software to the secondary display. So you don't have to use the AIDA64 LCD module at all, but you can simply use the SensorPanel and move the panel to the secondary monitor. Regards, Fiery

We've implemented the requested new sensor icons in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

5000 mAh

We don't aim at such deep level of customizations with our LCD module. Our LCD module is relatively easy to use while still offering deep customization possibilities. It's not infinitely customizable, but it also doesn't require a 100-page manual to operate. BTW, it's not the best way to open a meaningful discussion with "the AIDA64 lcds support is poor and ugly" and close the opening post with "aida64 lcd support is ugly poor does not offer any kind of control.... is terrible". It's one thing when you'd say "In my opinion it's terrible", and when you declare something being terrible, like you would declare the universal truth. And we do not want to buy or acquire any other software. We prefer to work with our code, developed by us from scratch. We believe that's the only way to have full control over the software, and most importantly: to provide the highest quality software. Regards, Fiery

Do you mean the actual Windows screensaver (like Mysify, Bubbles, etc) or the power-down mode of the monitor?

Thank you for your help. The issue will be fixed in the next AIDA64 beta update.

Thank you. I've just sent you a private message about this issue.

Thank you, but please note that it's not possible to diagnose such issues remotely. I could give you a few ideas, but I cannot pinpoint any particular hardware component this way I wish I could, but PC hardware is unfortunately too sophisticated, and there are too many variables about hardware components, their compatibility to each other, hardware settings, software settings, drivers, etc, etc

AIDA64 already supports fully automated internet updates since 2011. But, you need to have a valid license for it to work fully automated. If you have an illegal (pirate) license entered into AIDA64, it will only offer a download link and you have to complete the update manually. Regards, Fiery

That's normal, and it's because GPU clock reading is not really suitable to be displayed in a 16x16 pixel icon We could display "1.2" for 1200 MHz and "1.0" for 980 MHz (consider rounding), just like we do with CPU clock and memory clock, but that's not the most accurate system. Let me know if you still want us to do so

Our idea is to alter Corsair Link Software in a way that it would export the measured values using shared memory or Windows Registry. It would work quite similarly to our existing module in AIDA64 called External Applications. That way only Corsair Link Software would need to talk to Corsair water coolers and other CL compliant Corsair hardware, and 3rd party applications could only talk to Corsair Link Software and wouldn't have to access hardware at all. Very convenient, since that completely eliminates the issues about hardware access collisions. The only problem is: implementing such a feature in Corsair Link Software may be a bit tricky and would require certain development and QA resources on Corsair's part that they may or may not be able to allocate in the short run. We'll of course pester them hard enough to push them over the fence

Thank you for the dumps. I've just sent you an email about this issue.

With the latest beta, have you tried running the Cache & Memory Benchmark multiple times? Does it fail in all cases?

Very nice Thank you for the feedback!

Thank you

I suppose your overclock settings are a bit too much for your system to work stable. You need to lower the clocks and/or adjust the voltages and memory timings to make it stable. Regards, Fiery

NB Clock: I don't think it's a bug. By default, North Bridge clock is dynamically adjusted by the CPU, so it's not fixed at any certain value. Or do you have a fixed value configured in the BIOS Setup for it? As for the CPUID Panel, it's already quite crowded, so we're not planning to add any more information to it. As for Sensor Properties / Motherboard Name: it's not meant to show you the motherboard that you've got. It shows the codepath that AIDA64 uses to tweak the sensor readings to better suit your motherboard. The list of MSI product codes indicates that all those different motherboards use the same codepath for sensor tweakings. One of those IDs (MS-7976) is your motherboard of course On the DirectX Video page AIDA64 reports classic DirectDraw and Direct3D video adapter properties. Direct3D 12.x uses a different API that is currently not handled by AIDA64. You can see the DirectX hardware compliancy of your GPU on the Display / GPU page.

If it's possible, please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> SMBus Dump (Full). 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. Please do that for both the latest beta (3916) and the latest stable build (3900). What we've done since Build 3900 is increased the timeout value for the IMC of your processor. In theory that would help about slow SPD devices, and it shouldn't cause any more troubles than before. It shouldn't make any SPD devices disappear However, previously we've already seen a few examples of X99 motherboards where the IMC had issues talking to the memory modules populated on the last (4th) memory channel. The last memory module (e.g. DIMM-D1) appeared in the list of SPD devices, but there were reading errors in the SPD block and that caused various issues about detection. For example, memory module part number was read incorrectly, or some of the timings were off. It would be important to check whether DIMM-D1 SPD block can be read without errors on your system, using Build 3900. Thanks, Fiery

We do have a very good relationship with Corsair, so you can definitely expect a resolution for this issue. What you're saying applies to most sensor devices, but Asetek LC based water coolers are the exception from the rule. You cannot just passively read values from them. You have to alter the fan duty cycle (%) value in order for the device to pass back the current fan RPM and pump RPM measurements. It's a very bad design for sure, one of those that are very hard to work with. But we've come up with an idea that we've proposed to Corsair. If they accept it, then there will be a very convenient solution to this issue that would enable any 3rd party software to talk to Asetek based Corsair water coolers without altering the duty cycle setting or even talking to the device directly. The only problem is -- although this doesn't affect your case -- that such a fix would only help with Asetek LC based water coolers made by Corsair. Competitors making water coolers based on the same Asetek LC hardware (for example: NZXT Kraken) would still suffer from the same issue with their respective manufacturer made software (e.g. NZXT CAM). But that's a case for another day I know quite a bit about the background of those software development issues that Corsair has been facing in the past few years, and I can tell you one thing for sure: recently they (Corsair management) have made huge strides to fix that. So you can expect their software to greatly improve as time goes by.

We've added the 3 new lines to the SSE header, as you've requested. We've also implemented the /api JSON API that you've requested, in the way you've proposed. With the sensors tag you have to list the sensor items in the way AIDA64 calls them, separated by comma. So an example URL might be: ipaddress:8080/api?callback=myCallback&sensors=SDATE,STIME,TMOBO Both the callback and sensors tag are optional. The only quirk is that you have to place all the items you need to access via /api to your RemoteSensor layout as Simple Sensor Items. You can find the new AIDA64 Extreme beta build at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

We've added several new timings for Skylake and Kaby Lake. Make sure to upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works. Please note that tWTR is a calculated value that cannot be directly detected. As tWTR AIDA64 shows the values that the BIOS Setup and ASRock's software calls tWRRD.

Okay, I think I understand the issue now. Currently, due to hardware limitations, AIDA64 can only work with an Asetek based water cooler if you use a fixed duty cycle (%) value. If you use dynamic fan control via CL Software, AIDA64 cannot work with your hardware, since there will be a constant collision between the hardware polling done by CL Software and AIDA64. The synchronization technique that the latest CL Software and the latest AIDA64 use help in every other case but this one. We've already dropped an email to Corsair, explaining this issue. There are multiple solutions fortunately, and hopefully we can pick the one that is suitable for all users. I will keep you posted in this topic, although things may go a bit slow since we're in the middle of summer right now. Until then, you need to either use a fixed duty cycle value, or disable Asetek LC sensor support in AIDA64 / main menu / File / Preferences / Stability.

Have you tried fixing the fan duty cycle (%) value in CL Software, and set the same percentage value as Asetek fan speed value in AIDA64 / main menu / File / Preferences / Hardware Monitoring? Downgrading is not necessary. I suppose this is a different issue than the "classic" hardware collision. We'll contact Corsair and try to find a solution with them.

We've tried to implement a workaround for such situations by doing exactly what you explained, ie. multiplying the reported resolution by the DPI scale percentage. But, it doesn't always result in the right resolution, e.g. 1707 * 2.25 = 3841 pixels (rounded). And since Windows supports any kind of Desktop resolution, it is not safe to assume the Desktop must be e.g. 3840 pixels wide, and that it cannot be 3841 pixels wide. Monitor resolution should be shown on the Display / Monitor page. AFAIK it's not possible to detect the full-screen resolution when you're running another software (not AIDA64) in the foreground.

Corsair Link Software keeps evolving, and we're adjusting AIDA64 to suit the latest CL Software version. If you install the latest CL Software and the latest AIDA64, they should be able to work together, without a collision. The next version of CL Software will be even more secure about avoiding collisions. Corsair Link sensor support refers to the CL Framework. It's when you have a CL Commander central unit and you hook your devices onto it -- rather than hooking up the same devices via direct USB connection. When you have devices connected via USB, the CL Framework is not utilized at all, and so altering the Corsair Link sensor support option does nothing. I know, it's quite confusing that both the CL Software and the CL Framework are called CL, but that's Corsair's choice on the technical term.