Announcement

Collapse
No announcement yet.

Aura / G.Skill software corrupts SPD's?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Aura / G.Skill software corrupts SPD's?

    I had noticed some unusual behavior with four sticks of G.Skill Trident RGB DRAM, and started examining what could cause it. I started with CPU-Z. It showed some strange SPD information on the sticks. Then I tried Thaiphoon burner to read the SPD's and got the same results. Finally I ran HWiNFO64 in debug mode three times and sent the results to Mumak (the author of HWiNFO64).

    After reviewing the logs his response was "Sorry to say, but those modules have a pretty badly messed up SPD.."

    There are a number of other G.Skill Trident RGB owners posting similar issues in the "ROG Crosshair VI overclocking thread" on Overclock.net forum, so I don't think my case is a single aberration.

    Here is a link to the screen shots and debug files:

    https://1drv.ms/f/s!AmnqYpEo4iX0glqVJgJ1zleEXRsZ

    I like the RGB DRAM a lot, but I returned them due to this issue. I am considering whether to order another set, but I am very concerned the same issue would occur.

    BTW this for me is not caused by a conflict between G.Skill software and Aura software. I have never installed the G.Skill application.
    Last edited by Celt; 04-24-2017, 07:35 PM.

  • #2
    Hi! First of all, check out SPD CRC with Thaiphoon Burner. It must be OK.



    or



    If it is corrupted you will see "CRC: Error" what means that some of SPD bytes within the first 256 byte array are corrupted and need to be restored. G.SKILL doesn't mess with programming Serial Number and Manufacturing Date, its SPD is very common. So if you didn't back up the original SPD you can use similar SPD for TridentZ, Ripjaws, FlareX series. Make sure the source SPD has identical number of Ranks and DRAM density as your module.
    Last edited by facehook; 04-26-2017, 10:17 AM.

    Comment


    • #3
      As I stated, the RGB modules were returned. The issue is that at this point people are having expensive memory corrupted by the RGB feature and the software that operates it.

      This is a serious issue caused by using the product as it was intended. I have seen a number of unwitting customers become victims of the SPD problem. I am not knocking G.Skill in general, I even replaced my memory with non-RGB G.Skill.

      What concerns me is I have not heard of G.Skill stepping up to correct the RGB module situation or even acknowledge it. At the least a warning should be issued stating that using Aura or the G.Skill software can cause your RGB memory to be corrupted.

      Comment


      • #4
        We are aware of the issue and of course working on a solution. It is not solely Trident Z RGB software or ASUS Aura software that causes it so there are many other factors involved that we are looking into. Rest assured our goal is always to make sure the product is as good as it can be, and most importantly, the product is working flawlessly in your system. We read every post so we appreciate your feedback and patience as we resolve problems as soon as possible.

        Comment


        • #5
          I believe the problem is that ASUS AURA and AI Suite 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 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 ASUS 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. I am guessing you guys are aware of the root problem by now, so why don't you give ASUS a call and strongly suggest they clean up their poorly written software. After all, ASUS is not the one dealing with RMAs on brand new, expensive, bricked RAM sticks.

          Comment


          • #6
            same problem here , XMP-124 profiles appear on timings table ,
            w/o informations about manufacturer ,Part number , ....
            I really don't know why , i did RMA once , these are new 16 GB kit TridentZ RGB , but same issue .
            I dont want to RMA anytime i got this issue , it makes me sad and i know shop owner doesn't want to see me many times .
            Modules still work , but SPD issue - i dont know why
            Last edited by lucifa312; 05-07-2017, 07:30 AM.

            Comment


            • #7
              this happened to me. one of my sticks of F4-3200C14-8GTZR has lost its xmp profile, which was visible before. i had an asrock x370 taichi, used the g.skill software on that, and at some point i noticed that the xmp information had disappeared from cpu-z and despite reinstalling windows, the g.skill software wouldn't run. now i have a crosshair vi and i can't use the xmp profile in the bios because one of the sticks doesn't have that information (wasn't a problem on the crosshair). i also have to use the asus aura software to control the leds, so there's no guarantee it won't happen again.

              the cl14 replaced cl16 rgb trident z that went bad and failed, produced a bunch of bsods and errors in memtest. and i'm now wondering if the rgb software was also responsible for that.

              this is expensive ram. i don't particularly care for the rgb, but that's all we get here now. and if you have ryzen 7 and want samsung b-die, it's the only ram that guarantees b-die without knowing the version number.

              not overly pleased my nz$360 ram now has corrupted spd and the only way to fix it is either rma (which doesn't mean it won't happen again) or buy another program (with a really restrictive licence) and write new spd information?

              more information on what's gone wrong and how to avoid it happening again would be really useful. because although i've used g.skill exclusively for years, that can change instantly. and seeing as it looks like i'm going to have to rma this ram, it could change pretty much as soon as i find the right version of corsair ram.

              Comment


              • #8
                Have the same issue. Not using ASUS Aura as it is a MSI MB but just the G.Skill software V1.00.16 BETA. Will be good if G.Skill can share what is the root cause so that we will not have the same issue after RMA.

                Comment


                • #9
                  Have had this issue impact all 4 DIMMs on an Asus Crosshair VI Hero. It's gotten so bad that one of the DIMMs won't boot at all on x370 motherboards, but will boot on Intel chipsets still. RMA request went entirely unanswered so *shrug*.

                  Looks like the SPD write protection on the Intel PCH protects the really critical data on Z170 and up boards. I have no confirmation, but it appears that x370 boards don't have that and thus using the software on them can render your system unable to boot entirely.

                  Comment


                  • #10
                    they'll currently run, but on the taichi i had mysterious boot loop errors that resolved themselves (kind of like when you have doa ram). i've had that at least twice on the c6h. and after the xmp information disappeared from one, i started getting replicable errors in cinebench - not instability crashes from overclocking, but cinebench crashing at a specific point and always that specific point.

                    now i'm working with pretty much brand new hardware but for the ram and cpu, and it's crashing in that specific place again with exactly the same exceptions. seeing as the cpu checks out and has up until now managed to deal with everything that's been thrown at it, but the ram has these funky spd errors, i have to pin the blame on the ram. i'm going to run memtest later to see what happens. i ran it when i first got the sticks and it was fine, but seeing as i just had a bsod on cinebench that didn't trigger a board reset, and i know that thaiphoon reports corrupted spd on both, i think i have ram issues.

                    the silence on this from g.skill is disappointing, but considering how expensive this stuff is, i'm not happy with either the fact that software has been released without testing concurrent access to writable areas or how reluctant anyone is to say anything beyond the usual "we're concerned and investigating".

                    Comment


                    • #11
                      I also fell victim to the Aura software. It worked perfect for the lighting control, but corrupted my SPD and also caused random crashes during gaming. Another issue peeked its head, where the DRAM limited itself to 7.93GB Available/16GB. Not good!! I have read success stories from similar users who chose to restore their SPD profiles with Thaiphoon Burner software, but I didn't try to do this before sending in my RMA for replacement. The software does have a built in library, to restore your DRAM proifles, so in the event I run into additional problems, I will likely purchase the software to attempt the repair myself.

                      Sadly I am processing an RMA on the DRAM modules, to have a replacement sent of the same product. I sent the package last Friday and it looks like they will be arriving this Thursday. Pending a quick RMA and expedited shipping, this puts me at middle of next week. This is not a fun process, and I would have much rather "rolled the dice" on some software to restore the DRAM firmware. I feel G.Skill should release a restoration software or patch to perform the same function the Thaiphoon software is performing. It is unfortunate, because this is NOT an isolated few cases. This is actually a widespread problem, and a ton of G.Skill memory is being damaged due to (official release) software for synchronize lighting. Also, I have not downloaded any other lighting control software that would have caused conflict.

                      I did contact ASUS and G.Skill via phone to try and troubleshoot anything before filling the RMA, neither tech support line was helpful to my issues... I could tell the girl at ASUS didn't know anything I was talking about, then transferred me from hardware consultants department to complete computer systems. G.Skill said there was nothing that can be done at the moment, other than sending the DRAM to them to look at. This particular DRAM is the only type of DRAM that has given others success with the Ryzen platform, therefore I do not intend on changing anything. I cannot even attribute this problem directly to ASUS, as others have posted here with similar issues on the different motherboards and even with G.Skill in-house software. Maybe there will be future hardware revisions, but at the moment I can only blame the Aura software. My DRAM functioned perfectly out the box, and I was able to achieve a 3600MHz speed with the 1107 BIOS, recommended voltage, recommended timings. I have searched this forum, overclock.net, and ASUS ROG forum. I am upset being out these two weeks while my RMA is being processed, but I would rather address this issue while I am within my 30-day return period.

                      I am going to attach a photo to show you what happened on my end:

                      Comment


                      • #12
                        How did you notice that the RAM limited itself to 7.93GB?
                        Asus STRIX Z270F
                        i7700k
                        16GB G.Skill Trident Z RGB

                        Comment


                        • #13
                          Originally posted by naujoks View Post
                          How did you notice that the RAM limited itself to 7.93GB?
                          Windows 10 task manager lists memory available and total memory. Usually in a working system there's about 40-50mb unavailable and reserved for system use, but if you have a bad stick then it'll reserve the whole of that DIMM and mark it as unavailable.

                          Comment


                          • #14
                            Originally posted by ckc View Post
                            but if you have a bad stick then it'll reserve the whole of that DIMM and mark it as unavailable.
                            You are not right! When he turns on his computer BIOS can't calculate the module capacity on the base of SPD parameters like Number of Ranks, DRAM Density, Data Width, etc since SPD data are corrupted. That is why BIOS ignores such modules and lowers the total system memory capacity.

                            However, folks from G.SKILL R&D are really crazy with their idea to control LED lightning via SPD Write commands It's a very dangerous idea! The only purpose of SPD EEPROM is to store SPD data! What the hell did they use SPD EEPROM to control LED? Neither solution will solve the SPD corruption issue, because of the concept itself to use SPD Write commands!

                            Comment


                            • #15
                              Originally posted by facehook View Post
                              You are not right! When he turns on his computer BIOS can't calculate the module capacity on the base of SPD parameters like Number of Ranks, DRAM Density, Data Width, etc since SPD data are corrupted. That is why BIOS ignores such modules and lowers the total system memory capacity.

                              However, folks from G.SKILL R&D are really crazy with their idea to control LED lightning via SPD Write commands It's a very dangerous idea! The only purpose of SPD EEPROM is to store SPD data! What the hell did they use SPD EEPROM to control LED? Neither solution will solve the SPD corruption issue, because of the concept itself to use SPD Write commands!
                              i am entirely right. whatever you think i said, read it again before you leap to the wrong conclusion. bad ram for whatever reason - unless it's completely dead - gets listed as hardware reserved memory in the task manager. it can appear in the bios as normal and recognised, but it's unusable.

                              https://puu.sh/uRY7l/2ffb70ca7f.png

                              here's 16gb of memory recognised in the bios as such but hardware reserved in windows:

                              http://i.imgur.com/qIzDH59.jpg
                              http://i.imgur.com/RAuNZvo.png

                              not that i care to have a debate about how you either misread this or you're just wrong. i just forgot to unsubscribe when it became apparent no one at g.skill cares at all about how their software is breaking their ram.

                              Comment

                              Working...
                              X