Upgrading to current version has now caused no video issues after the PC shuts off monitor for power saving

[DRegal]

Summary of hardware:
ASUS 570x TUFF Pro
Ryzen 7 5800x
Gigabyte Waterforce 4090
4 sticks of Corsair RAM with RGB
Icue Commander Core running 3 fans (Support turned off in HWinfo64)

Issue is as follows.
I have been running Modbro for a Raspberry PI sensor screen for 3 years, and SignalRGB for RGB control for 2 years. I was running the previous non registered version of HWInfo64 with this with no issues.
As of the last week since upgrading the following happens.

Once in a while, after being away from the PC and the screen having been shut off by windows power management, I shake the mouse to wake the PC and the monitor starts to wake. But I get the message onscreen that no signal has been detected from the DP port. No matter what I do, I can't get the PC to respond. I checked windows EVENT logs, nothing during this time. I also noticed when this happens, it appears signal RGB is crashing and restarting over and over as the RGBs go to default, then back to their programing.

I turned on Debug mode to get data, but HWinfo64 crashes on startup with Debug mode turned on.

The only way out of the black screen no DP (or HDMI) signal is to hard reset the PC.

 

[Martin]

That might be a collision between SignalRGB and HWiNFO. Try to run only one of these if the same will happen.

 

[DRegal]

I can shut off either and it works fine, but it worked fine on the previous version of HWiNFO as well. I'm trying to find a resolution to making the new version work with my setup (especially since I just bought it for $175.) During my launching in Debug mode I was prompted to download the latest Beta and as of the last day, it hasn't happened (It normally does by now) Instead of just waking up, I notice signal RGB resets the RGB lighting when I wake up the PC, but I don't get the hard lock no DP Signal and everything seems to go back to normal. What changed in the latest Beta vs the release version in that regard?

 

[Martin]

I'm not aware of any change that would directly impact this situation. HWiNFO features synchronization mechanisms to avoid conflicts with other apps but the same mechanism must be implemented by them too. And I think SignalRGB isn't among those supporting such synchronization.

 

[DRegal]

That is odd. Not sure what is different but I am running debug now so I'll see what is happening if it cuts off the display ports again.

 

[DRegal]

The one thing I've noticed since upgrading to the Beta is when the lockup happened before, now SignalRGB is effected to be sure, the lights reset their pattern when the computer wakes up and that never happened in the previous version of HwINFO, but the computer doesn't hard lock.

 

[DRegal]

Well it took a few days, but it finally hard locked with no video forcing a hard reset. I have a debug file, but its 30gb. Using GLOG or some large format Text editor is there some code or piece of it you would find useful?

 

[Martin]

Compress the file before attaching (ZIP, RAR, 7z).

 

[DRegal]

I sent you a direct message.

 

[Martin]

It's a collision between HWiNFO and SignalRGB, we've seen other issues with SignalRGB in the past.
HWiNFO supports synchronization mechanisms to avoid such collisions but SignalRGB doesn't seem so. It should be fixed there.

 

[DRegal]

Is there a scan or smbus address I can exclude from hwinfo to get by for now?

 

[Martin]

Disabling "SMBus Support" might help but you'll lose some sensors and information.

 

[DRegal]

From the logs I sent, is there a specific SMBus ID I can exclude? I don't want to nuke the whole smbus scan.

 

[Martin]

It's not a matter of a specific SMBus address but SMBus transactions in general.
Why don't you report this to SignalRGB?

 

[DRegal]

I can, it's just odd as their software version didn't change, but HWinfo I upgraded and registered and now can't even use. The old version I was using didn't crash my system.