Image 1 — Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines
Image 2 — Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines
Image 3 — Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines
Image 4 — Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines
Image 5 — Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines
Image 6 — Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines
▲ 122 r/ryzen+1 crossposts

Unique (about to die) 9800X3D sample - physical and highly localized damage to DQ lines

(EDIT 1)

I have just sent GamerNexus an email. When I get reply I will attach it in my edit 2

(END EDIT 1)

Long story short. I was validating my theory that Proc Dq Drive strength and RTT WR reflections are causing some type of damage at the IOD die / contact pads due to continues stress which could potentially prove why some Zen 4 and Zen 5 are dying

To do so I created a custom memory stress test which basically spams write operations from CPU to RAM. The voltages were normal, nothing extreme.

This sample is unique in a sense that the chip itself is still perfectly bootable, which could be of great value to anyone researching the topic of 9800 X3D's dying

-

After 16 hours of stress testing the system shut itself down → red light → cold boot → 4 hours stress test → red light → cold boot → 2 hours stress test → red light

Afterwards I took the CPU out of the socket to inspect the pins. I found highly localized damage at MBB_Data 20 and MBA_Data 12. Where pin MBB DATA 20 is even missing the majority of its substrate

These pins are governing bidirectional read and write operations, which proves my theory behind continuous stress during write operations causing some type of degradation

-

Here is a list of exact pins which shows some type of damage to the substrate of the pads.

Left is position in accordance to the AM5 pin layout found here. Right is the name of the affected pin https://commons.wikimedia.org/wiki/File:Socket\_AM5\_pinmap.svg

(Left bottom part of the chip)

F31 → MBA_Data 12

L31 → VSS

E27 → VSS

(Right bottom part of the chip)

This area is the bronze/dark circle seen of the photo. Pin with dark spot (MBB DATA 20) on it is missing the majority of the substrate)

AW29 → MBB_Data 20

AP29 → Test 47_2

AT29 → VSS

AP31 → Test_CCD0

AW27 → VSS

-

My DM's are open for anyone which has the means and the knowledge to analyze the damage to the substrate and could somehow tie it (or not) to 9800 X3D failures

u/Real_Ad5580 — 4 days ago

Fix/PSA: Setting iGPU to "Forced" in BIOS locks LCLK at 1800MHz, eliminating micro-stutter and heavy input lag on 9800X3D system

**Introduction**

(This is follow up post of my previous post from a week ago)

During testing I found out that disabling IGPU on 9800 X3D while having the GFXOFF on Auto / Disabled inside AMD CBS causes a cascade of consequences which results in System Management Unit (SMU) attempting to dynamically and rapidly power gate LCLK down to minimum 150-400.

Rapid LCLK frequency shifts alter the inter-arrival delta of USB report packets, creating measurable input delivery jitter.

This manifest as "heavy, sticky, generally unreliable input" / "games being perfectly smooth when not moving and becoming stuttery mess the moment you start to move camera" on 9800 X3D (and other ZEN 5 processors with iGPU) Despite every possible benchmark, stresstest, FPS measures etc. being perfectly healthy

\-

**THE CONCEPT (Simplified)**

(LCLK LOCKED - NO DOWNCLOCKING)

High pooling mouse (8000 MHz)→ cIOD PCIe Root Complex → CDC → LCLK → IFOP → ZEN 5 Core → 1 to 1 healthy input

For 8000 MHz mouse the the packets arrive evenly like this:

Packet 1: 125 µs

Packet 2: 125 µs

Packet 3: 125 µs

Packet 4: 125 µs

**(LCLK** **DOWNCLOCKING DUE DISABLED IGPU)**

High pooling mouse (8000 MHz)→ cIOD PCIe Root Complex → CDC → LCLK →

....(Downclocking) LCLK → Dynamic State Event (for example in between frames idle time) → SMU Downclocks LCLK to 150 → Interrupt event (mouse movement) → LCLK wake up event → 1-2 nano second wake up time → INPUT PACKET DELIVERY JITTER →IFOP → ZEN 5 Core

Instead uniform 125 µs →125 µs we get messy uneven input delivery

Packet 1: 132 µs (Sluggish / Delayed)

Packet 2: 118 µs (Overshoot / Clustered)

Packet 3: 135 µs (Sluggish / Delayed)

Packet 4: 115 µs (Overshoot / Clustered)

\-

(**FIX - MUCH CLEANER ALTERNATIVE TO MANUAL MINIMUM LCLK OVERRIDE)**

Setting the IGPU of 9800 X3D inside BIOS from AUTO\\ENABLED → FORCED makes the SMU interprets this as an active state of continuous display pipeline load.

Continuous Display Pipeline locks LCLK to its high-performance frequency (1800 in my case) floor without having to brute force the SoC like during manual LCLK override

When the iGPU is set on AUTO/ENABLED in BIOS while discrete GPU is present, then SMU assumes that you are going to use your dgpu anyway and automatically tries to save power by downclocking LCLK to 150/400 instead being locked at minimum 1800.

Setting the IGPU to FORCED locks the LCLK at stable high 1800

\-

**(SUMMARY)**

  1. IGPU AUTO/ENABLED → FORCED

Forced locks the LCLK at 1800 due the presence of continuous display pipeline during the boot up. This prevents the downclocking of LCLK to 150/400

  1. GFXOFF AUTO → ENABLED

This cuts the power to iGPU without negatively affecting the nearby vSoC and VDD MISC rail which happens when IGPU is set on disabled. under igpu disabled they tend to have higher than normal voltage swing under load ←→ idle. GFXOFF ENABLED results in the same power saving without the downsides of iGPU disabled

  1. UMA BUFFER → 512 MB

When setting iGPU to forced the ram will be permanently locked away from being used by Windows as hardware reserved memory. Setting UMA Buffer to 512 minimalize lost ram to absolute minimum

  1. DISABLE IGPU INSIDE WINDOWS DEVICE MANAGER

This prevents Windows from off scheduling background applications like discord to iGPU which might cause HAGS or MPO issues.

reddit.com
u/Real_Ad5580 — 3 months ago
▲ 50 r/AMDHelp

Fix/PSA: Setting iGPU to "Forced" in BIOS locks LCLK at 1800MHz, eliminating micro-stutter and heavy input lag on 9800X3D system

Introduction

(This is follow up post of my previous post from a week ago)

During testing I found out that disabling IGPU on 9800 X3D while having the GFXOFF on Auto / Disabled inside AMD CBS causes a cascade of consequences which results in System Management Unit (SMU) attempting to dynamically and rapidly power gate LCLK down to minimum 150-400.

Rapid LCLK frequency shifts alter the inter-arrival delta of USB report packets, creating measurable input delivery jitter.

This manifest as "heavy, sticky, generally unreliable input" / "games being perfectly smooth when not moving and becoming stuttery mess the moment you start to move camera" on 9800 X3D (and other ZEN 5 processors with iGPU) Despite every possible benchmark, stresstest, FPS measures etc. being perfectly healthy

-

THE CONCEPT (Simplified)

(LCLK LOCKED - NO DOWNCLOCKING)

High pooling mouse (8000 MHz)→ cIOD PCIe Root Complex → CDC → LCLK → IFOP → ZEN 5 Core → 1 to 1 healthy input

For 8000 MHz mouse the the packets arrive evenly like this:

Packet 1: 125 µs

Packet 2: 125 µs

Packet 3: 125 µs

Packet 4: 125 µs

(LCLK DOWNCLOCKING DUE DISABLED IGPU)

High pooling mouse (8000 MHz)→ cIOD PCIe Root Complex → CDC → LCLK →

....(Downclocking) LCLK → Dynamic State Event (for example in between frames idle time) → SMU Downclocks LCLK to 150 → Interrupt event (mouse movement) → LCLK wake up event → 1-2 nano second wake up time → INPUT PACKET DELIVERY JITTER →IFOP → ZEN 5 Core

Instead uniform 125 µs →125 µs we get messy uneven input delivery

Packet 1: 132 µs (Sluggish / Delayed)

Packet 2: 118 µs (Overshoot / Clustered)

Packet 3: 135 µs (Sluggish / Delayed)

Packet 4: 115 µs (Overshoot / Clustered)

-

(FIX - MUCH CLEANER ALTERNATIVE TO MANUAL MINIMUM LCLK OVERRIDE)

Setting the IGPU of 9800 X3D inside BIOS from AUTO\ENABLED → FORCED makes the SMU interprets this as an active state of continuous display pipeline load.

Continuous Display Pipeline locks LCLK to its high-performance frequency (1800 in my case) floor without having to brute force the SoC like during manual LCLK override

When the iGPU is set on AUTO/ENABLED in BIOS while discrete GPU is present, then SMU assumes that you are going to use your dgpu anyway and automatically tries to save power by downclocking LCLK to 150/400 instead being locked at minimum 1800.

Setting the IGPU to FORCED locks the LCLK at stable high 1800

-

(SUMMARY)

  1. IGPU AUTO/ENABLED → FORCED

Forced locks the LCLK at 1800 due the presence of continuous display pipeline during the boot up. This prevents the downclocking of LCLK to 150/400

  1. GFXOFF AUTO → ENABLED

This cuts the power to iGPU without negatively affecting the nearby vSoC and VDD MISC rail which happens when IGPU is set on disabled. under igpu disabled they tend to have higher than normal voltage swing under load ←→ idle. GFXOFF ENABLED results in the same power saving without the downsides of iGPU disabled

  1. UMA BUFFER → 512 MB

When setting iGPU to forced the ram will be permanently locked away from being used by Windows as hardware reserved memory. Setting UMA Buffer to 512 minimalize lost ram to absolute minimum

  1. DISABLE IGPU INSIDE WINDOWS DEVICE MANAGER

This prevents Windows from off scheduling background applications like discord to iGPU which might cause HAGS or MPO issues.

reddit.com
u/Real_Ad5580 — 3 months ago

Raw Data - not interesting - PCIe 5.0 8x lanes vs PCIe 4.0 16x lanes LINPACK - 9800 X3D, 9070 XT

Just throwing this in the air for that one random guy in the future.

RUN 1 - LINPACK VALUES AT GPU BEING IN PCIE 5.0 X 8 MODE

RUN 2 - LINPACK VALUES AT GPU BEING IN PCIE 4.0 X 16 MODE (One run had 466 anomaly, I accidentally connected and reconnected USB device when cleaning desk)

-

(default dogshit EXPO at 65535 trfci, AGESA 1.3.0.1b (beta bios), shitty asus tuf gaming 650E wifi motherboard motherboard, dual rank Hynix A 32 GB x 2 sticks, 9800X3D (-10 PBO), 9070 XT, previously confirmed rock solid voltages. Before this run the motherboard had it's pins shorted, all the settings were kept on defaults. Nitro 1-2-1 from default 2-3-1 - 120 mm fan blowing directly over sticks no thermal throttle)

u/Real_Ad5580 — 3 months ago
▲ 20 r/AMDHelp

Discovery of RDNA 4 <> W11 bug which results in unexplainable performances issues/a ghost present in a system on some hardware combinations

Below explanation is extremely simplified as I tried to avoid the deep engineering topics which this bug/problem involves. Therefore it will not be 100% accurate representation of the technicalities (many of which I myself do not completely understand) so you have to take it at face value. It also will be little bit chaotic as due time constraints I couldn't clean it up

- Metadata Accumulation Theory_PART 1 -

The Metadata Accumulation is the reason why some RDNA 4 cards users experience unexplainable stutter/uneven frame pacing/heavy mouse feel/FPS reporting healthy values but something feels fundamentally wrong. Only some hardware combinations seems to be affected by it which would explain why some 9070 XT/other RDNA 4 cards users experience unexplainable issues where no driver clean install/windows reinstall/MPO fix etc. seem to be working or they only work temporarily.

There is bug where Windows 11 fails to "flush" old display metadata during minor topology changes. This manifest in Buffer Bloat and State Accumulation—where the system's input and rendering pipelines fall out of sync, and the "debt" of late frames/inputs grows each display topology event

This seems to be especially present on RDNA 4 cards where Windows 11 is behaving like an insecure girlfriend and continuously asks her boyfriend, which is RDNA 4 GPU if it's still there and if it still loves me. The annoyed boyfriend (RDNA 4 GPU) answers, yes I still love you. Soon after insecure girlfriend (Windows 11) tries to ask the same question over and over again.

Each time this question is asked it causes new topology event which accumulates the metadata bloat deep inside the kernel. This creates Display Topology Bloat where a specific interaction between your Display firmware & Windows 11 DWM experience a "handshake leak" over time = accumulation of metadata.

Regardless what causes topology event. In my case it was Pixel Shift + AMD External Events, but is seems some non OLED LG and Samsung panels have the same issue. More about it below.

-

- RE More regardless Metadata Accumulation Theory_PART 2 -

As mentioned before, old threads from 2021 on Guru3D and Blur Busters (later I will edit link of these threads for reference) have isolated a bug where Windows 11 fails to "flush" old display metadata during minor topology changes. I mentioned before that in my case these topology changes were triggered by Pixel Shift & AMD External Events View service

- Why does Pixel Shift triggers topology event?

Most OLEDs don't just move pixels; they report a slightly different Active Area to the driver to ensure the HUD doesn't get cut off. Every time the " Pixel Shift " occurs, the AMD driver receives a " Display Change Event " In current RDNA 4 drivers (specifically talking about 26.x branch), these events seem to not be discarded well. Instead, they accumulate in the NtGdiDdDDIGetDisplayModeList.

-

NtGdiDdDDIGetDisplayModeList a low-level, undocumented Windows operating system API call used by the GPU driver to fetch all the compatible screen resolutions, refresh rates, and color depths your monitor can support. It iterates through every possible display mode combination to populate a list for your graphics card and Windows to choose from. The more topology events are triggered the larger this "Mode List" becomes. this result in the Windows Kernel PnP (Plug and Play) manager becoming "congested" with old display states. The system is "thinking" harder for every frame it presents.

Some game engines periodically polls the display for a frame-sync. When it happens the OS has to scan and go through list of "ghost" display states. This adds microseconds of delay to every frame, which feels like "heaviness" that grows over the course of a session. Those microseconds can cause Presentation Pipeline timing mismatch between the GPU and Display which results in uneven bursts as these microseconds break synchronization somewhere between DXGI > DMW > MPO > FREESYNC > SCALING etc.

This is exact the reason why some systems report high fps while the game smoothness feels like shit and why disabling MPO sometimes helps (it eliminates one of the actors at Presentation Pipelines, reducing the timings mismatch). The rendering pipeline is perfectly fine (hence all tools report stable and smooth fps), but the presentation pipeline is utterly fucked (everything 'feels' wrong/muddy, chasing ghost in a system)

- Why does AMD External Events triggers topology event?

As mentioned previously (I am sorry I cannot be bothered to edit, clean up this post) it seems that disabling AMD External Events seems to stop insecure girlfriend Windows 11 from asking the question if boyfriend GPU still loves me = reduced / complete stop to topology events. Which would explain why disabling this service helps some people.

-

- GHOST IN MACHINE - REASONING - PART 3 -

All of the issues mentioned can break these things. I am not an engineer so I have no technical knowledge to prove my reasoning, so please take all my reasoning mentioned below with grain of salt

1. Pixel Shift caused topology event results in : The Sub-pixel Alignment Paradox

The Mechanism:- Windows and modern game engines often use sub-pixel rendering (like TAA or FSR4) which expects a fixed physical arrangement (with information tied to them like RGB, BGR, or RWGB). While Hardware Independent Flip ensures the GPU bypasses the DWM to send a perfect bit to bit frame to the display, it cannot bypass the physical reality of the panel's sub-pixel structure.The Desync: When Pixel Shift moves the image by 1–2 pixels, the motion vectors generated by the game engine (which doesn't know the monitor shifted) become slightly "incorrect" relative to the physical screen. The Accumulation: FSR 4’s AI model attempts to "correct" these errors. Over a long session, the "error accumulation" in the temporal buffer can lead to ghosting or a "jittery" sensation in framepacing, as the the AI cores however they are called on RDNA cards have to work harder and harder

-

The Problem - Pixel Shift moves the entire image by 1–2 pixels every few minutes. The display controller shifts the scan-out address, but the sub-pixels themselves are physically stationary.

-

The Influence- If the game renders a "Red" edge for a specific pixel, but that pixel is physically shifted to a position where a "Green" sub-pixel is dominant, the display controller must either:

A. Direct Shift: Move the image anyway, causing a 1-pixel color fringe or "softness" as the sub-pixel rendering now misaligns with the physical sub-pixels. On some game engines it can also cause unreliable, heavy mouse feel as the Hardware Cursor and the Rendered in game cursors are misaligned = gradual input degradation each time pixel shift occurs

B. Re-sampling: Attempt to re-calculate the sub-pixels in the display's internal scaler. This adds delay which cannot be detected by tools like PresentMon is it

-

The Feel -This results in a gradual loss of perceived sharpness. The brain detects that edges are no longer "clean," which is interpreted by our brain as noise or " input lag " even if the frame-times are flat

2. The "VBI" Reset & VRR DesyncVariable Refresh Rate (FreeSync/G-Sync) relies on the Vertical Blanking Interval (VBI)—the "wait time" between frames.

-

The Mechanism: Pixel Shift events are handled by the monitor's firmware. On many OLED controllers, shifting the image requires a reset of the internal timing controller (T-CON) during a blanking interval.

-

The Influence: In a VRR environment, the VBI is already fluctuating to match your rdna 4 GPU. If a Pixel Shift event occurs exactly as a new frame is arriving, the display controller may have to "hold" the current frame for an extra millisecond to ensure the new scan-out address is locked.

-

The "Feel": This creates a Micro-Jitter that does not show up on software-based frame-time graphs (like PresentMon) because the GPU sent the frame on time, but the display held it for a fraction of a millisecond. This is a "Hardware Hitch" which will never show up on on monitoring software.

3. Broken MPO/DMW due EDID <> GPU <> Windows 11 interactions

Most 1440p OLED's don't actually have 2560 x 1440 physical grid. To allow for Pixel Shift without cutting off the image, the panel often has a physical resolution closer to for example (on my display) the physical grid is 2720 x 1619 while native resolution is 2560 x 1440.

This can create MPO/DMW Heuristics conflict. For Hardware Independent Flip to engage and for MPO to work properly, the game’s "Active area/Bounding Box idk how to call it" must be perfectly match the OS’s "Addressable Plane".

In case the specific conditions mentioned below are fullfilled there is mismatch between Actieve area/Bounding Box vs Addressable Plane. This mismatch forces the DMW/GPU/DISPLAY to apply undesired scaling

The Quirk: If your monitor’s EDID (the identity data displays sends to your 9070 XT) includes TV/Overscan timings to account for those extra "out of bound" pixels...

(which was the case on my monitor as it reported 3840 x 2160 as one of available resolutions despite being natively 2560 x 1440)

...Windows may mistakenly categorize your display as a "TV" rather than a "PC Monitor.". ESPECIALLLY SINCE Registry entry TVEnableOverscan (found in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{Your GPU id number thingy dingy}\0000) is set to 1 (enabled) as default in Registry of AMD drivers (No clue if only 26.x.x brnach or also 25.x.x branch)

-

Often the TV resolutions and PC resolutions have different timings. It creates an issue where your game migth be pulling from PC timings while Windows is pulling from TV timings. This mismatch cause cascade of issues all resulting in the "something feels weird" Some monitors are reporting the TV resolutions as first available resolution, while others do not have them at all or report PC resolution as the first one available. Because the hardware signal is locked to a TV grid, your GPU/DMW is forced to operate in scaling loop. When you run a game at 2560 x 1440 (and one of your non native available TV resolutions is 3840 x 2160).

1. the engine draws frames at 2560 x 1440 >

2. The graphics driver (or DMW no clue which one exactly) captures that frame, stretches it to a virtual 4K canvas (to make Actieve Area and Addresable Area to match) >

3. and then the monitor’s internal scaler compresses it back down to fit the physical 1440p panel. It adds invisible and undecetable scaling costs. Additionally, it is impossible to scale 2560 x 1440 and 3840 x 2160 due the uneven amount of pixels (it is possible to do it from 1920 x 1080 though). This creates "fisheye" geometry distortion/blurry in game UI as the scaled picture doesn't match 1 to 1 with what GPU initially rendered (before scaling)

-

In combination with the things mentioned above I suspect this is exactly the exact reason why some people exepreince performance degradation/uneven feel while others are compleltly unaffected.

-

- POSSIBLE FIX? - PART 4 _ END -

-

On my machine with 9800 X3D, 9070 XT, Windows 11 23H2 Eneterpise (I suspect it works on 24/25H2+ too), Asus Tuf Gaming 650E Plus Wifi 3854 bios, Gigabyte Oled MO27Q2 (1440 p, one of available TV resolutions is 3840 x 2160) applying these steps complelty eliminated the ghost which I was chasing across mutiple Windows reinstalls. All "Heavy mouse feel"/"Some sessions felt fine, others not at all", "Muddy feeling despite excelent 0,1% lows and 1% lows" dissapered after rebooting from the last step. Since then my systems feels perfectly reliable, snappy and consistent across mutiple games.

(Some of the steps I mentioned below migth be straigth up redundant or unnecessery, so please feel welcome to point them out. Due the fatigue I will only provide the barebone fixes without explaining why with the intention to edit this post)

PART 1 - Preventing Windows from building up bloat inside NtGdiDdDDIGetDisplayModeList

Step 1: Stop Network Metadata StagingNavigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device MetadataSet PreventDeviceMetadataFromNetwork (DWORD) to 1.

Step 2: Disable Device Setup ManagerOpen services.msc, locate Device Setup Manager, click Stop. Set its Startup type to Disabled

Step 3: Enforce Kernel-Level Service Lockout > Navigate to > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DsmSvcSet Start (DWORD) to 4 (Hexadecimal). Note: If access is blocked on modern builds, temporarily change the key's Owner from TrustedInstaller to the local Administrators group, grant Full Control, apply the change, and then revert the owner

Step 4: Block GameBar Presence Telemetry HooksNavigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsRuntime\ActivatableClassId\Windows.Gaming.GameBar.PresenceServer.Internal.PresenceWriterFix permissions if access is denied > Right-click PresenceWriter > Permissions > Advanced > Change Owner to your current Administrator account > Check "Replace owner on subcontainers and objects and grant Full Control > Close and reopen the registry permissions window to refresh the token >Set ActivationType (DWORD) to 0

Step 5: Mitigate Shell UI Wait-States.

Open services.msc > locate App Readiness (AppReadiness) >click Stop, and set its Startup set to Disabled > Afterwards Right-click the Taskbar > Taskbar Settings > Under Taskbar Items, toggle Widgets to OFF

Step 6: Decouple Radeon Driver Topology PollingOpen services.msc.Locate the following two services, click Stop, and set both to Disabled:AMD External Events UtilityAMD Crash Defender Service REBOOT THE SYSTEM NOW before moving to step 7,8 & 9.(Yes your Freesync will not get broken as VRR is hardware controlled, not software controlled)

PART 2: EDID Purge & Display Cache Re-Initialization

Step 7: Cleanse EDID Profiles via CRU (Custom Resolution Utility, free. No, it doesn't edit the physical EDID on your display)

Launch Custom Resolution Utility. Start > (CRU.exe) as Administrator > Export your current profile, it is your default state > Select your active display from the top dropdown menu > On the main window, wipe legacy timing fallbacks > Under Standard resolutions, click Delete all > Under Established resolutions, click Delete all > In the Extension Blocks section at the bottom, select the CTA-861 block > Edit > Inside the Data Blocks list, highlight and Delete the following items > TV resolutions and CRT detailed resolutions > CRITICAL: Leave the DisplayID block completely untouched to preserve native high-refresh containers > Click OK reboot twice > if done correctly the second time you launch CRU.exe no TV timings, established resolutions etc. should appear. In case of 1440 display your Windows wouldn't have 3840 x 2160 anymore as available resolution (later I will try to edit it into more in depth guide)

Step 8: Registry Editor > CNTR + F > TVEnableOverscan > it will bring you to folder Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{long number, unigue to your GPU id thingy dingy}\0000 > Set TVEnableOverscan to 0 (disabled) from 1 (enabled) (each driver update you might need to redo it)

Step 9: Clear Graphics Drivers Configuration Cache

After step 7 is done correctly (verify!!!) > boot into Safe Mode without networking > open regedit and export default values (it's your backup) navigate to > Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers > you will find 3 sub-folders called > 1. Configuration 2. Connectivity 3. ScaleFactors > delete every SUBfolder found under these 3 folders.> do not reboot yet, see step 10

Step 10: Execute Physical Port Re-Enumeration. After you have done step 9 > reboot into normal mode > Immediately after the PC screens power off to reboot, disconnect the display cable (HDMI/DisplayPort) from the graphics card > Allow the machine to finish booting back into standard Windows completely unattached to the monitor (wait 1–2 minutes for all start-up processes to clear) > Connect the display cable into a different physical port on the graph

reddit.com
u/Real_Ad5580 — 5 months ago