Post your issues with the Trident RGB Control software here

[hyphen951]

Going from 3 of 4 working RGB sticks to 1 of 4 working after the tech support email "fix" was a bit of a frustration. Clearly a software issue that should have been resolved before releasing the product/software together. I understand them wanting to jump on the RGB hype but its really sad that you buy a product only to have to play email tag to try and get it to function as advertised.

[Patient0]

The worrying part is that they say YET.

[Tucubanito07]

OK it's a complex issue. How about some technical detail? What exactly is the problem, and what is G.Skill doing to resolve it? How does the upcoming software release differ from previous releases? Are you implementing the required mutex to access the SMB Buss with the proper interlocks? Are you actually getting other companies like ASUS to fix their poorly coded utilities? Some details would be appreciated.

I see stories about multiple RMAs and corrupted SPD data. Now customers are talking about law suits. Time is of the essence to resolve this properly. Using customers as Guinea pigs and refusing to issue refunds to those who have decided to move on is not a strategy that is going to work out well for anyone. I think it would be beneficial for G.Skill to post details of the root cause and the solution being developed as opposed to saying "Its complex". Does anyone else feel this way?

I agree with you 100%.

[BillB]

How about an explanation

We're not giving up yet guys. The issues are a lot more complex than most people think. At the moment, we're exploring the possible solutions we can think of.

If you do have a problem, please do email our tech support team at techsupport@gskill.com. It may take a few days, since we do review each case and email. And because the issues have varying causes, not everyone's solution is the same, even if it's just a "dim stick of ram".

We've been working on the next software version and should be ready soon.

OK it's a complex issue. How about some technical detail? What exactly is the problem, and what is G.Skill doing to resolve it? How does the upcoming software release differ from previous releases? Are you implementing the required mutex to access the SMB Buss with the proper interlocks? Are you actually getting other companies like ASUS to fix their poorly coded utilities? Some details would be appreciated.

I see stories about multiple RMAs and corrupted SPD data. Now customers are talking about law suits. Time is of the essence to resolve this properly. Using customers as Guinea pigs and refusing to issue refunds to those who have decided to move on is not a strategy that is going to work out well for anyone. I think it would be beneficial for G.Skill to post details of the root cause and the solution being developed as opposed to saying "Its complex". Does anyone else feel this way?

[G.SKILL]

We're not giving up yet guys. The issues are a lot more complex than most people think. At the moment, we're exploring the possible solutions we can think of.

If you do have a problem, please do email our tech support team at techsupport@gskill.com. It may take a few days, since we do review each case and email. And because the issues have varying causes, not everyone's solution is the same, even if it's just a "dim stick of ram".

We've been working on the next software version and should be ready soon.

[Patient0]

Hi,

Does anyone know where we stand legally on this ?

It's now getting past a joke.

Thanks

[kat]

With how very little communication there's been about future updates it kinda sounds like they've given up on actually fixing this in a timely manner and I'm giving up on the RAM. Shame because when it did work it looked really beautiful but at this point I'm down to 1 working stick out of 4 and honestly that's just unacceptable.

[paysen]

Possible fix

I reinstalled Win10 and downloaded the newer 1.00.16beta. After a day, one module became unresponsive and after a restart, it was not lit anymore. The G.Skill software didn't recognize it anymore, so I uninstalled and reinstalled the software. I tried everything. Like switching the modules from 1 and 3 to 2 and 4, swapping them etc.

I was so pissed, I wanted to open a ticket and send them in for warranty repair. But then I tried the last software that worked for me: The TridentZ_RGB_v1.00.08beta.

After uninstalling the newer version and restarting, I installed the TridentZ_RGB_v1.00.08beta, and the module became responsive again and the led's worked again. I am now using the 1.00.08 until they fix it.

[thedeceiver]

I agree. I have one with the rainbow, the 2nd is dead...so I'd be all kinds of happy if I was stuck with a rainbow on both

Haha I'm 3 out of 4 working but yes I'd totally be happy if I had all 4 rainbow again.

[MeiBee]

Wishing I could return these, at this point, feels like false advertising.

Not to mention rainbow is getting so old, looks ugly in my all red build

I agree. I have one with the rainbow, the 2nd is dead...so I'd be all kinds of happy if I was stuck with a rainbow on both

[QuantumsEdge]

Wishing I could return these, at this point, feels like false advertising.

Not to mention rainbow is getting so old, looks ugly in my all red build

[thedeceiver]

I believe the problem is that ASUS AURA, AI Suite, and similar utilities packaged with MOBOs access the SMB Bus without using the proper interlocks to avoid bus access conflicts. ASUS AURA and AI Suite have been causing conflicts with Corsair Link, HWINFO, CPUZ, SIV, and other sensor monitoring utilities for years. These programs all use the proper interlock mutexes but ASUS does not as their program developers seem to assume that they are the only ones accessing the SMB Bus. Considering their target is HEDT Enthusiasts who are using these types of programs while overclocking, it is a pretty stupid thing for them to assume. The fix is easily made but to date, the solution has fallen on deaf ears. Now that LED RAM is all the rage, and G.Skill is using the SMB Buss for LED control data, non-inerlocked SMB Buss access is now causing random SPD data corruption and bricking brand new RAM modules.

G.Skill needs to get ASUS, MSI, and others to get with the program and modify their software to use the proper interlock mutexes like HWINFO, CPUZ,Corsair Link, and SIV do. With all these reports of LED color control data corrupting SPD data, hopefully they will finally fix their poorly coded software. Corsair finally fixed Link but only after years of the developer of SIV waving the problem (and the solution) in their faces. He has also offered to assist ASUS in correcting their programs so that they access the SMB Bus with the proper interlocks. It will be interesting to see how this unfolds. Until they step up and fix it, I personally will not run any ASUS software that accesses sensor information. I was thinking about buying a G.Skill Trident-Z LED kit but decided to wait and see if they would have problems due to SMB Bus contention. Glad I waited but I feel sorry for those that bought the marketing hype and took the plunge early.

So come on G.Skill. You guys are aware of the root problem by now, so why don't you contact the MOBO manufacturers and strongly suggest they clean up their poorly written software. After all, they are not the ones dealing with RMAs on brand new, expensive, bricked RAM sticks.

feelsbadman

[BillB]

I believe the problem is that ASUS AURA, AI Suite, and similar utilities packaged with MOBOs access the SMB Bus without using the proper interlocks to avoid bus access conflicts. ASUS AURA and AI Suite have been causing conflicts with Corsair Link, HWINFO, CPUZ, SIV, and other sensor monitoring utilities for years. These programs all use the proper interlock mutexes but ASUS does not as their program developers seem to assume that they are the only ones accessing the SMB Bus. Considering their target is HEDT Enthusiasts who are using these types of programs while overclocking, it is a pretty stupid thing for them to assume. The fix is easily made but to date, the solution has fallen on deaf ears. Now that LED RAM is all the rage, and G.Skill is using the SMB Buss for LED control data, non-inerlocked SMB Buss access is now causing random SPD data corruption and bricking brand new RAM modules.

G.Skill needs to get ASUS, MSI, and others to get with the program and modify their software to use the proper interlock mutexes like HWINFO, CPUZ,Corsair Link, and SIV do. With all these reports of LED color control data corrupting SPD data, hopefully they will finally fix their poorly coded software. Corsair finally fixed Link but only after years of the developer of SIV waving the problem (and the solution) in their faces. He has also offered to assist ASUS in correcting their programs so that they access the SMB Bus with the proper interlocks. It will be interesting to see how this unfolds. Until they step up and fix it, I personally will not run any ASUS software that accesses sensor information. I was thinking about buying a G.Skill Trident-Z LED kit but decided to wait and see if they would have problems due to SMB Bus contention. Glad I waited but I feel sorry for those that bought the marketing hype and took the plunge early.

So come on G.Skill. You guys are aware of the root problem by now, so why don't you contact the MOBO manufacturers and strongly suggest they clean up their poorly written software. After all, they are not the ones dealing with RMAs on brand new, expensive, bricked RAM sticks.

[alito]

Dear Gskill, do you believe that you can solve this problem? My hope is slowly diminishing. Should I return the Ram modules to you?

[QuantumsEdge]

@ G.SKill Admin

I just sent you the private message and I will post here as well

I apologize for our tech support team. We'll send your feedback in, so they can change how we respond to issues such as yours.

The Trident Z RGB software communicates with the memory modules through the SMBUS. Unfortunately, if another software is also using the SMBUS for communication or for sending commands without the option to pause or hand over the SMBUS, there will be conflicts. We're still working on solutions, which also would require an update on the third party side.

If your memory kit can't be detected by the software, can you PM me your motherboard model, motherboard BIOS version, and the CPU? We'll try to see if there's an issue with your setup.

<b>Motherboard Model</B>
MSI X99A Gaming 7

<b>Motherboard BIOS</b>
H.F0 (Realeased 2016-07-16 [https://us.msi.com/Motherboard/suppo...tml#down-bios])

<b>CPU</b>
i7 5820k

<b>My CPU-Z file</b>
http://www.filehosting.org/file/deta...SONSTRYKER.txt

<B>List of Apps & Programs</b>
http://imgur.com/a/nlUCm

OS Name Microsoft Windows 10 Pro
Version 10.0.15063 Build 15063

Thank you so much for your help.