Fiery

I'm afraid we don't have a tool to diagnose that issue. As you can see from how Windows Process/Resource Monitor gets stuck, the issue is deep down in the driver stack of Windows. I guess only Microsoft can get to the bottom of this

I'm afraid we couldn't reproduce the issue on our own test systems Please let us know a bit more about your hardware configuration. What kind of video card(s) do you have? And what's the Corsair hardware you referred to? Is it a Hydro Series water cooler perhaps?

Sometimes the old beta gets stuck in a page cache, in which case it's necessary to press Ctrl+F5 in your web browser

Thank you, we've fixed it up 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 Thanks, Fiery

That's actually a complicated issue. Yes, it would be relatively easy to add GPS readouts to the existing AIDA64 for Ubuntu Touch app. But we're ambivalent about going down that path, and not just about the actual app in question, but about other AIDA64 mobile apps too (like AIDA64 for Tizen, AIDA64 for Windows Phone). That's mostly because of the additional permission (called "location") that we would have to request for. Unfortunately the Ubuntu Touch OS doesn't offer fine-grained permissions management like Android 6+ and iOS7+. So users cannot grant or revoke individual permissions in case they find one or more of them suspicious or feel that they would invade their privacy. Either they accept the list of permissions our app requests, or they refuse to install the app. And the current list of requested permissions (camera, networking, sensors, webview) is already excessive to many users -- even though we've explained in the app's description why our app needs them. The users' biggest issue is of course the camera permission. But just like with every other mobile operating systems, sadly Ubuntu Touch also couples camera capabilities detection with taking photos/videos. So a sysinfo app cannot just request a permission called "camerainfo" or "cameradetect" or such, it has to request for the full camera permission, like if it wanted to take photos/videos And the existing list of permissions, especially the camera one, coupled together with asking for the user's exact location (via requesting the "location" permission) may just be a big red flag for many users. We don't want to risk making our app look suspicious of spying or being mistaken as a malware by doing that. I suppose it would be easier and less risky to just develop a separate app, dedicated to providing GPS info. But we believe it's best to focus on a single multi-role sysinfo app, rather than fragmenting the app into multiple simpler apps. We'd much rather wait for Canonical to introduce a fine-grained permission system that would be perfect for apps like AIDA64. Then we could add even more optional permissions to read even more information about the hardware and software environment. Regards, Fiery

Yes, the SHA2 update KB3033929 may be related to this issue. Make sure to install it, it's an important update to Win7: https://www.microsoft.com/en-us/download/details.aspx?id=46148

Do you have all available Windows 7 updates installed?

Anytime

Install the Intel NVMe driver, and it will work fine again Intel's own driver also improves the performance of 750.

Maybe it's because the order of physical disk drives change after you connect the VHD? Maybe the drive is there, it's just at a different drive index, and that confuses the AIDA64 LCD module.

I don't think it's that important, since 32-bit x86 is already supported in the AIDA64 for Ubuntu Touch .click package, and all AMD64 (x86_64) processors should be able to execute 32-bit x86 binaries. Just as 64-bit ARMv8 binary is not necessary, since such processors are perfectly capable of executing the existing 32-bit ARMv7 binary in our .click package. Regards, Fiery

What driver do you have installed for your SSD? Is it made by Intel? And if so, what's the driver version you have installed? And what Windows version do you have installed? Thanks, Fiery

Are you sure your CPU load is similar before and after hibernation? Have you tried to check the power measurements using HWMonitor or HWiNFO as well?

When AIDA64 loads its kernel driver, it uses dynamic driver loading. Dynamic driver loading causes Windows to flush its driver cache and initialize it again. It usually takes no more than 1/10 of a second, as long as all the drivers are fine. In your case I suppose one of the drivers is acting up and causing that very long penalty. Try to check what devices do you have in your Device Manager, and if you can see any that could be disabled, try to disable them. You may also want to disconnect any external devices, like external HDDs or special USB-connected devices, maybe one of them is the culprit.

There are tons of those out there, and we've never purchased any of them, so I have no idea which one is nice and which one isn't. In the specifications they should mention Windows compatibility, DisplayLink or such. If you want to go for sure, then pick one with a DVI, HDMI or DisplayLink connector. Then it wouldn't need a driver at all, and you could connect it to any video source too (like a DVD-player or such).

We've just found a workaround for the Ubuntu Touch OS version detection issue. Also, we've renamed the "Android Version" line to "Android Subsystem Version" to avoid further confusion. The AIDA64 for Ubuntu Touch app has already been updated in the Ubuntu Store as v1.0.1.

SensorPanel is definitely less complicated than an external LCD that does not appear as a monitor under Windows. You can use the SensorPanel with a HDMI connected display, since those devices appear as a monitor under Windows.

Yes, it's because Ubuntu Touch devices feature several portions of Android actually The reported Android version is not the OS version, but the Android subsystem version. Here's how the Ubuntu Touch architecture looks like: Ubuntu Touch OS version cannot be detected due to platform issues about too strict sandboxing (confinement) solution called Ubuntu AppArmor. AppArmor prevents not only regular apps to detect certain system details like Ubuntu Touch OS version, battery readouts and temperature measurement, but also cripples built-in Qt5 APIs that would otherwise be able to provide some of those details. For example: * Ubuntu Desktop / 16.04 LTS (latest updates) QSysInfo::productType(): "ubuntu" QSysInfo::productVersion(): "16.04" QSysInfo::prettyProductName(): "Ubuntu 16.04 LTS" That one was an unconfined environment where everything worked out fine. But, if you call the same Qt5 APIs on a phone where AppArmor confinement is enforced, you get the following values: * bq Aquaris E5 HD Ubuntu Edition / 15.04 (OTA-11) / Device Image Part 20160524-63b1875 QSysInfo::productType(): "unknown" QSysInfo::productVersion(): "unknown" QSysInfo::prettyProductName(): "Linux 3.4.67" This is an oversight on Canonical's part, but we've already notified them about this issue. Once they fix it up, our app will be able to report Ubuntu Touch OS version on the OS page. I wouldn't expect that to happen before OTA-14 though, so this fall the earliest. Regards, Fiery

AFAIK none of them are produced anymore, so you cannot get them brand new anymore. The last series consisted of the 800P, 1000P, 800W and 1000W models. I'm not sure if the "W" version was a successor to the "P" version though.

A constant zero percent CPU throttling means your CPU is not overheating. So it's the best scenario of them all That's why the throttling graph is green at 0%, and turns red at any other value. Regards, Fiery

Yes, it can still happen, since even if you disable all items, the sensor module will still poll many of the sensors. The AIDA64 sensor module has some degree of granularity, so you can disable polling certain sensors by picking from the list of shared memory items, but you cannot disable the main part that polls motherboard and GPU sensors, as well as a few other external sensors devices. Thank you for the list and the extra info! Now we'll try to reproduce the issue on a local test system of ours. Please give us a few days to do that

We believe the issue is related to one of the sensor items you export via shared memory. Can you please send us the full list of IDs you export via shared memory? The easiest way to do that is to locate AIDA64.INI file in the installation folder of AIDA64, and find the line that starts with: HWMonExtAppItems= Please copy-paste that line into your post if possible. Thank you in advance!

Only Samsung SPF and AX206 hacked digital picture frames can display data that you pass through the USB port. No other picture frame can do that I'm afraid. Even Samsung SPF frames have such variants that aren't capable of that feature. And AX206 frames are usually very small, so definitely not something you would want to use.

Please note that we've just rolled out a new update to our AIDA64 Windows 10 UWP app, version 2.0.8.0. The new update implements a dark theme, and a new command bar button to let you switch between themes anytime. I hope you'll find the new design appealing

The closest might be a Samsung SPF digital picture frame. But, some versionso of that device suffers from overheating issues, and also you cannot get one brand new anymore. Mint 2nd hand ones going on the 'bay also tend to be a bit expensive. Some AIDA64 users opt to get an old and/or cheap Android tablet and use Odospace: https://forums.aida64.com/topic/2776-display-pc-sensor-values-on-android-device-connected-via-usb-odospace-remote-panel/ But, you will see that there's no perfect solution out there. A big screen that doesn't act like a monitor, and has direct USB connection is very rare. Most users expect such big displays to work as a secondary monitor under Windows/OSX/Linux. It's even more difficult to find a big screen with fast USB connection that provides fluid full-frame refresh rates. For example, Matrix Orbital makes some great looking large displays with USB connection (e.g. GTT70A), but they all use a very slow serial protocol that is not suitable to be used with the AIDA64 LCD module. Not to mention they're bleeding expensive too