Fix DRIVER_OVERRAN_STACK_BUFFER (0xF7) in Windows 11

DRIVER_OVERRAN_STACK_BUFFER, or stop code 0x000000F7, means a driver wrote past the end of a buffer that lives on the kernel stack and damaged the value a function relies on to return safely. Windows detected the damage and stopped the machine instead of letting the function return to wherever the corrupted value pointed.

This stop code is unusual because Microsoft describes it in security terms: it is the classic buffer overrun, and the system shuts down to prevent a malicious user from gaining control. That framing worries people, and it deserves a careful explanation. This guide covers what the parameters mean, why this is not automatically a sign of an attack, and how to find the driver responsible.

PAGE CONTENT

• What 0xF7 Means and Why Windows Stops
• Read the Parameters
• Fix 1: Identify the Driver From the Trigger
• Fix 2: Update or Remove the Suspect Driver
• Fix 3: Rule Out Malware and Unsupported Drivers
• Fix 4: Test Memory and Storage
• Fix 5: Repair Windows and Verify
• FAQs About DRIVER_OVERRAN_STACK_BUFFER
• Back Up and Restore Windows with Qiling Disk Master

What 0xF7 Means and Why Windows Stops

A function needs to know where to return to when it finishes, and it stores that return address on the stack, next to its own local variables. If code writes past the end of a local buffer, the bytes it overwrites can include that return address. The function then returns not to its caller but to an address built from whatever data was written, and the machine starts executing in the wrong place.

To catch that, the kernel places a stack cookie, also called a security check cookie, at a known position in the frame, and keeps both the cookie and its bit-complement. Before a function returns, the code verifies that the cookie is unchanged. This stop code means the check failed, so a function's locals were overwritten by something writing beyond its own buffer.

Microsoft states the implication plainly: this is the classic buffer overrun pattern used in attacks, and the system is shut down to prevent a malicious user from taking complete control. That said, the important word in that sentence for a home user is "pattern". A driver with an ordinary bug, one that mishandles an oversized or malformed input, produces exactly the same signature as a deliberate exploit. What you know for certain is that a driver wrote outside its own local buffer, not that you have been compromised.

Read the Parameters

The parameters exist to quantify how badly the cookie was damaged:

• Parameter 1 — the actual security check cookie found on the stack
• Parameter 2 — the expected security check cookie
• Parameter 3 — the bit-complement of the expected security check cookie
• Parameter 4 — always zero

In a healthy frame, the value in parameter 1 would match parameter 2, because the check would have passed and no stop code would occur. The fact that they differ is the evidence that something overwrote the value. Comparing them tells you how thoroughly the stack area was clobbered, which is useful for a developer but less so for a repair.

What you actually need is the driver. In a debugger, the stack trace is the tool: immediately before the buffer overrun handler and the stop code call, the last routine on the stack is the one that wrote past its own local variables. If you are not debugging, the equivalent evidence is the trigger and the recent changes described next.

Fix 1: Identify the Driver From the Trigger

Step 1. Write down precisely what you were doing. Buffer overruns are usually tied to a specific input, so a reproducible trigger is the single most valuable clue. In one documented case, the fault appeared only when a particular game was running, and the driver involved turned out to be related to a connected device rather than to the game itself.

Step 2. Recall what changed recently. A newly installed driver, a new peripheral, new security software, or a freshly updated application moves to the top of the suspect list, because an overrun is normally introduced by code that changed.

Step 3. Check whether a device is involved. Drivers that parse data from outside the system are the classic candidates: universal serial bus devices, network and wireless adapters, Bluetooth stacks, printers, and anything with a custom driver or a licence dongle.

Step 4. Note whether the error mentions a stack protection failure. That kind of report confirms the mechanism described above and tells you a driver, rather than an application, is responsible.

Fix 2: Update or Remove the Suspect Driver

Step 1. Update the driver for the device or component in your trigger, using the manufacturer's package rather than a generic one. A driver that mishandles an input and overruns its buffer is usually fixed by a later release, so an update is often the whole solution.

Step 2. If updating does not help, uninstall the driver, restart, and let Windows reinstall a clean copy, or install the previous known-good version instead. A corrupted installation can produce the same behaviour as a buggy one.

Step 3. For graphics related cases, do a clean install with a display driver uninstaller while in Safe Mode, then install the vendor package. Graphics drivers are large and prone to leaving components behind.

Step 4. Consider the security software. Antivirus suites, virtual private network clients, disk encryption products, and system utilities all install kernel drivers that process external data, and replacing one with a current version is a reasonable test.

Fix 3: Rule Out Malware and Unsupported Drivers

Step 1. Because this stop code shares its signature with an exploit, run a full scan with a current definition set, and ideally with a scan that runs outside Windows. Treating it as a possible intrusion costs you little and removes the doubt.

Step 2. Remove unofficial driver packages. Drivers downloaded from third-party download sites or bundled with tools of uncertain origin are a real risk, and they are also the most likely to contain the kind of bug this stop code reports.

Step 3. Look for unsigned or unfamiliar kernel drivers. Our guide on DRIVER_VERIFIER_DETECTED_VIOLATION explains how to inspect and verify drivers, and how to recover if a verification attempt leaves the machine unable to start.

Step 4. Remove optimiser and tweaking utilities that install kernel components. These tools frequently write to protected areas they do not fully understand, and their kernels drivers are rarely held to the standards of a mainstream vendor.

Fix 4: Test Memory and Storage

Step 1. Run the built-in memory checker as a first pass. Press Windows and R, type mdsched.exe, and choose to restart and check now. Save your work first, because the test runs before Windows loads.

Step 2. Follow up with a thorough test. A bootable memory tester that completes four or more full passes, ideally overnight, catches faults the quick check misses. A bit flip can also corrupt a stack value, so this step is worth doing even though an overrun is the more likely explanation.

Step 3. Disable the memory profile in BIOS or UEFI and remove any overclock, since unstable timings produce exactly this kind of random corruption.

Step 4. Check the system drive. Read the SMART attributes and look at the reallocated sector count and the remaining life value, because a drive returning corrupted data can damage kernel memory as it is loaded.

Fix 5: Repair Windows and Verify

Step 1. Open Command Prompt as administrator and repair the component store, then the protected system files:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Step 2. Install all pending Windows updates, including the optional driver updates, and update the system firmware and chipset drivers if they are behind.

Step 3. Reproduce the original trigger for several days. Because an overrun depends on a particular input, confirming that the same action no longer crashes is a meaningful test, and stability over time is the real proof.

Step 4. Keep a written record of what you changed. If the stop code returns, that record tells you whether it tracks a specific driver or appears regardless.

FAQs About DRIVER_OVERRAN_STACK_BUFFER

Does this mean my PC has been hacked?

Not necessarily. Microsoft describes the mechanism as the classic buffer overrun used in attacks, but a driver with an ordinary input-handling bug produces the same signature. Most cases trace to a buggy or outdated driver. Run a full scan anyway, because it is cheap and removes the doubt.

What is the security cookie mentioned in the parameters?

It is a canary value placed on the stack when a function starts, together with its bit-complement. Before the function returns, the code checks that the cookie is intact. If it changed, something wrote past a local buffer.

Why do parameters 1 and 2 differ?

Parameter 1 is the cookie actually found on the stack and parameter 2 is the value that was expected. In a healthy frame they would match; the mismatch is the evidence that the value was overwritten.

Can faulty memory cause this?

It can, though a buffer overrun is far more common. If memory tests report errors, or the crashes appear at random rather than on a repeatable action, test the memory thoroughly and disable any overclock.

Why does it only happen with one particular program or device?

Because an overrun needs the specific input that overflows the buffer. That is also why the trigger is the most useful clue you have, and why the fix usually involves the driver that handles that input.

Will resetting Windows fix it?

Only if the offending driver is removed by the reset. If you reinstall the same device or software afterwards, the same driver returns and the stop code comes back with it.

Back Up and Restore Windows with Qiling Disk Master

Resolving this stop code means Safe Mode sessions, driver removals, and possibly malware cleanup, and any of those can leave a machine that will not start. Create a full system backup before you begin. Qiling Disk Master handles both the backup and the restore.

• Free Download
• Windows 11/10/8/7, 100% Secure

Part 1: Create a Full System Backup

Step 1. Install and open Qiling Disk Master. On the home screen, open "Backup and Recovery" and choose "System Backup". This option automatically includes Windows and the hidden boot partitions, so you do not have to select them one by one.

Step 2. Check the source. The disk where Windows is installed and its system partitions are already ticked for you. If you only need your personal documents, run a separate "File Backup" task instead.

Step 3. Click the destination box and choose where the image should be saved. Use an external HDD or SSD, a NAS, or any drive other than the one Windows is installed on, and make sure it has enough free space.

Step 4. Review the task summary and click "Proceed". Wait until the progress bar reaches 100%. Do not unplug the drive or turn off the PC while the backup is running.

Part 2: Restore Windows from the Backup

Step 1. Open Qiling Disk Master again, go to "Backup and Recovery", and select the recovery option. Your backup images are listed, so pick the one you created before the changes began.

Step 2. Choose the target disk or partition. Normally you restore to the original system disk. If the drive was replaced, select the new disk instead, and the restore rebuilds Windows together with its boot partitions.

Step 3. Preview the restore plan, click "Proceed", and confirm the warning. The PC restarts to finish the job, and Windows comes back exactly as it was on the day the image was created, with your files and programs intact.

Conclusion

DRIVER_OVERRAN_STACK_BUFFER means a driver wrote past the end of one of its local buffers and damaged the security cookie that protects a function's return address. Microsoft frames the mechanism as the classic buffer overrun used in attacks, but the same signature comes from ordinary driver bugs, so the practical conclusion is that a driver mishandled an input rather than that you were necessarily attacked. Parameter 1 and parameter 2 differ because the cookie was overwritten, which confirms the mechanism but not the culprit. Work from the trigger: identify the device or program involved, update or remove its driver, run a full malware scan and clear out unofficial drivers, then test the memory and the drive before confirming stability over several days.

Protect your PC with Qiling Backup—create a system image before your next troubleshooting step.

Related Articles

• Fix BAD_POOL_HEADER BSOD (0x00000019) in Windows 11
  The other stop code an overrun produces. When a driver writes past its buffer, the damage can land in a pool header instead of the stack.
• Fix ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY 0xFC in Windows 11
  What happens next if a corrupted return address is actually followed. Useful for understanding why Windows stops so abruptly.
• Fix DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4) in Windows 11
  How to inspect and verify kernel drivers, including the settings that catch a driver writing where it should not.
• Fix KMODE_EXCEPTION_NOT_HANDLED BSOD in Windows 11
• Windows 11 Blue Screen: Causes and Step-by-Step Fixes