Corsair Vengeance sensors only logging at boot, before disappearing

[VortexSupernova]

I've tried to fix this problem but cannot identify where to start. I've tried BIOS settings but I know it's not the BIOS. My RAM shows up and the sensors work... for under a minute. Some program or background task interferes and then the sensors just stop, and then a couple of the sensors themselves disappear. Help would be much appreciated! I can't upload the .dbg file because it's too large, even though it's only 2-3mb. I uploaded the report, however.

 

[Martin]

Are you perhaps running some other monitoring or RGB control software along with HWiNFO? That could be causing this.

 

[VortexSupernova]

Are you perhaps running some other monitoring or RGB control software along with HWiNFO? That could be causing this.

Fan Control, OpenRGB, but if I close both of them, the issue persists. I don't have the gigabyte control centre installed (I uninstalled it just in case) as it interferes with RGB sometimes

 

[Martin]

Are you sure that just closing them is enough? They might still have services running in background.

 

[VortexSupernova]

Are you sure that just closing them is enough? They might still have services running in background.

Well, the monitoring things I usually have running are as follows: OpenRGB, Fan Control, and Process Lasso.
I have HWINFO and GPU-Z and CPU-Z installed but I don't run them in the background. I only open them to check something and then close them again.
I will try cancelling their processes from task manager though and update you on it
Edit: I also have WD Dashboard to open on startup and it's usually a background task (I only have the monitoring set to function when the task is on my screen, so it won't monitor anything in the background... allegedly)
Edit 2: I also have Razer Cortex and Synapse installed, as well as the affiliated Chroma plugin for my Razer mouse and keyb, if that helps. They run in the background. I ALSO have MSI Afterburner running an undervolt + overclock on the core, and it monitors... quite a lot of sensors. I'll kill both it and WD Dashboard to check if HWINFO can find the DIMM sensors again.

 

[VortexSupernova]

Update: I discovered that, if I prevented ThrottleStop and WD Dashboard from running at startup, my DIMMs would show up again and continue reporting data. As soon as I opened Throttlestop, the issue came back.
I've heard that HWINFO blocks limit readings in throttlestop from staying permanently, but I've never seen Throttlestop ERASE logging in HWINFO before. Would this be something you could address? I'd rather not turn to XTU due to all the bloat it dumps in my computer. Otherwise I can ask the author, unclewebb
Edit: DIMMs logging is gone again, but neither Throttlestop NOR WD Dashboard are open (both are set NOT to open on startup. Please I really require assistance on getting these sensors running :< )
Edit 2: I swear to god, the moment the sensors stop working, all of HWINFO's sensor data halts, and then permanently slows down after it resumes (meanwhile the DIMMs never respond again)

 

[Martin]

That looks like some other app blocks HWiNFO, especially access to SMBus which results in large delays.
HWiNFO supports methods to synchronize with other apps but if you're running one that doesn't support it on their side, such problem can happen. It has to be fixed on their side.

 

[VortexSupernova]

That looks like some other app blocks HWiNFO, especially access to SMBus which results in large delays.
HWiNFO supports methods to synchronize with other apps but if you're running one that doesn't support it on their side, such problem can happen. It has to be fixed on their side.i

Could it be RTSS (Rivatuner)? Or is that synchronised

 

[Martin]

We can't say for sure if some other application properly implements the synchronization methods. It's their responsibility and it can happen that they didn't implement it properly in all cases.
You will have to try and see which one is causing this.

 

[Fr0stX76]

SIV is what I use for monitoring/troubleshooting what software is not using the SMBus mutex properly. http://rh-software.com/

If programs are accessing the SMBus and either not using the locks at all or create them in the Local\ rather than the Global\ namespace the SMBus access will not work correctly. SIV detects when the Local\ namespace is being used and will switch to using it which will work when there is a single session. If there are multiple sessions then Global\ needs to be used. The [Lock Usage] page displays the namespace the locks are currently within and [Lock Handle] displays the programs using the locks. When Only SIV is reported this shows no other programs are using that lock, so if other programs are reporting motherboard sensors their access will not be interlocked with the SIV accesses so the strange and unexpected may occur. All of AIDA64 + CPUZ + HWiNFO + OHM + SpeedFan + SIV should correctly use these locks and work correctly when used concurrently. ASUS AI Suite does not use these locks so should not be used when SIV is being used and doing this is unsupported. This is also the situation for most other motherboard manufacturer supplied utilities. Some SMBus drivers interlock SMBus operations using the INUSE_STS semaphore. SIV also implements this regime as addition to using the Access_SMBUS.HTP.Method mutex

From memory, OpenRGB uses the global

Edit, yep global https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/1436

Also, note that once SMBus collide happens, just closing the offender soft is not enough, you have to reboot. Best way is to to troubleshoot is to disable-> reboot.