Windows 11 24H2 now being pushed onto my system

Diving back into the blow ups and my hypothesis, analyzed by the AI:

I suspect this build in gpu may have something to do with the burning/blowing of the Ryzen 7950 X3D as well as the newer models, here is why I believe that:


1. It is powered by the same "rail": VDDCR_SOC

2. The processor seemed to die when the screen saver kicked in on windows.

3. The adrenaline drivers were buggy.


What do you think of this hypothesis ?

Your hypothesis regarding the integrated GPU's potential role in the Ryzen 7000X3D burning issues is very interesting and touches on some of the underlying complexities of the SoC design and the actual failure mode. Let's break down your points:

1. "It is powered by the same 'rail': VDDCR_SOC"

    You are absolutely correct here. The iGPU (integrated graphics processing unit) on Ryzen 7000 series CPUs (including the X3D models) draws its power from the VDDCR_SOC voltage rail.

    This is crucial because the core problem identified by AMD and motherboard manufacturers was indeed excessive VDDCR_SOC voltage. When this voltage went too high, it degraded or destroyed components on the SoC, which includes the iGPU, memory controller, and Infinity Fabric.

    Therefore, if the iGPU demanded more power, or if a bug caused it to draw current in an uncontrolled way while its voltage rail (VDDCR_SOC) was already set too high by the BIOS, it could certainly contribute to the problem.

2. "The processor seemed to die when the screen saver kicked in on windows."

    This is a very specific observation and could be highly significant.

    Screensavers and display states can trigger unusual power transitions: When a screensaver activates, or when the display enters a sleep state, the system often undergoes a power state transition. This involves changes in CPU core clocks, iGPU clocks, voltage adjustments, and C-states.

    Potential for Voltage Spikes: These transitions, especially if poorly handled by the BIOS or drivers, can sometimes trigger transient voltage spikes. If the underlying issue with the excessive VDDCR_SOC auto-voltage was present, a transition that suddenly demands power from the iGPU (e.g., to render a complex screensaver or wake up from a low power state) could have been the "straw that broke the camel's back," causing a voltage overshoot on the already-too-high SoC rail.

    Reports of DWM/iGPU activity in sleep/screensaver: There are indeed reports (as found in search results) of Windows' Desktop Window Manager (DWM) or other processes causing CPU/GPU activity spikes when the display goes to sleep or screensavers are active. If your iGPU was suddenly tasked with rendering something while in a vulnerable voltage state, it could fit this scenario.

3. "The adrenaline drivers were buggy."

    AMD Adrenalin drivers are responsible for the iGPU: The Adrenalin Software (drivers) from AMD are what control and optimize the integrated graphics.

    Driver Bugs and Power States: Buggy graphics drivers can sometimes mismanage power states, clock speeds, and voltage requests, especially during idle periods, power transitions, or when dealing with specific workloads.

    Possible Scenario: If an Adrenalin driver bug caused the iGPU to draw excessive power, request an invalid clock state, or mishandle a power transition (like entering a screensaver or sleep mode) while the VDDCR_SOC rail was already running at an elevated and unsafe auto-voltage, it could have potentially contributed to a component stress that led to failure.

What do I think of this hypothesis?

I think your hypothesis is very plausible and aligns well with the known root cause of the Ryzen 7000X3D issues.

Here's why:

    Converging Factors: The problem wasn't solely one thing. It was a confluence of factors:

        Motherboard BIOS (the primary culprit): Setting VDDCR_SOC automatically to dangerously high levels (1.35V+).

        Ryzen 7000X3D's Sensitivity: These chips were more sensitive to high SoC voltage due to the stacked V-Cache impacting thermal dissipation in that region.

        Potential Triggers (where your hypothesis fits): The "event" that pushed it over the edge. These triggers could be:

            Enabling EXPO (which often triggered the high auto SoC voltage).

            Running certain workloads.

            Specific power state transitions, like a screensaver activating, which could involve the iGPU and potentially a buggy driver.

    The iGPU is Part of the SoC: Because the iGPU is part of the SoC, any stress on the iGPU, especially if mismanaged by drivers or power states, would directly impact the VDDCR_SOC rail. If that rail was already operating at an unhealthy voltage, the added stress could lead to failure.

While AMD's official statement and the subsequent BIOS fixes primarily focused on capping the VDDCR_SOC voltage, the exact "trigger" that caused the final destructive event for individual CPUs could vary. Your observation about the screensaver and buggy drivers points to a very specific and compelling trigger that could have exacerbated an already precarious voltage situation. It perfectly explains how an apparently "idle" scenario could lead to a catastrophic event if the underlying voltage management was flawed.

Therefore, your hypothesis is a well-reasoned explanation for how the iGPU and its drivers could have been an interacting factor in the unfortunate failures of some Ryzen 7000X3D CPUs.

I do notice something odd about HWInfo64 though:

It only display GPU Fan 1 and GPU Fan 2 while in reality my Graphics Cards has 3 fans ! HAHA ! Yes ! I check in GPU Tweak 3 which I/my PC uses to control graphics cards fan curvitures. It also only shows: Fan Speed (Sides) and Fan Speed (Center).

So apperently some kind of limitation in the design of all of this... hmm...

^ This happened while trying out the "sensors" part of HWInfo64....

PCI Lock warning, abort, retry, cancel, etc...

I tried retry a few times, it kept showing up. It did rapport which app was responsible for the like: iCue...

So then eventually I shutdown iCue, exited it for system tray, restart HWInfo64 and then no more complaints.

So at least this allows me to inspect temperatures, voltages, settings, etc.

Afterwards I shut down HWInfo64, restart iCue and everything should be fine again.

Though I do now wonder if maybe iCue could have an affect on system performance, not sure yet...

One more future note so I can let it flow out of my brain lol:

I let gemini flash 2.5 analyze the memory situation/settings of my system.

The end conclusion of gemini flash 2.5 is more or less the following:

The memory chips are capable of running at 6000 MT/sec. The system can do it as well. However getting it stable might be difficult.

In case I or others with a similar system want to try it in the future:

The AI recommends:

1. Install the latest BIOS to increase the chance of stability.

2. Ofcourse at least version 1.28 for this particular system should be installed to prevent any Voltage Soc going to the processor from going higher than 1.25 volts or 1.305 volts. (On youtube I saw somebody set it to 1.2 volts to begin with).

3. Enable AMD Expo.

The expected performance gains are: 20% lower latency and 66% more theoretical bandwidth.

In certain use cases this might be noticeable, like perhaps virtual machines, maybe loading AI models.

However during benchmarking by others long ago, they only showed 1% or 2% performance improvements probably because of 3D V Cache or they didn't test it right ;)

The risk of damage is low according to the AI because it was all designed for this.

However system instability is still a risk.

For me system stability is very important so I am perfectly fine with running memory at 3600 MT/sec which is still a very fast system compared to what I used to be running and also compared to real world usage that I am getting which is lightning fast for a human, so I have little desire to experiment with this at the time being.

However it does make me a little bit curious.

Another however, if this system were to be damaged a replacement would not be easy since newer models seem to be blowing up and it would be a lot of work to take the system apart or build a new one.

So benefits do not outway the risks.

But it is interesting to note this down for the future in case I do buy a better/new or backup computer and I want to experiment with this system to see what it could really do.

Finally I will throw in some numbers computed by the AI:

Revisiting the Timings (30-30-30-58):

Knowing it's DDR5 running at 3600 MT/s (1796.8 MHz clock), let's calculate the real-world latency in nanoseconds (ns):

With current timings at 3600 MT/sec:

    tCAS-tRCD-tRP-tRAS: 30-30-30-58

    Clock Period: 1 / 1796.8 MHz = 0.5566 nanoseconds per clock cycle.

    tCAS Latency: 30 cycles * 0.5566 ns/cycle = 16.698 ns

    tRCD Latency: 30 cycles * 0.5566 ns/cycle = 16.698 ns

    tRP Latency: 30 cycles * 0.5566 ns/cycle = 16.698 ns

    tRAS Latency: 58 cycles * 0.5566 ns/cycle = 32.28 ns


    Supported Module Timing at 3000.0 MHz (EXPO Profile 0): 40-40-40-77

        This is the key EXPO profile your RAM is designed for. At a true clock speed of 3000 MHz (which is 6000 MT/s), the timings are 40-40-40-77.

        CAS Latency in ns (EXPO): 40 cycles * (1 / 3000 MHz) = 13.33 ns


Comparison of Real-World Latency:

    Current (DDR5-3600 CL30): ~16.7 ns

    EXPO (DDR5-6000 CL40): ~13.3 ns

This confirms that by enabling EXPO, you'd be reducing your primary CAS latency by approximately 20% (16.7 ns to 13.3 ns), in addition to the massive
increase in bandwidth (3600 MT/s to 6000 MT/s).


In summary, by enabling EXPO, you are looking at:

    A substantial increase in memory bandwidth (66% theoretical).

    A noticeable reduction in absolute CAS latency (around 20%).

    Tangible performance gains in CPU-intensive games and applications, especially smoother gameplay due to better 1% lows.

More:

1. Absolute Latency (in nanoseconds):

    Current (3600 MT/s @ 1796.8 MHz clock, 30-30-30):

        CAS Latency: 30 cycles * (1 / 1796.8 MHz) = 16.7 ns

    With EXPO (6000 MT/s @ 3000 MHz clock, likely CL40):

        CAS Latency: 40 cycles * (1 / 3000 MHz) = 13.3 ns

    You're looking at a ~20% reduction in CAS latency in absolute terms. This means the time it takes for the CPU to receive data from the RAM is
    significantly reduced.

2. Bandwidth (Theoretical):

    Current (DDR5-3600, Dual Channel):

        3600 MT/s * 8 bytes/transfer (64-bit bus) = 28.8 GB/s

    With EXPO (DDR5-6000, Dual Channel):

        6000 MT/s * 8 bytes/transfer = 48 GB/s

    This is a massive 66% increase in theoretical memory bandwidth! This means your system can move data to and from the RAM much faster.



Concerning voltage settings:

    1.35V for DRAM (VDD/VDDQ) is completely normal and safe for DDR5-6000.

    The 1.25V / 1.3V limit you're thinking of applies to the CPU SoC Voltage.

        During the initial Ryzen 7000 launch, some motherboard BIOS versions (before patches) were automatically pushing the CPU SoC voltage too high when
     EXPO was enabled, sometimes going over 1.4V. This excessive SoC voltage was indeed found to potentially cause damage to the CPU's memory controller
     (leading to "burn outs").

        AMD quickly addressed this with AGESA updates, and motherboard manufacturers followed suit with new BIOS versions. These updates now cap the CPU
     SoC voltage at a maximum of 1.3V (with 1.25V often being the recommended "sweet spot" for stability and longevity).

        When you enable EXPO, the motherboard should now automatically apply a safe SoC voltage that adheres to these new limits, typically 1.25V or
     slightly higher, but staying below 1.3V.

Key Confirmations and Insights:

    Corsair CMT64GX5M2B6000Z40: This confirms the exact part number for your RAM kit, which is indeed a 64GB (2x32GB) DDR5-6000 CL40 kit. The "Z40" at the
    end of the part number specifically indicates the CL40 latency.

    SK Hynix A-Die: This is excellent news! SK Hynix A-Die is currently one of the best DRAM ICs (chips) for DDR5 overclocking and stability, known for its
    ability to reach high frequencies and relatively tight timings.

    Module Size: 32 GBytes, Number of Ranks: 2 (Dual Rank): You have two 32GB dual-rank modules. This confirms your 128GB total memory is achieved with two
    modules, which is generally easier to stabilize at higher speeds than four modules, although 32GB dual-rank modules still put more strain on the memory
    controller than 16GB single-rank modules.

    Memory Speed: 3000.0 MHz (DDR5-6000 / PC5-48000): This is the rated effective data rate for the modules via their EXPO profile.

For now I am going to take what the AI wrote with a grain of salt, I do believe it somewhat, but confirmations by others would be nice to make sure the AI is not hallucinating :)

(There was more text, but I copy & paste the most essential parts of it ! ;))

Laterz !
Bye,
    Skybuck ! ;) =D

HWInfo64 removed and new version v8.28-5770 installed and working.
(This tool seems to manipulate/interact with the SMBus / I2C, so care must be taken not to accidently click on some things or whatever).

It can generate a full report of system... but I see no way of including such a long report in this forum...

So everything is working again.

To be more specific about lightning settings for iCue/DRAM:
Lighting Link1/Quick Lighting Zone: Dimm #1 set to: AMD Ryzen 9 7950X3D Package
Lighting Link2/Quick Lighting Zone: Dimm #2 set to: ASRock B650E Steel Legend WiFi Temp #1
Lighting Link3/Quick Lighting Zone: Dimm #3 set to: ASRock B650E Steel Legend WiFi Temp #4
Lighting Link3/Quick Lighting Zone: Dimm #3 set to: Dominator Platinum RGB DDR5 Temp #4.


(At lighting link #3 at had Temp #3 from mobo but decided to switch to temp #4 because it's slightly hotter, not yet sure which parts of the mono are being heat measured here, so that's where I am a little bit unstatisfied, but perhaps in time with HWInfo64 I can figure it out further, but this is something where mobo makers/sensors/hwinfo64 could do some more work to improve upon this in the future).

All temperature colors set to:
Green 20 degree celcius
Yellow 40 degree celcius
Red 60 degree celcius
(It shades them in between).

Current ambient/room temperature is 24.0 degree celcius
Dimm 1. yellow/orangish
Dimm 2. light greenish
Dimm 3. yellow/orangish
Dimm 4. yellowish green.

Power supply temperature 25 celcius. Power supply fan RPM set to approx 1000 RPM.

Very silent system at the moment, I do have outside balkany door open though for fresh air and I kinda like it, might close it soon though.

Inside asus armory crate:
(Dominator set not present anymore, I guess I delinked it in iCue or something, which is good I don't want armory crate controlling it because it doesn't have access to all sensors...)

Asus auro sync->Auro Effects->Smart<-Click it it shows:
By GPU Temperature (select it ;))
Low Point: 60 degree celcius, High point 85 degree celcius.

So far the GPU has been greenish the entire summer hehe.

This is cool/nice setup, can quickly see temperatures in a glance, assuming it works and it does seem to work ;)

It's an amazing system, it continues to amaze me every day ! ;) XD =D

Later, bye for now,
Skybuck