Surface Pro 7 – Black Screen and Display Glitch During Windows Boot

Code 0 Reputation points
2026-10-01T16:51:13.6666667+00:00

Hello,

I am experiencing a serious display issue with my Microsoft Surface Pro 7, mainly during Windows startup.

The problem occurs as follows:

  • The UEFI screen works completely normally and is stable.
  • After performing a Restart, the screen may remain completely black.
  • The same problem can occur after a full Shutdown → Power On.
  • Sometimes the screen does not stay completely black but instead shows glitches, flickering, or distorted graphics.
  • Windows appears to boot successfully — I can hear the Windows startup sound and the system seems to be running — but the built-in Surface display does not show an image.
  • When this happens, I usually have to hold the power button to completely force the device off and then turn it back on. The display will often work again after this cold boot.
  • A similar issue can also occur after Sleep/Modern Standby.
  • I also tested Hibernate, and the display failed to come back after hibernation as well.
  • In one problematic Windows session, the desktop appeared to be running at approximately 1024×768, while the active signal was reported as approximately 1736×1824.
  • Intel graphics driver currently detected: 31.0.101.2130.
  • I have installed/checked the available Windows and Surface firmware updates.
  • I have also run the Surface Diagnostic Toolkit.
  • powercfg /a shows that the device uses S0 Low Power Idle / Modern Standby.

The most important point is:

UEFI works normally, but the problem occurs when Windows takes over the display, especially after Restart or Shutdown → Power On.

Because of this, I suspect there may be an issue somewhere in the following chain:

Windows Boot → Intel GPU → WDDM/DXGKRNL → Display Driver → eDP/Surface Display Panel Initialization → Surface Firmware/ACPI

I would particularly like to determine why the built-in Surface display sometimes fails to initialize correctly when Windows starts or when the system restarts, and why the display can sometimes come back with an abnormal resolution.

If anyone has experience with Surface Pro 7, Intel graphics drivers, WDDM/DXGKRNL, eDP panel initialization, or Surface firmware, I would greatly appreciate your help.

The main question I am trying to answer is:

Why does a Surface Pro 7 with a perfectly functional UEFI display sometimes fail to initialize its internal display after Windows Restart or Shutdown → Power On, while a complete forced power-off and cold boot often restores the display?

Surface | Surface Pro | Display and screen
0 comments No comments

2 answers

Sort by: Newest
  1. S.Sengupta 32,666 Reputation points MVP Volunteer Moderator
    2026-10-02T02:12:31.8+00:00

    Why UEFI works and Windows doesn't:

    UEFI only needs a simple, fixed-mode framebuffer. When Windows takes over, the Intel driver has to reprogram the display engine, retrain the eDP link to the panel, and re-enable power features such as PSR, backlight PWM and the display low-power firmware. Any step that fails leaves you with a black screen, corruption, or a fallback to 1024×768 on the Basic Display Adapter, while the rest of the system boots fine. That is why you hear the startup sound.

    Why a cold boot can fix it:

    A normal Restart or Shutdown → Power On does not necessarily produce exactly the same hardware state as removing power completely.

    A forced shutdown followed by a cold start can reset:

    Intel GPU/display-engine state

    eDP link state

    panel power state

    graphics-driver state

    ACPI display power state

    Modern Standby-related state

    The next boot therefore gets a cleaner graphics initialization, allowing the internal display to come back.


    What the underlying fault probably is. There are two candidates:

    A software/firmware bug in panel power-state handling, for example a PSR or low-power state that the driver and Surface firmware disagree about. This is plausible, but it rarely causes visible glitches or distortion.

    Marginal hardware in the display flex cable or connector, the panel's timing controller, or the GPU/board. Flicker and distortion that depend on thermal and power state fit this better, and a link that trains badly on a warm restart but fine when cold is the classic signature.

    The odd 1736×1824 active signal, if it was read exactly (the native panel is 2736×1824), supports a link or timing negotiation problem rather than a simple driver crash.

    I can't prove which one it is from here. The quickest way to tell is to wait for a black screen and then try three things:

    #Win+Ctrl+Shift+B. If the screen returns, it's a driver or WDDM issue.

    #An external monitor over USB-C. If it works while the internal panel stays dead, the fault is in the panel path. If it glitches too, suspect the GPU or driver.

    #Disabling the Intel adapter so Windows uses the Basic Display Adapter. If the failures continue, the Intel driver isn't the cause.

    If the failures survive a clean install of Microsoft's Surface driver package and the Basic Display Adapter test, I would treat it as hardware.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-10-01T16:51:35.8466667+00:00

    The pattern points to a Windows-side display initialization problem rather than a basic panel failure, because the UEFI screen is stable and the failure starts when Windows takes over the display path. In the provided guidance, black screens with a cursor or after startup are commonly tied to a stalled Windows process, display output misconfiguration, or a driver issue. Screen flickering is also described as usually caused by a display driver issue or an incompatible app.

    Most relevant checks:

    1. Reset the graphics driver when the screen goes black:
      • Press Windows + Ctrl + Shift + B.
      • A beep or screen flicker indicates the graphics driver reset was triggered.
    2. Check whether Windows is sending output to the wrong display mode:
      • Press Windows + P.
      • Then tap P again and press Enter to cycle display modes.
      • This is specifically recommended for blank-screen cases caused by display output misconfiguration.
    3. Try the security screen path:
      • Press Ctrl + Alt + Del.
      • If the security screen appears, open Task Manager.
      • From there, try restarting Windows Explorer.
    4. If the issue presents as flicker or distortion, use Task Manager to help isolate the cause:
      • Press Ctrl + Alt + Delete to open Task Manager. If Task Manager does not appear, press Ctrl + Shift + Esc.
      • If Task Manager flickers too, the guidance says a display driver is probably causing the problem.
      • If Task Manager does not flicker while the rest of the screen does, an incompatible app is probably causing the problem.
    5. If the display does not recover, force a restart:
      • On Surface models including Surface Pro 7 generation devices covered by the Surface restart guidance, press and hold the power button until the device shuts down and restarts and the Windows logo appears, about 20 seconds.
      • This matches the behavior already observed where a full power cycle often restores the display.

    What the available guidance supports as the likely explanation:

    • Display driver issue: supported by the flicker troubleshooting guidance.
    • Display output misconfiguration during Windows startup: supported by the blank-screen guidance recommending Windows + P cycling.
    • A stalled Windows process after login/startup: supported by the blank-screen guidance recommending Ctrl + Alt + Del and restarting Windows Explorer.

    What is not established in the provided material:

    • A confirmed root cause in WDDM/DXGKRNL, eDP panel initialization, ACPI, or a specific defect in Intel driver 31.0.101.2130 is not provided.
    • The abnormal resolution observation is consistent with Windows not initializing the display path normally, but no deeper kernel or firmware-level explanation is given in the available material.

    Because UEFI is normal and the failure begins when Windows takes over, the supported conclusion is: the issue is most consistent with Windows display-driver or display-mode initialization during startup, restart, or resume, not with a basic always-failed screen panel.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.