Fiery

Thank you, but we've got 2 major issues with that. First, you quote the option being named "RemoteAPi: Deprecated Api" -- it doesn't sound like an active development API Second, using a HTTP client for such purposes would be a big overhead and we wouldn't want to go down that path. We would be happy to interface through a DLL API though, if there's one.

It is possible, as long as you can come up with a detailed specification on how to handle the proposed DLL. E.g. calling convention, string type (Ansi or Unicode), image format (raw bitmap is okay? or PNG? or both?), picture parameters (24-bit RGB? or 32-bit ARGB? or both?)

As far as I know, there's no JDownloader API that a 3rd party application could support, and there's no SDK either. If there's one, please let me know where can we check it out Thanks, Fiery

If you use classic Intel SATA RAID, then AIDA64 will be able to show RAID members just fine.

I can't promise to deliver a working solution in a few days, but we'll do our best to make it happen soon

Thank you for the info. We ordered a Corsair RMi PSU today, to help us figure out how the RMi protocol works. I'll post updates on our progress into this topic.

Thank you for the data, and apologies for the late response. In the past few weeks we've been trying to figure out how the Digifanless HID protocol works, but without an actual test hardware we've failed to solve it. So we had to order a Digifanless PSU today. Hopefully once it arrives, we'll be only a few days away from finding out how it works and implement the protocol in AIDA64. I'll post updates to this topic.

If it's possible, please discuss such traces and reverse-engineering matters in private message or email.

Thanks a lot! I've just sent you a private message about this.

Upgrading to Win10 could raise new issues, but the particular issue this topic is about was already there with Win7, so Win10 doesn't make a difference now. And please try to be more patient about certain questions

Thank you for the test. So you mean there was no new file created on your Windows Desktop?

Do you have the Corsair RM PSU connected directly to a USB port header or an actual USB port? Or you have it connected to a Corsair Link Commander device? If the former (direct USB connection), then please right-click on the bottom status bar of AIDA64 main window --> System Debug --> USB Dump. Copy-paste the full results into this topic. Please make sure to use AIDA64 latest version (5.50) to perform that dump. Thanks, Fiery

Thank you for the test. This seems to be a tough nut to crack If it's possible, please do the following: 1) Upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta 2) After upgrading to this new version, restart Windows to finalize the upgrade 3) Go to AIDA64 installation folder, and a create file (could be an empty file) named ENABLE_HWMONINIT_LOG.TXT 4) Start AIDA64, go to Preferences / Hardware Monitoring / Sensor Icons 5) If it crashes there, then please open the new file that was placed on your user desktop named hwmoninitlog.txt in e.g. Notepad. Scroll to the end of the file, and copy-paste the last few lines into this topic. Those lines should tell at exactly which point the sensor item enumeration code crashes. Thanks, Fiery

If that didn't help, then I'm afraid we ran out of ideas The problem is that somehow either Windows or RST hides the drives from our RAID enumeration calls, so AIDA64 simply cannot detect the individual drives. Unless RST can provide information for RAID member drives via the regular RAID calls, we're simply stuck.

Thank you. Can you please check if the Computer / Sensor page causes a crash? And if no, then it would also be very interesting to check whether you can generate full report with all pages included, or that causes a crash.

Thank you. We need to narrow this down a bit more. Please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> ATA Dump. Let me know if it causes a BSoD. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> SMART Dump. Let me know if it causes a BSoD. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> Physical Drives Dump. Let me know if it causes a BSoD. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> RAID Dump. Let me know if it causes a BSoD. Thank you in advance

Thank you for the data. Do you have Intel RST driver installed? If not, then please install it, because that should help AIDA64 to enumerate member drives of soft or hard RAID arrays connected to Intel SATA controllers.

There's nothing to repair there I'm afraid. That is just normal behavior of AIDA64. AIDA64 has got a mechanism to prevent date roll-back cheating. The system date has to be set correctly, otherwise the license will be refused. Regards, Fiery

No, the LCD/SensorPanel rendering engine doesn't support HTTP download or any other HTTP access. What you can do is download the image with a 3rd party tool, and insert the image to the AIDA64 LCD layout.

Thank you. Holy cow, you've got quite a few stuff in your system I'm truly impressed about the variety of hardware included in your computer. It's an amazing minefield for a software like AIDA64 to walk on Anyway, I think the issue may be related to the Aquaero, or the Profilic USB bridge. Can you please check if the Aquaero dump causes an issue? Right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Aquaero Dump.

Since the BSoD seems to be happening in the HP SmartArray kernel driver, I suppose the issue is related to the RAID array enumeration module of AIDA64. Please try to disable the two RAID-related options in AIDA64 / main menu / File / Preferences / Stability, and restart AIDA64 to apply the changes. Let me know if it helps.

Thank you for the test runs, that's a great help to narrow it down. And we do need to narrow it down, because the "Detecting sensor information" part actually polls all available sensor devices, including motherboard sensors, CPU sensors, RAM module sensors, HDD/SSD sensors, USB drives, GPU diodes, video card PWM/VRM sensors, PSU sensors, water coolers, special USB sensors, etc. If it's possible, please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump. Please let us know if it crashes there. Then right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> SMBus Dump (Full). Please let me know if it crashes there. Then right-click on the bottom status bar of AIDA64 main window --> Video Debug --> nVIDIA GPU Registers. Let me know if it crashes there. Then right-click on the bottom status bar of AIDA64 main window --> System Debug --> USB Dump. Let me know if it crashes there. If none of those crashes, or when the last dump crashes, then please copy-paste the TXT report for the Devices / USB Devices page into this topic. Since in that case I suspect one of the USB sensor detections may cause the crash. Thank you for your time and help to resolve this.

If you use another stress test software in the same time AIDA64 is also stressing your system, then, well ... It's not the best idea, since they both may not be able to perform the stress test by fully loading your system due to the concurrent usage of system resources. But if you want to do that, and you run another GPU stress test, then it's best to not use the GPU subtest in AIDA64. I'd say 12-24 hours, but in most cases users deem it's too long to let the computer sit and just sweat under the stress test and preventing them from using it But a few hours is the bare minimum if you really want to find out how well your system works.

It's weird, since it works fine for me, under Win10 64-bit. Do you have any special window management software installed? Or any other software that may affect how windows are rendered or handled?

I'm afraid we cannot use HTML embedding or HTML queries with classic LCD/VFD screens. The rendering engine for those displays aren't HTML-based.