Why Shutdown Doesn't Fix Your GPU Problem but Restart Does? Windows Fast Startup, Hybrid Shutdown & Driver State Explained

2026-10-25 ｜ GPU Repair ｜ About 15 minutes ｜ HK GPU Fix Editorial Team

重點摘要

Windows Fast Startup turns shutdown into a hybrid sleep that saves the kernel and driver state to disk, so a shutdown often preserves the very fault a restart would clear. This guide explains that mechanism, compares shutdown, restart, and Shift-plus-shutdown, and sets out when disabling Fast Startup is a useful diagnostic comparison rather than a permanent fix.

The Short Answer First

When a graphics problem survives a shutdown but disappears after a restart, the usual explanation is not that the shutdown button is broken. On a Windows 10 or Windows 11 machine with Fast Startup switched on, shutdown and restart are different operations. Shutdown closes the user session and then saves the kernel session, including loaded driver state, to disk. Restart discards the kernel session and loads it fresh. A fault that lives in kernel or driver state therefore survives shutdown and gets cleared by restart, which is exactly the pattern many users report: same fault after every shutdown, gone after one restart, back again after the next shutdown.

This article is about that mechanism only. It is not about standby power still reaching a card after shutdown, which article #202 covers. It is not about a black screen on the way into Windows, which article #141 covers. And it is not about crashes that happen while a machine sits idle, which article #151 covers. Those three problems share surface symptoms with this one — a screen that misbehaves, a machine that seems not to have switched off properly — but they have different causes and different tests. Keeping them apart is what makes the tests in this article useful.

What Shutdown Actually Does When Fast Startup Is On

Fast Startup is switched on by default on most Windows 10 and Windows 11 installations. With it on, choosing Shut down does the following, in order. First, Windows signs out the user session and closes open applications, the same as any shutdown. Second, instead of discarding the kernel session, Windows writes it to the hibernation file on disk. The kernel session includes the loaded state of kernel-mode drivers, which includes the graphics driver core. Third, the machine powers off. On the next power-on, Windows reads the kernel session back from disk instead of initialising it from scratch, then starts a fresh user session on top of it.

The practical consequence is that the kernel session is continuous across shutdowns. Anything wrong inside that session — a driver stuck in a bad power state, a corrupted display configuration held in kernel memory, a device state that a driver failed to reset — is carried forward to the next boot. The user session is fresh, so desktop icons, open windows, and logged-in applications all look normal, which makes the fault harder to recognise. The machine looks as if it started cleanly, because half of it did.

Restart behaves differently by design. Restart closes the user session and discards the kernel session as well, then loads both fresh. That is why a restart clears faults that a shutdown preserves. It is also why Windows Update and driver installers ask for a restart rather than a shutdown: a restart is the only ordinary operation that guarantees a fresh kernel session.

What Restart Does Differently, Step by Step

The difference is worth spelling out, because it explains every test later in this article. During a restart, Windows unloads drivers, powers down devices, and then runs the full boot sequence: firmware initialisation, kernel load, driver load, device enumeration, and user session start. Every stage runs from its initial state. During a Fast Startup shutdown, the firmware stage still runs, but the kernel load stage is replaced by reading a saved session from disk, and driver load is partly replaced by restoring saved driver state. Device enumeration still happens, and devices are re-initialised, but the software state that drives them is restored rather than rebuilt.

This distinction also explains why the fault pattern is intermittent in a specific way. A fault that lives in driver state appears after the driver enters the bad state, survives every shutdown until something forces a fresh kernel session, and then stays away until the driver enters the bad state again. Users often describe this as the problem coming and going for no reason. The reason is usually the sequence of operations: a restart in the middle breaks the chain, and a run of shutdowns preserves it.

The Three Boundaries: Not #202, Not #141, Not #151

Article #202 covers standby power: power that continues to reach parts of a machine after shutdown, keeping lights on or fans spinning, and the distinction between a machine that is truly off and one that is in a low-power state. That article is about electricity. This article is about software state. A machine can be fully powered off and still restore a faulty kernel session, because the session lives on disk, not in powered memory. If the symptom is a light or a fan, read #202. If the symptom is a graphics fault that a restart clears, stay here.

Article #141 covers a black screen on the way into Windows: the display path during boot, firmware output, and the handover from firmware to the Windows display driver. That problem appears during the boot sequence itself, before the desktop loads. The problem in this article appears after the desktop has loaded normally, as wrong resolution, a missing second monitor, flicker, stutter, or a driver error that only a restart removes. If the screen never shows anything from power-on, #141 is the right guide.

Article #151 covers crashes while a machine sits idle: power-state transitions at idle, display sleep, and devices failing to wake cleanly. That problem is triggered by time passing without input. The problem in this article is triggered by the shutdown path itself: the fault is present from the moment the desktop appears, after a shutdown, and absent after a restart. If the machine behaves after boot and only fails after sitting idle, #151 is the right guide.

A Comparison Table: Shutdown, Restart, Shift-Plus-Shutdown, Hibernate

Shift plus Shut down is the most useful single test in this article. Holding Shift while choosing Shut down tells Windows to perform a full shutdown for that one occasion, bypassing Fast Startup without changing any setting. If a fault that survives ordinary shutdown disappears after a Shift plus Shut down, the fault lives in saved kernel or driver state, and Fast Startup is the mechanism preserving it. If the fault survives a Shift plus Shut down as well, the fault is not a saved-state problem, and the next steps belong elsewhere: cable and port checks, driver reinstallation, or hardware inspection.

The Diagnostic Sequence, One Change at a Time

Start with the restart comparison, because it costs nothing and changes nothing. Note the fault, restart, and check whether the fault is gone. If it is gone, shut down normally, power on, and check again. If the fault returns after the ordinary shutdown, the pattern points at saved kernel state. Repeat the pair once more to be sure, because a single observation can be coincidence: a driver can recover on its own, or a second monitor can behave differently for an unrelated reason. Two consistent rounds — fault after shutdown, clear after restart — are enough to act on.

Next, run the Shift plus Shut down test. Hold Shift, choose Shut down, wait for the machine to power off fully, then power on and check. If the fault is gone after this one-off full shutdown, the evidence points at Fast Startup preserving the fault. This test changes no setting, so it is safe to repeat and safe to use as a comparison whenever the fault returns.

Only after those two comparisons should the Fast Startup setting itself be touched, and then only as a diagnostic comparison. The setting lives under Control Panel, Power Options, Choose what the power buttons do, under Change settings that are currently unavailable, as Turn on fast startup. Untick it, shut down, power on, and check. If the fault stays away across several ordinary shutdowns with the setting off, Fast Startup was preserving it. That result still does not prove the driver is healthy. It proves the fault needs a fresh kernel session to clear, which usually means the driver or its configuration is entering a bad state during use, and the saved session is carrying that state forward.

Disabling Fast Startup as a Diagnostic Comparison, Not a Default Fix

Turning Fast Startup off permanently is a trade-off, not a cure, and it should be presented that way. With Fast Startup off, every shutdown becomes a full shutdown, so boot takes longer, because the kernel session is rebuilt from scratch each time. On a machine with a fast solid-state drive, the difference is small; on a machine with a slower drive, it is noticeable every single morning. Fast Startup also depends on hibernation: switching hibernation off removes Fast Startup as a side effect, and switching it back on restores the option. Anyone who runs the powercfg comparison should know which change was made, so it can be reversed cleanly.

There are also situations where leaving Fast Startup off is the right long-term choice, and situations where it is not. It is reasonable to leave it off when a machine has a recurring driver-state fault that no driver update resolves, when the machine dual-boots with another operating system that needs clean access to shared drives, or when shutdown behaviour itself is being diagnosed. It is less reasonable to leave it off as a first response to every graphics problem, because most graphics problems are not saved-state problems, and turning the setting off then hides the diagnostic signal without fixing the cause. The disciplined order is: compare first, change the setting second, and only keep the change if the comparison supports it.

A related trap is treating a driver reinstall as equivalent to a restart. Reinstalling a driver while Fast Startup is on can leave the old driver state in the saved kernel session, so the fresh driver files load on top of a restored session that still holds the old state. That is why driver installers ask for a restart, and why a driver reinstall that ends in a shutdown can appear to have no effect. After any driver change, restart, not shutdown. The same applies to Windows Update: updates that report as installed after a shutdown may still be waiting for the restart that completes them.

Symptom Patterns and What Each One Suggests

This table is a triage tool, not a diagnosis. A pattern suggests a direction; it does not prove a cause. The Shift plus Shut down test is what turns a suggestion into evidence, and a driver reinstall followed by a restart is what tests whether the driver itself is at fault rather than the saved session.

Six Misconceptions, Corrected

First, shutdown does not always mean off and fresh. With Fast Startup on, shutdown is a hybrid operation, and the word shutdown on the menu does not describe a full shutdown. Second, a faster boot is not proof of a healthy boot. Fast Startup boots faster precisely because it skips rebuilding the kernel session, which is the step that would clear a saved-state fault. Third, restarting from the login screen or from the power menu are the same operation; neither is a shutdown, and both clear the kernel session. Fourth, unplugging the machine does not clear a saved kernel session, because the session lives on disk, not in powered memory. Unplugging clears standby power problems, which is #202 territory, not this article. Fifth, updating a driver does not guarantee a fresh driver state. If the update ends in a shutdown with Fast Startup on, the old session can be restored over the new files. Sixth, disabling Fast Startup does not repair a driver. It removes the mechanism that preserves a fault, which is useful for diagnosis and sometimes for daily stability, but a driver that repeatedly enters a bad state still needs a driver update, a settings change, or inspection.

Edge Cases Worth Recognising

Laptops with modern standby blur the picture further, because their sleep states keep more of the system alive than traditional sleep, and their shutdown path still depends on the same Fast Startup setting. The tests in this article still apply, but the observations need more care: a laptop that was never truly shut down, only put to sleep by closing the lid, has not run either operation, and its behaviour says nothing about Fast Startup. Check that the machine actually shut down, by watching it power off fully, before drawing conclusions.

Another edge case is a pending Windows Update. While an update is waiting for a restart, shutdown with Fast Startup on does not complete the update, and the machine can behave oddly across several shutdowns until a restart finally runs. If a graphics fault appears at the same time as a pending update notice, restart first and judge afterwards. A third edge case is a second monitor or docking station whose state is held by its own firmware. A fresh kernel session does not reset a dock, so a fault that survives both shutdown and restart but disappears when the dock is power-cycled points at the dock, not at Windows.

When Inspection Is Warranted, and What to Prepare

Inspection is warranted when the fault survives a full shutdown and a restart, when it survives a driver reinstall followed by a restart, when it appears alongside artifacts, crashes, or a card that is not detected at all, or when the shutdown pattern keeps returning even with Fast Startup off. Before bringing the machine in, note the exact pattern: fault after shutdown, clear after restart, or fault after both. Note whether Shift plus Shut down clears it, whether Fast Startup is on or off, and which driver version is installed. That short note saves a long round of questions and points the inspection at the right layer first.

FAQ

Does shutdown with Fast Startup on damage the graphics card?

No. Fast Startup changes which software state is restored at boot; it does not change voltages, temperatures, or the physical state of the card. The harm it can cause is diagnostic confusion, by preserving a software fault across boots, not physical damage.

Why does my machine boot faster after shutdown than after restart?

Because shutdown with Fast Startup on restores a saved kernel session instead of rebuilding it, while restart rebuilds it from scratch. The speed difference is the visible sign of the mechanism this article describes.

Is Shift plus Shut down the same as turning Fast Startup off?

For one shutdown, yes. Shift plus Shut down performs a full shutdown for that occasion without changing any setting. Turning the setting off makes every shutdown a full shutdown until the setting is changed back.

Should I leave Fast Startup off forever?

Only if the comparison supports it: the fault stays away with the setting off, returns with it on, and no driver update resolves the underlying driver state. Otherwise the longer boot time buys nothing, and the underlying cause remains unaddressed.

Does unplugging the machine clear a saved kernel session?

No. The saved session lives on disk, so removing power does not erase it. Unplugging addresses standby power, which is a different problem covered by article #202.

Why did a driver update seem to change nothing?

If the update ended in a shutdown with Fast Startup on, the old kernel session may have been restored over the new driver files. Reinstall or update the driver, then restart, and judge the result after the restart.

Can Fast Startup cause a black screen?

It can preserve a driver state that produces display faults after boot, but a screen that shows nothing from power-on is a boot display path problem, covered by article #141, not a saved-state problem.

What should I note before asking for inspection?

The shutdown pattern, the result of the Shift plus Shut down test, the Fast Startup setting, and the driver version. Those four facts separate a saved-state problem from a hardware problem before any inspection begins.

Getting Help in Hong Kong

If the fault survives a full shutdown, a restart, and a driver reinstall followed by a restart, or if it comes with artifacts, crashes, or a card that is not detected, bring the machine in for inspection. HK GPU Fix is at Shek Mun, Dali Plaza, Room 1209. The phone number is 2186 8010 and WhatsApp is 6558 6806. There are no home visits and no Mong Kok shop. Inspection pricing follows the published three-tier range of HK$400 to HK$2,800, with a final quote after inspection.