This is rather long post but has points in it that I think is the cause of your issues, 99% sure.
Ask your friends what they think and if you had a mate that would let you borrow a later PSU ATX3.0 just to see, I know PSU's here are around NZ $200.00 plus, depending on name and specs, etc.
I running a CA RM1000e and had no issues so far.
CP has helped me write this, hence the way it is written, my writing are full of mistakes.🤣
- The crash signature: 0x133 DPC_WATCHDOG_VIOLATION with amdkmdag in ISR
Every dump you have provided — including the three new ones — shows the same pattern:
The GPU miniport driver amdkmdag.sys enters an ISR (Interrupt Service Routine)
The ISR never completes
The DPC watchdog timer expires
Windows triggers BugCheck 0x133 (DPC_WATCHDOG_VIOLATION)
The system hard locks (no BSOD, no logs, no recovery)
This is the exact failure mode when the GPU stops responding electrically during a transient power event.
Not a driver bug.
Not a memory error.
Not a PCIe error.
Not a CPU error.
Not a USB stack hang.
This is the GPU becoming electrically unresponsive for >2 seconds.
- Why the GPU becomes unresponsive: transient load exceeds PSU rail capability
Modern AMD GPUs (RDNA2/RDNA3) have extremely high transient spikes:
A GPU with a 250W TBP can spike to 450–550W for 1–10 milliseconds
These spikes occur during:
Shader compilation
Scene transitions
Rapid frametime changes
VRAM clock state changes
FSR/driver-level frame pacing adjustments
If the PSU cannot supply the instantaneous current demanded on the 12V rail, the rail voltage droops.
When the 12V rail droops below the GPU’s VRM tolerance window:
The GPU’s internal logic halts
The PCIe bus stops responding
The driver ISR stalls
Windows watchdog kills the system
This is exactly what your dumps show.
- Why runtime changes with GPU Power Limit (PL) but not with EXPO/TDP105
This is the part that confuses most users, but the electrical explanation is straightforward.
3.1 GPU Power Limit directly controls transient amplitude
Lower PL → lower average power → lower transient peak → fewer rail collapses.
This is why:
PL -20% → 1h35m
PL -10% → 56m
PL default → crashes in minutes
This is a perfect linear correlation with transient load.
3.2 EXPO and TDP105 do NOT affect the root cause
Turning off EXPO or TDP105:
Reduces CPU + memory power draw
Which increases the headroom for the GPU to boost harder
Which increases transient amplitude
Which reduces stability
This is why he went from 1h35m → 3m30s after “reducing” system power.
It allowed the GPU to hit the PSU harder.
This is classic PSU transient behaviour.
- Why the system hard locks instead of BSODing
When the GPU stops responding electrically:
The PCIe root complex waits
The GPU driver ISR waits
The kernel scheduler waits
The watchdog timer fires
But the GPU cannot reset
The system cannot recover
The machine hard locks
This is the same behaviour seen in:
Undervolted GPUs with too-low Vmin
PSUs with weak transient response
Multi-rail PSUs with OCP tripping
Aging PSUs with degraded capacitors
PSUs below ATX 2.52 spec
The dumps confirm the GPU is the component that stops responding.
- Why this is NOT:
❌ RAM instability
No memory corruption signatures
No 0x1A, 0x50, 0xA, 0x3B, 0x109
No PFN list corruption
No pool corruption
No random BSODs
Only GPU ISR stalls
❌ CPU instability
No WHEA 0x124
No MCEs
No APIC timeouts
No core lockups
❌ PCIe instability
No AER errors
No PCIe bus resets
No WHEA 17 spam
❌ Driver bug
Driver bugs do NOT scale with power limit
Driver bugs do NOT cause 3m30s vs 1h35m runtime differences
Driver bugs do NOT depend on EXPO/TDP105
❌ GPU silicon defect
Silicon defects produce consistent crash times
Not variable runtime based on PL
- The electrical explanation (the real root cause)
6.1 PSU transient response
A PSU must maintain 12V within ±5% under:
0 → 400W load step
1–10ms rise time
Repeated hundreds of times per second
If the PSU cannot:
The 12V rail dips to 11.2–11.4V
GPU VRMs cannot regulate
GPU logic halts
Driver ISR stalls
System hard locks
6.2 ATX 3.0 vs older PSUs
ATX 3.0 requires:
2× GPU transient handling
200% load spikes for 100µs
180% load spikes for 1ms
160% load spikes for 10ms
Most pre‑ATX‑3.0 PSUs cannot do this.
AMD GPUs are notorious for exceeding transient specs.
- The fix path (deep technical version)
Step 1 — Confirm PSU model, age, and rail design- we already know your PSU specs, but I left it in for others to read.
If it is:
Non‑ATX‑3.0
Multi‑rail OCP
<750W
3–4 years old
Bronze/Silver tier
Not a top-tier transient performer
…it is a prime suspect.
Step 2 — Test with PL -10%
If PL -10% gives long runtimes and default PL gives short runtimes, the PSU is confirmed.
Step 3 — Replace PSU with a unit that has strong transient response
Look for:
ATX 3.0 certification
Single-rail design
High-quality bulk capacitors
Low ESR secondary caps
Fast transient response (<1ms recovery)
750–1000W depending on GPU
Step 4 — Optional: GPU undervolt
A proper undervolt curve:
Reduces transient amplitude
Reduces average power
Reduces VRM stress
Increases stability
Often increases performance
But this is a workaround, not a fix.
Your crashes are caused by PSU transient failure: the GPU stops responding electrically during a power spike, the AMD driver ISR stalls, and Windows triggers a 0x133 hard lock. Only GPU power limit affects the crash time because only GPU transients are the root cause.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(156.8, 61%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ED%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(160, 21%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EB%3C/text%3E%3C/svg%3E)
