NVIDIA blue screens after a driver or Windows update: install the OEM or previous driver

An NVIDIA display-driver revision can be compatible enough to install but unstable on a particular laptop's GPU, integrated/discrete graphics arrangement, power configuration, or OEM firmware. The useful pattern is not simply “an NVIDIA computer blue-screened.” The pattern is that crashes begin after a display-driver or Windows update, the crash evidence names the NVIDIA display path or a power-state failure, and the same normal workload becomes stable after the exact-model OEM package or the preceding NVIDIA driver is restored.

Four retained cases support this bounded repair path: an ASUS ROG Strix G16 with VIDEO_TDR_FAILURE, an HP ZBook 15 G2 whose Quadro-enabled crashes stopped with an older HP package, a Dell XPS 15 9510 with PAGE_FAULT_IN_NONPAGED_AREA naming nvlddmkm.sys after Windows 11 23H2, and a Windows 10 laptop with DRIVER_POWER_STATE_FAILURE after an NVIDIA update. These are variations of one driver-revision mechanism; they are not proof that every instance of any listed stop code is caused by NVIDIA.

Searchable Windows stop codes, drivers, and identifiers

Use this procedure when Windows can start normally or in Safe Mode and all of the following are true:

• the computer has an NVIDIA display adapter identified in Device Manager;
• the crashes began immediately or soon after an NVIDIA driver installation, a Windows update that replaced the display driver, or a feature update;
• the current driver provider, version, and date can be recorded before removal;
• the exact computer model, service tag, serial-number family, and GPU hardware ID can be identified;
• an exact-model OEM package or the previously working NVIDIA package is available before the current driver is removed; and
• at least one additional fact ties the crash to this display path: nvlddmkm.sys in the blue screen or dump, VIDEO_TDR_FAILURE, a power-transition trigger, NVIDIA enablement as the trigger, or a repeatable before/after driver-version result.

For the four demonstrated variants, keep the model boundary visible. Do not assume that a package for an ROG Strix G16, ZBook 15 G2, XPS 15 9510, or a different laptop sharing the same GPU is interchangeable.

Do not use this procedure merely because the computer contains NVIDIA hardware. It does not apply when the dump consistently identifies another driver, when crashes predate the driver/update change, or when the same crashes continue under the proven previously stable/OEM driver.

Stop and use a hardware or general bug-check diagnostic path when there are GPU artifacts before Windows starts, the adapter disappears, OEM diagnostics fail, temperatures or power are abnormal, RAM errors are present, or 0x116/0x50 continues across clean tests with two known-compatible driver versions. Do not use this as a fix for Device Manager Code 43, a no-display boot failure, a physically loose GPU, overclock instability, or a general Windows Update failure.

The exact internal defect in the driver, the Windows build that first exposed it, and the precise power or memory operation that failed may remain unknown. A consumer repair does not require kernel source code.

The following may not remain unknown before removal:

• exact computer model and, where available, service tag or serial-number family;
• NVIDIA adapter name and hardware ID;
• current driver provider, version, and date;
• the version and official source of the proposed replacement package;
• whether the laptop uses hybrid graphics; and
• whether a recoverable copy of the current or newer OEM package is available if the older package makes the system worse.

“HP SoftPaq 3xx-series Quadro driver” is only a description retained from one report, not a complete package identity. Resolve the exact SoftPaq for the ZBook 15 G2 before installing anything.

• Administrator access
• A verified backup of important files
• Stable AC power
• Exact-model support information from the computer manufacturer
• The replacement driver downloaded from the computer maker or a previously saved, known-working package
• Enough crash history to record the stop name, named module, time, and trigger
• A way to enter Safe Mode if the normal desktop crashes too quickly
• A second package or restore point that can return the machine to its recorded starting driver

Create the evidence folder on the actual online Windows system drive and save the before-state there. In an elevated PowerShell window, run:

$evidence = Join-Path $env:SystemDrive 'DriverEvidence\FIX-073'
New-Item -ItemType Directory -Path $evidence -Force | Out-Null

Get-CimInstance Win32_VideoController |
  Select-Object Name,PNPDeviceID,DriverVersion,DriverDate,AdapterRAM |
  Format-List | Out-File (Join-Path $evidence 'video-before.txt')

Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber |
  Format-List | Out-File (Join-Path $evidence 'windows-before.txt')

Also open Device Manager, expand Display adapters, open the NVIDIA adapter's Properties > Driver page, and photograph the provider, date, version, and signer.

Do not begin by deleting driver-store packages or using a third-party “cleaner.” First download and checksum or otherwise preserve the exact replacement installer, close applications, and pause nonessential work. If Windows Update is actively installing or a restart is pending, let that operation complete and restart before changing the display driver.

If the machine crashes too frequently for normal work, use Settings > System > Recovery > Advanced startup > Restart now > Troubleshoot > Advanced options > Startup Settings > Restart, then select Safe Mode. On Windows 10 the first path is Settings > Update & Security > Recovery. Safe Mode is a controlled access path, not proof that NVIDIA is the cause.

1. Record the complete blue-screen stop name and every named file. Photograph the screen when practical. Copy, rather than move, any files under $env:SystemRoot\Minidump to the $evidence folder. Do not assume Windows is installed on C:.

2. Open Reliability Monitor with:

   perfmon /rel
   

   Record the first NVIDIA-driver installation or Windows feature-update date and the first crash date. A driver/update that occurred after the crashes began cannot be the initiating change.

3. Open Settings > Windows Update > Update history and record any display-driver or feature update immediately before the failures. Do not infer that Windows replaced the driver unless the version/date or history supports it.

4. In Device Manager, open the NVIDIA adapter's Properties > Details page and select Hardware Ids. Save the first complete PCI\VEN_10DE... value. Use the hardware ID only to verify a package; do not search random download sites with it.

5. Check whether Roll Back Driver is available on the Driver tab. Do not select it yet. Its availability shows Windows retained a previous package; it does not prove that package was stable.

6. Compare the OEM support page for the exact model and installed Windows version with the current driver. For a hybrid-graphics laptop, also record the OEM Intel/AMD integrated-graphics package because the two display stacks can be coupled.

7. Establish a minimum evidence threshold. Continue only if at least two independent facts agree, such as:

   • a dump or blue screen names nvlddmkm.sys and the driver version changed immediately before the crashes;
   • 0x116 began with the generic NVIDIA package while the OEM package is a different documented version;
   • 0x9F appears during the same AC-power transition that was normal before the NVIDIA update; or
   • enabling the NVIDIA adapter triggers crashes and a documented older OEM package exists for that exact model.

8. Do not deliberately reproduce another blue screen if ordinary use already supplies the evidence. A forced crash adds risk without improving the decision.

Choose one branch. Branch A is preferred because it preserves Windows' own rollback relationship. Branch B is for an unavailable rollback button or a generic package that must be replaced with the exact OEM package. Branch C provides Safe Mode access when the normal desktop is too unstable.

Branch A — Windows retained the previously installed driver

1. Close applications and disconnect external displays, docks, and nonessential USB graphics devices. Keep AC power connected.
2. Open Device Manager > Display adapters.
3. Right-click the NVIDIA adapter, select Properties, and recheck that its hardware ID and recorded driver version match the intended device.
4. Select Driver > Roll Back Driver.
5. Choose the truthful reason indicating that the previous driver performed better, confirm the rollback, and wait for Device Manager to finish.
6. Restart Windows when prompted. If no prompt appears, restart manually.
7. Return to the Driver page and record the new version/date. If the version did not change, the rollback did not occur; do not claim success.
8. Test using section 12 before allowing another driver replacement.

Branch B — Roll Back Driver is unavailable; install the exact-model OEM or saved prior package

1. Download the official package for the exact computer model, GPU, Windows version, and architecture before removing the current driver. Preserve its filename and version.
2. In Settings > Windows Update, pause updates only for the short diagnostic interval so Windows Update is less likely to replace the test driver. This is temporary; it is not a permanent driver-blocking policy.
3. Disconnect from the network after the required installer is local. Do not browse, read email, or install unrelated software during the reduced-update interval.
4. Open Device Manager > Display adapters, reidentify the NVIDIA adapter, and select Uninstall device.
5. If Windows offers Attempt to remove the driver for this device, select it only when the exact replacement package and a recovery package are already available. Do not use pnputil /delete-driver against an unverified INF.
6. Complete the uninstall and restart. A low-resolution Microsoft Basic Display Adapter state after restart is expected.
7. Run the OEM/prior installer locally. Accept only components intended for the detected hardware. Do not add unrelated utilities solely because the installer offers them.
8. Restart again, confirm the NVIDIA adapter is present without a Device Manager warning, and record the installed driver version.
9. Reconnect the network, resume Windows Update, and watch the driver version. If Windows immediately replaces the package and the crashes return, record both versions and use the computer manufacturer's supported driver-management path; do not apply a permanent broad registry or Group Policy block as part of this article.

Branch C — Normal Windows crashes before the driver can be changed

1. Enter Safe Mode through Advanced startup as described in section 6.
2. In Safe Mode, record the adapter identity again and uninstall only the NVIDIA display device/package selected for replacement.
3. Restart into normal Windows while offline.
4. Install the exact-model OEM or saved preceding driver package.
5. Restart at least twice and then reconnect the network.
6. Continue with the full verification sequence. Safe Mode success alone is not a pass.

• Expected pass: Device Manager shows the intended older/OEM version, ordinary graphics operation and the original power/workload transition no longer produce the recorded stop code, and repeated restarts remain stable.
• Driver silently replaced: The version changes again after reconnecting or running Windows Update. Preserve the before/after versions. The result is not a failed rollback; it is an uncontrolled replacement that must be addressed through the exact OEM support path.
• Different stop code appears: Treat it as a new diagnostic result. Do not keep cycling NVIDIA versions without reading the new dump.
• Same 0x116, 0x50, or 0x9F persists under two known-compatible packages: Stop. Test OEM hardware diagnostics, RAM, thermals, power delivery, and hybrid-graphics firmware rather than broadening the driver claim.
• No NVIDIA adapter after restart: Recheck Device Manager for hidden/unknown devices and use the OEM package. If firmware or OEM diagnostics also cannot enumerate it, stop for hardware service.

• Do not install a driver chosen only by GPU family or a similar laptop model.
• Do not use a third-party driver-download site or generic driver-updater utility.
• Do not change TdrDelay, TdrDdiDelay, or related timeout registry values to hide VIDEO_TDR_FAILURE.
• Do not use Display Driver Uninstaller as the first-line public procedure; it is not required by the retained evidence.
• Do not remove both the integrated and discrete graphics stacks at the same time.
• Do not flash BIOS/UEFI firmware merely because 0x116 occurred.
• Do not permanently disable Windows Update or all driver delivery to preserve an unverified old package.
• Do not call nvlddmkm.sys the root cause solely because it is named; it can be the failing participant in a hardware, power, memory, or compatibility problem.

If the test driver causes worse display behavior, enter Safe Mode if necessary and reinstall the exact driver version recorded in section 5 from the preserved OEM/current package. If Windows' Roll Back Driver button is available after the change, use it and verify that the version actually returns.

Resume Windows Update, reconnect the network, and restore any temporarily disconnected dock or display one at a time. A restore point can be used if the device stack cannot be returned cleanly, but do not promise that System Restore will recover every third-party driver package. If neither preserved package can produce a stable desktop, stop and recover from the verified system image or OEM recovery path rather than deleting more driver-store entries.

1. Confirm the NVIDIA adapter has no Device Manager warning and record its final provider, date, and version.

2. Run the same non-destructive ordinary workload associated with the prior failures. Do not run a synthetic stress test unless hardware testing is the new diagnostic goal.

3. For the AC-power variant, test normal battery-to-AC and AC-to-battery transitions. For a sleep/resume variant, perform one normal sleep/resume cycle.

4. Restart Windows at least three times. Confirm that the chosen driver version persists after reconnecting and after Check for updates.

5. Review Reliability Monitor after the original observation interval. One retained case remained stable for six hours; use six hours as a minimum observation point for that variant, not as universal proof.

6. Confirm that no new 0x116, 0x50, 0x9F, or nvlddmkm.sys crash appears in the same test interval.

7. Save the final adapter state:

   $evidence = Join-Path $env:SystemDrive 'DriverEvidence\FIX-073'
   Get-CimInstance Win32_VideoController |
     Select-Object Name,PNPDeviceID,DriverVersion,DriverDate,AdapterRAM |
     Format-List | Out-File (Join-Path $evidence 'video-after.txt')
   

Confidence is approximately 80% when the diagnostic threshold is met: the crash starts after a documented NVIDIA revision change, the stop/dump or trigger identifies the NVIDIA display path, and an exact-model OEM or recorded prior package is available. Four separate reporter-confirmed cases support the rollback/OEM-package mechanism, but the procedure has not been independently reproduced in the lab.

Confidence is lower when only the timing matches, when the stop code is PAGE_FAULT_IN_NONPAGED_AREA without nvlddmkm.sys, or when the only evidence is that the laptop contains NVIDIA hardware.

Stop before removal when the replacement package is not exact, the current package cannot be recovered, the GPU is not consistently enumerated, or the machine shows pre-Windows artifacts. Stop after one controlled rollback when the same crash persists, the named module changes, Device Manager reports a hardware error, or OEM diagnostics, RAM testing, temperature, or power evidence points away from the driver revision.