# No signal, black screen or lines: diagnosing a display fault

> Separate cable, port, panel, GPU and driver faults in the right order — and know which symptoms mean the monitor is dying rather than misconfigured.

**Tested on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

A display fault is one of five things. Diagnosis is cheap **if you test in this order**, because each step eliminates a layer:

| Layer | Test | If it fails |
|---|---|---|
| 1. **Input source** | monitor OSD → correct HDMI/DP/USB-C? | wrong input, not a fault |
| 2. **Cable** | swap the cable, same ports | cable |
| 3. **Port** | different GPU port, different monitor port | port or GPU |
| 4. **Panel** | monitor's own OSD menu visible? | panel/backlight |
| 5. **GPU/driver** | works in Safe Mode or another OS? | driver or GPU |

The single most useful question: **does the monitor's own menu appear?** If the OSD renders, the panel and backlight work and the fault is upstream (signal). If the OSD does not appear, the monitor is the problem.

## "No signal" — the common causes

| Symptom | Likely cause |
|---|---|
| No signal, monitor light amber/blinking | no valid signal: input, cable, or GPU not outputting |
| Signal appears only after replugging | marginal cable or port |
| Works at 60 Hz, fails at 144 Hz | cable/port bandwidth (see below) |
| Works until the GPU driver loads | driver or resolution/refresh mode |
| Works on one GPU port only | port or cable |

```powershell
# what the OS thinks is connected
Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorID |
  Select-Object InstanceName, @{n='Name';e={[char[]]$_.UserFriendlyName -join ''}}
Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,CurrentHorizontalResolution,CurrentVerticalResolution,CurrentRefreshRate
```

If `WmiMonitorID` is empty but a display works, Windows is seeing an EDID-less path (adapters, KVMs).

## Bandwidth is the hidden cause of "flicker at high refresh"

A cable that carries 1080p60 fine can fail at 1440p165 or 4K120. The limit is total data rate, not the connector shape.

| Link | Practical ceiling |
|---|---|
| HDMI 2.0 | 4K60 8-bit, no HDR headroom |
| HDMI 2.1 | 4K120+ with DSC |
| DisplayPort 1.2 | 4K60 |
| DisplayPort 1.4 | 4K120 with DSC, 1440p240 |
| USB-C DP alt-mode | depends on lane count — often 2 lanes |

Symptoms of overrun: flicker, black flashes, the monitor dropping to 60 Hz, or "no signal" that resolves when you lower the refresh rate. **Test by dropping to 60 Hz** — if the fault disappears, it is bandwidth, not a dying panel.

## Lines and artefacts

| Pattern | Meaning |
|---|---|
| **Vertical/horizontal lines that move with the OSD** | panel defect |
| **Lines fixed in position, visible on OSD too** | panel defect |
| **Lines only in Windows, gone in BIOS** | driver or GPU memory |
| **Lines only at one resolution/refresh** | bandwidth or scaler |
| **Coloured speckle/"snow"** | cable, or GPU memory failing |
| **Burn-in ghosting** | OLED/IPS retention, not a fault |

The BIOS test is decisive: if the firmware screen is clean but Windows is striped, the hardware carries a signal fine and the problem is in the OS path — driver, colour depth, or GPU memory under load.

> **Caution: Do not 「fix」 a failing GPU with a driver reinstall**
>
> If artefacts appear under load and vanish at idle, or the machine crashes with a display timeout, a clean driver install may only postpone it. Check for WHEA events and GPU temperature first — see [WHEA and bugchecks](https://windows.homes/en/hardware/diag/whea-bugcheck/).

## Safe Mode and the "works there" tell

Boot into Safe Mode (or a Linux live USB):

- **Clean in Safe Mode, broken normally** → driver or a background app (colour profile, HDR toggle, OEM utility).
- **Broken in Safe Mode too** → hardware: cable, port, GPU, panel.

```powershell
# last display-related driver events
Get-WinEvent -LogName System -MaxEvents 300 |
  Where-Object { $_.ProviderName -match 'Display|nvlddmkm|amdkmdag|igfx' } |
  Select-Object TimeCreated,Id,ProviderName,LevelDisplayName | Format-Table -AutoSize
```

`Display` event **4101** ("display driver stopped responding and recovered") points at the driver/GPU, not the monitor.

## HDR and colour artefacts

A washed-out or oversaturated image is not a fault — it is a colour pipeline issue, covered in [colour management](https://windows.homes/en/windows/media/colour-management/) and [the HDR chain](https://windows.homes/en/hardware/display/hdr-chain/). Flicker that appears **only in HDR** is usually bandwidth (HDR needs more).

## When it is the monitor

Reasons to RMA rather than keep debugging:

- OSD itself is striped or half-black.
- Backlight bleed that appears as flicker at low brightness.
- Lines persist across inputs and cables.
- The monitor drops signal when it warms up (thermal fault).

Test it on a second source (laptop, console) before opening a ticket — that is the evidence support will ask for.

## Related

- [Choosing a monitor](https://windows.homes/en/hardware/display/monitor-choice/)
- [Windows HDR: the whole chain](https://windows.homes/en/hardware/display/hdr-chain/)
- [Colour management and ICC](https://windows.homes/en/windows/media/colour-management/)

## Lab boundary

E1. Display pipeline behaviour is Microsoft-documented. The lab has no physical monitor or GPU output, so no cable/panel fault was reproduced here.

## Sources

- [Microsoft Learn — Display drivers](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/)
- [Microsoft Learn — High DPI and display](https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows)
- [Microsoft Learn — DXGI](https://learn.microsoft.com/en-us/windows/win32/api/dxgi/)

---

Source: https://windows.homes/en/hardware/display/display-faults/