Fiery

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.

Just run both tests after each other. If you only use the "FPU" subtest, it will test not only the floating-point computation capabilities of your system, but also stresses the cooling solution by driving your system to the highest temperatures. If your system can stand that without any issues, then enable all subtests to run a stress test with diverse computational tasks. Any properly built systems should be able to stand and pass both stress tests.

That only means the Strike7 SDK causes a crash in its DLL, and that pulls AIDA64 main process down with itself I'd be happy to help you out, but at this point we both are at the mercy of Mad Catz. If they could try this out and find the issue in their SDK and fix it up, that would of course fix this whole thing. Or, if they can find an incompatibility between their SDK and AIDA64, then we would be happy to work with them to resolve it. The main problem is that we cannot reproduce the issue on our own Strike7 keyboard. If we could do that, things would probably be a bit easier. Please try to put a bit more pressure on Mad Catz, as a customer who's having issues using their product.

Thank you. I see the point now. Can you please tell me from a technical point of view which method would suit you best out of these two: 1) Embed the HTML code directly. You would have a new LCD item type of HTML Code, and you could enter the tags and text in there, which would then be stored as a fixed HTML snippet in the AIDA64.INI configuration file. If you want to update the HTML code, you would have to reconfigure (modify) the LCD item. 2) Include a HTML code on-the-fly, from a HTML file on your computer. You would have a new LCD item type of HTML Include, and you could enter the filename of a HTML file that will be basically included in (copy-pasted into) the HTML file rendered for the RemoteSensor and Logitech Arx modules of AIDA64. And now that I wrote that last line, I came to realize that you may not be talking about those special LCD variants, but maybe a physical LCD device like Logitech G19? It would be important to clarify, because we cannot include HTML code in our classic LCD/SensorPanel rendering engine -- but we can do that for the HTML based LCD modules, namely RemoteSensor and Logitech Arx.

Do you mean CPU fan or CPU temperature reading? If it's the CPU fan, then such issue could happen when the fan is spinning too slow at idle, and the motherboard sensor chip cannot pick up the fan RPM.

Embedding a fixed HTML code would be a lot less difficult than to embed content from another website. Can you please tell me what is the goal with this feature? If it's not to be published on the forum, then please send me in private message. I'm really curious how someone would actually utilize such a feature.