Monitor Goes Black or Loses Signal While PC Stays On: Cable, Port, GPU Driver, Refresh Rate, Power, and Event Evidence

Start with what remains alive when the screen goes black. Note whether audio continues, keyboard indicators still respond, a second display remains active, remote access still works, or the application continues producing sound. A monitor reporting “no signal” while Windows remains responsive is a different fault branch from a PC that restarts, freezes completely, loses power, or never establishes display during POST.

Also record whether the image returns by itself, returns after changing monitor input, returns after reconnecting the display cable, or only returns after restarting Windows. Do not infer a dead GPU from a black screen alone. The failure can exist anywhere along the display path: monitor/input selection, cable or adapter, GPU output, negotiated display mode, graphics driver, GPU stability, or the wider system.

Write down the exact condition that precedes the signal loss: idle desktop, waking from sleep, launching a game, switching into fullscreen, changing HDR or refresh rate, sustained GPU load, connecting a second display, or moving the cable. A repeatable trigger is much more useful than a general statement that the monitor “randomly” goes black.

Change one thing at a time. If you replace the cable, change the port, update the driver, alter refresh rate, and reset GPU tuning simultaneously, you lose the ability to tell which variable mattered. The goal is controlled isolation, not accumulating fixes until the symptom temporarily disappears.

Microsoft’s external-monitor troubleshooting guidance starts with basic path isolation: make sure the cable is secure, try another cable, test the monitor with another system, and try another video output when one is available. Apply the same logic to an intermittent dropout. If one known-good cable and one GPU port stay stable while another combination repeatedly loses signal, that is evidence about the path; it is not yet proof of which connector or device is electrically defective.

Confirm the monitor is actually set to the input you are testing, especially on displays that auto-switch among HDMI, DisplayPort, or USB-C inputs. Remove unnecessary docks, adapters, KVMs, splitters, or converters during isolation when the setup permits it, then reintroduce them one at a time. Do not hot-plug hardware that its manufacturer says must be powered down, and do not open cables, adapters, monitors, or PSUs to probe internal wiring.

Windows Advanced display shows the current resolution and refresh rate for the selected display, and the refresh-rate choices it exposes depend on what the current display path reports as supported. A monitor marketed for a high refresh rate does not prove that every port, cable, adapter, resolution, color format, or GPU output can sustain every advertised mode.

If the dropout appears only at one high-bandwidth mode, compare with a lower supported refresh rate or resolution as a diagnostic step, then check the exact monitor, GPU, adapter, and cable specifications. Do not turn a successful lower-rate test into a universal bandwidth formula or a declaration that the cable is bad. For DisplayPort, VESA cable certification is a stronger compatibility signal than an unlabeled “8K” or “gaming” cable claim because certification targets defined DisplayPort link-rate requirements. Avoid inventing universal maximum cable lengths.

GPU overclocks, undervolts, raised or reduced power limits, custom memory clocks, third-party display timing overrides, and monitor overclock modes can change stability. If the signal loss began after tuning, establish a documented default baseline before deciding the GPU, monitor, or cable has failed.

Do not prescribe arbitrary voltage, clock, power-limit, custom-resolution, or timing values as a generic repair. If the issue exists only with a monitor-specific overclock or unsupported custom mode, keep the diagnosis tied to that mode. If the entire PC freezes, reboots, or powers off under the same workload, branch to the whole-system load-failure workflow instead of treating it as display-only loss.

Windows Timeout Detection and Recovery (TDR) exists so the operating system can detect a GPU that is taking too long, reset parts of the graphics stack, and restore the desktop when recovery succeeds. Microsoft documents that a visible screen flicker can occur during this reset and that Windows logs diagnostic information after recovery. A brief black screen followed by a restored desktop can therefore be consistent with a graphics-driver/GPU recovery event.

That evidence narrows the branch but does not identify the root cause by itself. Driver defects, unstable GPU tuning, application behavior, GPU hardware, system memory, power delivery, or another graphics-stack problem can all require further evidence. Do not “fix” TDR events by extending registry timeout values; changing the timeout can hide or delay detection without establishing why the GPU stopped responding.

Check the Windows System log around the exact time of the dropout and compare it with the behavior you observed. A display-driver recovery entry near a brief black screen is relevant chronology. A Kernel-Power unexpected-shutdown record belongs to a different branch when the machine actually rebooted or lost power. The absence of a useful event does not prove the cable or monitor failed; some display-link interruptions can occur outside a Windows driver-recovery event.

If the problem began immediately after a display-driver update, Microsoft documents driver rollback as one troubleshooting option for an existing setup that suddenly stopped working. Use the GPU or system manufacturer’s supported driver path and record the exact version before and after the change. Avoid third-party driver-pack utilities or repeated broad driver removal when a controlled version comparison can answer the question more cleanly.

A display-only dropout under GPU load can justify checking the graphics card’s normal user-serviceable power path, especially if the card was recently installed or moved. With the PC shut down and disconnected as required by the hardware manuals, confirm the exact auxiliary connector arrangement required by the graphics card and that only the PSU manufacturer-approved cable set is being used. PCIe add-in cards can use several auxiliary connector families, so the exact card documentation controls the check.

Do not open the PSU, probe mains or connector voltages, repin cables, mix modular cables from different PSU models, or improvise adapters. A stable low-load desktop and a dropout under GPU load can make power delivery one plausible branch, but it does not prove the PSU is defective. If GPU load instead causes a full restart or shutdown, move to the whole-system load-failure workflow.

Use this order: 1) confirm whether only the display signal is lost; 2) record the exact trigger; 3) isolate monitor input, cable, adapter, and GPU output one variable at a time; 4) verify the exact Windows resolution/refresh-rate mode and compare another supported mode when relevant; 5) return user-applied GPU/display tuning to documented defaults; 6) correlate the failure with TDR/display-driver and surrounding Windows events; 7) compare a known supported driver version when the timeline points to a driver change; 8) with the system safely powered down, verify the exact user-serviceable GPU power connections when load correlation makes that relevant; 9) branch to no-POST or whole-system-failure troubleshooting only when the machine itself stops remaining responsive.

Escalate to a known-good monitor, cable, GPU, or professional hardware test only after the observations point to that branch. A component swap is most useful when it changes exactly one variable. Do not replace the GPU merely because Event Viewer mentions the display driver, replace the PSU because a game triggers the dropout, or replace the monitor because one high-refresh configuration loses signal.