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.

Yes, that pretty much what needs to be done on all systems, regardless of the CPU model or motherboard type.

Our CFA634 was bought not that long ago, but last year, and it has FW 3.1 in it. When we power up the display, it shows the firmware version as "FW 3.1". What does yours show when it powers up? I suspect yours has got an older firmware (perhaps "SKD204-634 V2.2" means it's FW version 2.2 -- or maybe PCB version 2.2). If it's the case, then we will have to find out how to implement support for older firmware. Most likely the CFA634 communication protocol has gone through major changes in the past 10 years, and AIDA64 can only handle the later (newer) protocol.

Please try to enable the two RAID related options in AIDA64 / main menu / File / Preferences / Stability, and restart AIDA64. If it doesn't help, then please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> ATA Dump. Copy-paste the full results into this topic. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> SMART Dump. Copy-paste the full results into this topic. Also right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> RAID Dump. Copy-paste the full results into this topic. Thanks, Fiery

Do you mean embedding a certain HTML snippet? Or you would like to display another website content on the LCD?

It means your CPU scales better when AIDA64 is running those benchmarks. VP8 and PhotoWorxx are different beasts anyway. VP8 because it doesn't scale with all cores in the system perfectly, so its behavior is different to all the other benchmarks. And PhotoWorxx relies heavily on the memory and cache subsystem, so in many cases it will not scale well after a certain point because of the narrow memory bandwidth (or cache bandwidths).

No, I'm not saying 2690 is worse than 2660. What I'm saying is that we've already seen such regression in performance before, although it was more about overclocking vs. memory bandwidth and latency. Sometimes adding more resources do not mean an increase in performance. Of course, it would be best to confirm those results by running other benchmarks as well. Of course it has to be such a benchmark that could scale up to 12 cores / 24 threads per socket, and can also be limited to use only 10 cores.

1) Do you use the same AIDA64 version and the same SATA/RAID controller driver now and before? 2) Do you use the same AIDA64 settings (AIDA64.INI) now and before? 3) Are you intentionally running an old AIDA64 version?

It's definitely an odd issue. I can think of 2 issues that might explain this: 1) Turbo Boost and power limits are configured in a way that they kick in too much with all cores utilized, preventing your CPU from running at high clock speeds. 2) Haswell-EP processors may not scale perfectly when going from 10 cores to 12 cores. Maybe 10 cores mean a more ideal configuration than 12 cores, and in certain situations utilizing 2 more cores could mean a regression in overall performance or per-core performance. We've done a test run on our 10-core reference Haswell-EP Xeon system to see how it scales when going from 1 core to 2 cores, then 4 cores, 6 cores, 8 cores, 10 cores, and the scaling didn't show any regression or bump in the performance. The pecularity that you're experiencing may well be related to the 12 cores your CPUs feature.