0x00000020: Fix the Shutdown APC BSOD Error on Windows

Definition: 0x00000020, KERNEL_APC_PENDING_DURING_EXIT, means an asynchronous procedure call (APC) was still pending when a thread exited.

This guide is part of our Windows BSOD stop codes: full list and fixes series.

This bug check is documented by Microsoft in the bug check reference as KERNEL_APC_PENDING_DURING_EXIT (0x20). The most useful technical clues are in the bug check parameters: Microsoft says Parameter 2 is the APC disable count for the thread, a nonzero value can indicate the source of the problem, a negative value can indicate a driver disabled APC calls without re-enabling them, a positive value indicates the reverse, and Parameter 3 should be zero. If it is not zero, Microsoft says a driver cancellation routine may have returned at an elevated IRQL.

What should you check first after a 0x00000020 BSOD?

Start by keeping the evidence, then tie the crash to the exact action that triggers it. After that, check recent driver or low-level software changes before moving on to repair scans. If you need step-by-step background for adjacent fixes, see our Windows BSOD stop code troubleshooting guide, driver rollback in Device Manager walkthrough, how to boot into Safe Mode on Windows, and SFC and DISM repair guide.

Save the evidence before making changes

1. Open File Explorer > C:\Windows\Minidump and copy any recent .dmp files to the Desktop or another folder so you still have the originals available for later review.
2. Open Event Viewer: press Win + X > Event Viewer, then check Windows Logs > System for errors around the crash time.
3. Open Reliability Monitor: press Win + R, type perfmon /rel, and note the day the failures started.
4. Write down the last change made in Device Manager, Windows Update, antivirus, VPN, backup software, hardware monitoring tools, GPU software, or storage utilities.
5. If the system is stable enough, leave the files in C:\Windows\Minidump untouched and work from the copies you made. Microsoft says the !analyze debug extension displays information about the bug check and can help determine the root cause.

Match the crash moment before touching drivers

• Try to identify the exact action that causes the blue screen, such as Start > Power > Shut down, Sign out, resuming from sleep, or a specific file copy or app launch.
• Repeat that same action after each single change so you can tell whether the change helped.
• If the crash does not happen the same way every time, note the last successful action and the last failed action in Reliability Monitor and Event Viewer.

Decide whether normal mode, Safe Mode, or Clean Boot is best

If Windows stays up long enough to test the trigger, use normal mode first. If normal boot is unstable, use Safe Mode to remove the last added low-level software. If the machine boots but crashes during exit, use a Clean Boot to isolate third-party services and startup items. Safe Mode and Clean Boot are standard Windows isolation steps when normal startup is too unstable for ordinary uninstall or rollback work.

According to 0x00000020 Error: Kernel APC Pending During Exit — The Windows stop code 0x00000020 is labeled KERNEL_APC_PENDING_DURING_EXIT. (source)

Likely causes of 0x00000020, ranked by how often they show up

Keep the initial focus on recent driver changes and other low-level software changes, because Microsoft’s parameter guidance points to APC state and IRQL handling in the thread that exited. The goal is to test one recent change at a time and retest the same trigger after each change.

1. Recently changed drivers and filter drivers

Start with the drivers that changed last. Check storage, network, chipset, GPU, USB, and anything installed right before the crashes. If the system began blue-screening after a driver update, rollback is usually the first clean test. If no recent update is known, an update from the PC or motherboard maker may be the next test.

2. Antivirus, VPN, backup, disk, and monitoring tools

These products often install kernel services or filter drivers. If the crash started after adding or updating one of them, uninstall or disable only that product first, then retest the same trigger before changing anything else.

3. Corrupted system files or damaged Windows components

If no recent driver or utility change lines up with the first crash, check Windows files next with SFC and, if needed, DISM /RestoreHealth. Those are standard Windows repair steps for damaged protected files and the component store.

4. Memory, BIOS, and chipset-level instability

If the crash persists after software isolation, move to memory and storage checks, then BIOS and chipset updates from the system or motherboard manufacturer. Those are follow-up checks rather than the first move.

Is 0x00000020 usually a driver problem or a hardware problem?

Start with drivers and other low-level software, especially if the blue screen began right after a driver change or software install that adds system-level components. Hardware and firmware checks move higher on the list if the problem continues after rollback, uninstall, Clean Boot, and repair scans. If you want a dump-focused workflow, our Windows minidump analysis in WinDbg guide is the companion process to use after preserving the dump.

Use Device Manager with a rollback-versus-update rule

1. Press Win + X > Device Manager.
2. Open the category for the suspect device, such as Display adapters, Network adapters, Storage controllers, System devices, or Universal Serial Bus controllers.
3. Right-click the device > Properties > Driver.
4. If the crashes began right after a driver update and the Roll Back Driver button is active, use Roll Back Driver first.
5. If the device is still on an older vendor package and the crash started without a recent update, choose Update driver or install the current driver from the PC or motherboard maker.
6. After each single change, repeat the exact action that previously caused the crash, such as Start > Power > Shut down, Sign out, or the same file transfer or app launch.

Remove recently added low-level tools one at a time

1. Open Settings > Apps > Installed apps in Windows 11 or Settings > Apps > Apps & features in Windows 10.
2. Uninstall one recent suspect at a time: antivirus add-ons, VPN clients, backup agents, disk utilities, RGB or hardware-monitoring software.
3. Restart, then test the same shutdown, logoff, sleep, or heavy I/O path.
4. If normal uninstall fails, boot into Safe Mode and remove the software there.

Use System Restore if the timing is obvious

1. Press Win + R, type rstrui.exe, and press Enter.
2. Select a restore point from before the BSOD started.
3. Confirm the restore and let Windows restart.
4. Use this when the problem began right after a driver, utility, or failed software installation.

Can antivirus or monitoring software trigger 0x00000020?

Yes. Security suites, VPN clients, backup tools, disk filters, and hardware-monitoring software are reasonable suspects when the crash begins after one of those products is installed or updated. A Clean Boot can help show whether a third-party service or startup item is involved.

Run a Clean Boot with msconfig

1. Press Win + R, type msconfig, and press Enter.
2. Open the Services tab and check Hide all Microsoft services.
3. Click Disable all.
4. Open the Startup tab and click Open Task Manager.
5. Disable all startup items, close Task Manager, click OK, and restart.
6. Retest the same action that caused the BSOD. If the system no longer crashes, re-enable a small group of services or startup items, restart, and retest again until the crash returns.

Use Safe Mode when normal uninstall fails

1. Open Settings > System > Recovery > Advanced startup > Restart now in Windows 11, or Settings > Update & Security > Recovery > Advanced startup > Restart now in Windows 10.
2. Go to Troubleshoot > Advanced options > Startup Settings > Restart.
3. Press 4 for Safe Mode.
4. Remove the suspect tool from Settings > Apps or roll back the related driver in Device Manager.

How do you tell whether system files are causing 0x00000020?

Suspect system files when the crashes began after a failed install, an improper shutdown, or repeated Windows errors in Reliability Monitor and Event Viewer, and when no recent driver change matches the start date. In that case, run SFC first, then DISM, and then SFC again.

Run SFC and read the result correctly

1. Right-click Start and open Terminal (Admin) or Command Prompt (Admin).
2. Run sfc /scannow.
3. If SFC says it repaired files, restart Windows, then repeat the same action that previously caused the blue screen.
4. If it says it found no integrity violations, move to DISM instead of repeating SFC.

HashRoot includes sfc /scannow in its repair steps. Microsoft’s System File Checker documentation is the source I trust for interpreting the output states.

Run DISM, then rerun SFC

1. Open Terminal (Admin) or Command Prompt (Admin).
2. Run DISM /Online /Cleanup-Image /RestoreHealth.
3. After DISM completes, run sfc /scannow again.
4. Restart and retest the same action that caused the crash.

HashRoot also recommends DISM /Online /Cleanup-Image /RestoreHealth. Microsoft’s DISM technical reference is the precise citation for why this comes before a final SFC rerun when component corruption is suspected.

If scans are clean but the blue screen keeps returning

That result pushes attention back toward drivers, filter drivers, or platform stability. Microsoft says the APC disable count in Parameter 2 helps identify the source, a negative value can indicate a driver disabled APC calls without re-enabling them, and Parameter 3 should be zero or a driver’s cancellation routine may have returned at an elevated IRQL.

How should you triage 0x00000020 by crash timing?

Use the crash moment as a sorting tool. If it always happens during one specific action, keep that action unchanged while you test one fix at a time. That makes it easier to tell whether rollback, uninstall, Clean Boot, or repair scans changed the outcome.

Decision matrix: crash timing, likely cause, first three tests

How to use this table: pick the row that matches the action that reliably causes the crash, make only the first change in that row, then repeat the same action again before moving to the second test.

Roll back vs update: the driver choice table

Annotated minidump walkthrough: proving how 0x00000020 timing maps to a driver stack

If you have a minidump, use it to narrow the suspect area before making broad changes. Microsoft says the !analyze debug extension displays information about the bug check, and for this one the parameters are especially useful.

1. Preserve the dump first. Copy the newest file from C:\Windows\Minidump to another folder before uninstalling software or changing drivers so you still have a reference copy.
2. Open the dump in WinDbg and run !analyze -v. Check the bug check line and pay close attention to Parameter 2 and Parameter 3. Microsoft says Parameter 2 is the APC disable count for the thread, and Parameter 3 should be zero.
3. Correlate the timing. Compare the dump time with Reliability Monitor and Event Viewer so you know whether the crash is tied to shutdown, logoff, sleep/resume, or another repeatable action.
4. Read the active stack, not just the bug check line. Look for the driver or subsystem that appears in the active stack around the failing thread.
5. Check recent changes in that area. If the stack points toward networking, storage, graphics, or another subsystem, review the driver and software changes that affect that subsystem first.
6. Use a change-and-retest loop. Make one change, such as uninstalling one recently added VPN or rollbacking one driver, then repeat the same trigger several times. If the crash stops, that change is a strong lead; if not, restore stability and move to the next single change.

What the proof means: use the dump parameters, the active stack, and a repeatable trigger together. That combination is stronger than guessing from the stop code alone.

If that did not work, move to platform checks

1. Press Win + R, type mdsched.exe, and choose Restart now and check for problems to run Windows Memory Diagnostic.
2. Run chkdsk C: /F from an elevated command prompt, approve the disk check for the next restart if prompted, restart the PC, let the scan finish, and then repeat the same action that previously caused the crash. A user report said CHKDSK found and fixed errors. (avast.com)
3. Install BIOS and chipset updates from the PC or motherboard maker.

Still not working?

If the crash keeps happening after driver rollback, Clean Boot, and repair scans, move from broad troubleshooting to controlled isolation. Keep the minidump copies, keep testing the same trigger, and avoid changing multiple things at once.

Escalation ladder

1. Retest in a Clean Boot state and then in Safe Mode. If shutdown succeeds there, a third-party service or filter is still a lead suspect.
2. Use System Restore to return to the point before the first crash if a recent change matches the timeline.
3. If Windows remains damaged after those checks, use Settings > System > Recovery > Reset this PC in Windows 11 or Settings > Update & Security > Recovery > Reset this PC in Windows 10, after backing up personal files first.
4. If the minidump is available, have it reviewed with !analyze. Microsoft says !analyze displays bug check information and can help determine the root cause.
5. If crashes persist after a near-clean software state, BIOS update, chipset update, memory test, and disk checks, move to vendor support or hands-on hardware diagnostics.

Prevention

Keep a short change log for drivers and low-level utilities. If shutdown, sleep, or heavy I/O starts failing right after one install, reverse that single change first instead of updating everything at once.

Author and testing context

Author: Daniel Mercer, Windows troubleshooting writer and bench technician.

Testing context: Use standard Windows isolation steps such as preserving minidumps, checking Event Viewer and Reliability Monitor, testing with Clean Boot or Safe Mode, and confirming a fix by repeating the same trigger after one change at a time.

Primary references used: Microsoft Learn pages for KERNEL_APC_PENDING_DURING_EXIT (0x20), WinDbg !analyze, System File Checker, DISM operating system package servicing command-line options, Windows Start your PC in safe mode in Windows, and Windows Memory Diagnostic.

Frequently asked questions

What does stop code 0x00000020 mean in Windows?

Save C:\Windows\Minidump, check Event Viewer > Windows Logs > System, and note the last changed driver or low-level utility before making repairs.

Why does 0x00000020 happen during shutdown or logoff?

Shutdown and logoff force drivers and other low-level software to finish cleanup work. That is why rollback or removal of recent antivirus, VPN, backup, chipset, storage, GPU, network, USB, and monitoring software is a practical early test.

What should I do first if I get a 0x00000020 blue screen?

Copy the minidump from C:\Windows\Minidump, open perfmon /rel to find the first failure date, and match the crash to a repeatable action. Then test the last changed driver in Device Manager with rollback before trying wider fixes.

Can antivirus or monitoring software trigger 0x00000020?

Yes. Use msconfig, check Hide all Microsoft services, click Disable all, disable startup items in Task Manager, and retest the same trigger. If the crash stops, re-enable items in batches or uninstall the newest security, VPN, backup, or monitoring package.

Will clean boot or safe mode help fix 0x00000020?

They help by separating Microsoft services from third-party software. Use msconfig for a Clean Boot when Windows still runs, and use Settings > Recovery > Advanced startup for Safe Mode when normal uninstall or rollback fails because the system crashes too early.

What if 0x00000020 keeps happening after reinstalling drivers?

Move to platform and Windows checks in order: run mdsched.exe, run chkdsk C: /F, then run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. If it still returns, install BIOS and chipset updates and get the dump reviewed with !analyze.

Short FAQ answers for quick scanning

• Most common starting point: a recently changed driver or other low-level software.
• Most useful clue: the exact action that triggers the crash.
• Best first action: save the minidump before uninstalling or rolling back anything.
• Best proof: a minidump review plus a retest that changes only one variable.