Fiery

No, it's only related to the driver that a particular SATA controller uses. Drivers can differ between Windows installations, and even a newer driver of the same kind (e.g. Intel RST) can bring substantial changes. As for the BSoD: when a SATA driver gets confused about the drive interrogation commands that AIDA64 sends, the BSoD comes up at AIDA64 startup, while the AIDA64 splash screen says "Scanning RAID Devices" or "Scanning SMART Devices".

Wow, that is an awesome looking SensorPanel It must have been a hell of a job to construct that layout, well done!

I'm not sure what you mean by that AIDA64 should already support Poweradjust devices, along with all other Aquaero devices that provide sensor readings. In case the measured values are off, you can calibrate them using the Correction feature of AIDA64. Just go to AIDA64 / main menu / File / Preferences / Hardware Monitoring / Correction.

Without RAID SMART support enabled, AIDA64 can only read temperatures from those drives that appear as regular IDE-compatible drives in Windows. With RAID SMART support enabled, any special cases are also supported. You can leave RAID SMART support enabled if you don't experience any stability or performance issues that way. It's not harmful to have it enabled. There's an option to let you disable it only because in some rare cases RAID SMART support can make a SATA driver throw a BSoD. But you would have noticed that already if your system suffered from such an issue

The option is still there in the INI file (named HWMonSPLCDJPEGLimit), you can adjust it from there. We do not plan to add it to the AIDA64 Preferences, since we don't think that option should be used generally. Yours is still a special case, but you can still control the JPEG file size limit via the INI file. Happy New Year!

Maybe ULPS is not enabled in Catalyst (Crimson) under Windows 10 due to technical or other issues? Win10 uses WDDM 2.0, and that brings major changes in video drivers too. Maybe AMD will enable ULPS only in future video drivers under Win10.

We will add the requested new sensor items in the next AIDA64 beta update due next week I will post a message into this topic once the new beta is available for download. Regards, Fiery

In the next AIDA64 beta update (due next week) we will fix that by renaming Fan #1 and Fan #2 on Sabertooth Z87 and other capable Asus motherboards to Assistant #1 and Assistant #2. That way you'll be able to measure all fan RPMs with AIDA64. I will post a message into this topic once the new beta is available for download. Till then, Happy New Year! Regards, Fiery

Only such a picture where all chips can be identified. So it would have to be a high-resolution + high-quality picture, which is hard to capture when the motherboard is already built into a PC chassis. But, if you could find chips on your motherboard that can be EC (Embedded Controller) or sensor chips, that would be great. If could be a tough job though, and if you find an EC -- which I think you would --, it would still be of little help considering the issue that I've explained above. There's a slim chance you could find a classic sensor chip as well as an EC, and in such case we might be able to solve it without the assistance of HP. But, we've seen thousands of different motherboard sensor chip solutions, and yours doesn't look anything like any of those, so I don't think there's a sensor chip there afterall, but only an EC. I really wouldn't want you to go through all the chips you can find on your motherboard to try and find an EC or sensor chip, but if you have plenty of time, a good eye-sight, and you'd like to contribute in an attempt to solve this issue, then we would of course appreciate your help on this.

The SSD? No. The SATA controller where the SSD is connected to? Maybe Polling SMART information is done via calls to the SATA/IDE controller driver, and there anything could go wrong. Fortunately it's very rare that things go wrong, but it could happen.

The old AIDA64 version handled ULPS in the very same way as before we've applied the 2 workarounds in the recent betas. The only difference may have been that an old AIDA64 version may have been unable to report anything about R9 Fury Series And when it comes to an unknown GPU, AIDA64 will not read anything from it, so it won't cause any issues when ULPS is active. As for Windows 10, it's hard to tell. I personally have made the upgrade on all my personal computers, but it doesn't work flawlessly. I still believe Windows 7, even at its RTM state was a more mature and more roboust OS. Windows 10 will soon get to that level of maturity, but it's just not there yet. If it weren't useful for AIDA64 development purposes, I would have waited until the Redstone Update (Spring 2016) for moving to Win10. One thing absolutely great about Win10 though is the UWP app development using Visual Studio 2015. It's just very smooth, and it makes app development light-years easier than before (using Win8.1 + VS2012). But, it's sadly a niche "market". Most app developers are still not interested in making Windows apps, and I suspect most of them won't change their minds before next summer (the earliest).

Thank you for trying to contact HP. What we would need is: technical documentation or proper programming guidelines on how to handle the Embedded Controller chip in order to read out temperatures, voltages and fan speeds. Even a very limited, very focused set of information would be a great help. Just to explain our situation with a bit more details... There's a big difference between mobile systems (notebooks, laptops, tablets) and classic desktop computers (desktop PCs). With desktop PCs temperatures, voltages and fan speeds are usually measured by a sensor chip that is integrated to the motherboard. Such sensor chips are usually manufactured by either Fintek, ITE or Winbond/Nuvoton. Handling those sensor chips are quite easy, since they are well documented, they follow industry standards, and there aren't tons of variations of them. Contrary to that, mobile systems are usually equipped with Embedded Controllers that are reprogrammable to suit the vendor's (in your case: HP) needs. So even by having documentation on the chip itself wouldn't help at all to figure things out. Embedded Controllers can work very differently even across models of the same computer brand, and there's no industry standard way of handling them. The only good thing about them is that some computer vendors (namely Apple, Asus, Dell, and Sony) came up with their own standards, so with such mobile computers reading sensor information out is almost as easy as with desktop computers. But the rest of the mobile world is a big pain, and in most cases we can only figure out how to read sensor values from the Embedded Controller if we can gain access to a physical system for a few days at least. And even though your system is a desktop PC, it looks and acts like a mobile system: it's not equipped with a sensor chip, but an Embedded Controller of some sorts. So it falls under the same "painful" category as mobile computers about this issue...

We will implement the requested feature in the next AIDA64 beta update due next week. I will post a message into this topic once the new beta is available for download.

Something between 12 and 24 hours is best.

I'm sorry, but the crash is due to ULPS, so there's nothing to log about that. We could log all GPU register readouts to see which register reading causes the crash, but since ULPS crashes on any registers you try to read when the GPU is asleep, having a register index wouldn't help at all. As I've previously mentioned, to assure 100% stability when ULPS is enabled, we would have to check GPU sleep state before reading or writing each GPU register. And that would make GPU polling very slow, so it wouldn't be any better than the other workarounds. As for the 30 seconds issue, that could be caused by many things. It may or may not be related to GPU polling. What you can try is right-clicking on the bottom status bar of AIDA64 main window --> HWMon Modules, and disable those modules one by one, by removing the ticks next to them. Start with HDD, then disable GPU, and then go on until you find the culprit. You may need to enable status bar in AIDA64 / main menu / View first.

Thank you for your feedback It wasn't easy to solve the USB protocol AXi PSUs use, it was full of tricks and pitfalls. But I'm glad it works now. Regards, Fiery

Interesting... But it shouldn't be a problem, since Afterburner is synchronized with AIDA64 and other monitoring software.

While waking up, Catalyst may have reported that the GPU is not sleeping anymore, but the GPU was still not ready to accept GPU register readouts properly. As you can see, it's still a messy situation. I'm not sure what HWiNFO64 does differently, but I'm pretty sure ULPS will not work with it 100% reliable either, at least if you let it run for a few hours. We and also the authors of several other 3rd party applications have been nagging AMD for years to solve the ULPS issue. But for some reason they don't listen and just keep pushing their solution as is. It's a lot like how Asus refuses to fix AI Suite, so AMD is not alone at being hard-headed

Yes, it's normal. All measured values, including GPU and GPU memory clock, GPU temperature, GPU voltages, GPU fan RPM will turn to zero when the GPU in question goes to sleep.

Thank you, I hope we can continue working together Quite frankly, I have no idea what that option does. The problem with ULPS is that there's no 100% sure way to avoid having issues when it is active. The way it works is: when you try to read a GPU register, like the one used to calculate GPU clock, or another one used for measuring GPU temperature (etc), and the GPU in question is asleep (due to ULPS previously put it to sleep), the system will throw a fatal error. What we do now is try to detect if the GPU is asleep before reading out GPU properties and before polling GPU sensors. In theory that should help to avoid issues, but there's a slim chance that the GPU is not asleep when we check the sleep state but goes to sleep right after it -- but before we actually start reading various GPU registers. Or it could go to sleep between reading two GPU registers, etc. It would be the safest to check GPU sleep state before every GPU register readouts, but that would make polling GPU properties and especially GPU sensors a lot slower than now. The performance of that solution would be abysmal, and that's why we still stick to our previous stance: you need to disable ULPS or disable polling non-primary GPUs to make it 100% stable. BTW, when the whole issue of ULPS was first introduced, back in the Radeon HD 5970 days, we hoped AMD would solve this quickly. By simply patching Catalyst drivers it would be very easy to solve this, and there could be multiple ways to achieve the goal. For example, a software could request Catalyst for a temporary wakeup of GPUs for the time of polling GPU registers. Or, a software could request Catalyst to initiate a GPU register readout while retaining the sleep state but not ending the register readout in a fatal error (sort of a "safe GPU register readout" -- which is now not available). Sadly, so far AMD didn't implement any of such tricks to let 3rd party applications handle ULPS properly

According to our tests, Samsung NVMe SSDs work at quite high temperatures, especially under heavy load. We can rarely see anything under 40 Celsius when they are working, so I'd say 60 Celsius is definitely more realistic than 14C And yes, if you touch them, they don't feel anything cool, so it's not a temperature measurement issue. Quote from a 950 Pro review: And another 950 Pro review:

Thank you for the feedback Happy New Year!

Thank you for the feedback Happy New Year!

We've implemented support for Corsair Link sensor devices (including Link Commander, Commander Mini, H80, H80i, H100, H100i, H100i GT, H110i, H110i GT, and various Corsair Link capable PSU models) in the latest AIDA64 Extreme beta update available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Please note that since Corsair's own Corsair Link software is not synchronized with any other monitoring software, it is very important to make sure it is closed, and also that its background service is not running. It's best if you completely uninstall the Corsair Link software. Due to the special precautions required to use the new Corsair Link feature of AIDA64, it is disabled by default. You have to go to AIDA64 / main menu / File / Preferences / Stability, and enable (check) Corsair Link sensor support to activate the new feature. Let us know how it works on your system. If you find any issues, please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Corsair Link Dump. 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. Also right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> USB PSU Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post.

We've implemented support for Corsair Link sensor devices (including Link Commander, Commander Mini, H80, H80i, H100, H100i, H100i GT, H110i, H110i GT, and various Corsair Link capable PSU models) in the latest AIDA64 Extreme beta update available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Please note that since Corsair's own Corsair Link software is not synchronized with any other monitoring software, it is very important to make sure it is closed, and also that its background service is not running. It's best if you completely uninstall the Corsair Link software. Due to the special precautions required to use the new Corsair Link feature of AIDA64, it is disabled by default. You have to go to AIDA64 / main menu / File / Preferences / Stability, and enable (check) Corsair Link sensor support to activate the new feature. Let us know how it works on your system. If you find any issues, please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Corsair Link Dump. 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. Also right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> USB PSU Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post.