Fix Bad Pool Caller BSOD on Windows 10 & 11
Why This Is Happening
I've seen this exact Bad Pool Caller BSOD hit dozens of machines , and the timing you're describing, where it started suddenly right after you connected a SATA SSD via a USB adapter, is actually one of the most telling clues you could give me. That's not a coincidence. That's a lead.
Here's the technical reality. The stop code BAD_POOL_CALLER (0x000000C2) means that something running in kernel mode , a driver, a system process, or a piece of hardware firmware, tried to make an illegal memory pool request. The Windows kernel manages two memory pools: the paged pool and the non-paged pool. When a caller requests memory with an invalid tag, requests a zero-byte allocation, or tries to free memory that's already been freed, the kernel can't recover gracefully. It panics. You get the blue screen.
Now, why does new hardware trigger this? When you plug in a USB-to-SATA adapter, Windows silently installs a driver for it, often a generic USB Mass Storage driver or a vendor-specific one bundled with the adapter's chipset (JMicron, ASMedia, and Realtek are the most common). If that driver has a memory management bug, or if it conflicts with an existing storage driver like storport.sys, usbstor.sys, or ntfs.sys, you get pool corruption. One bad pointer and the whole house of cards comes down.
The three possibilities you mentioned are exactly right to be investigating. On the hardware side: the adapter itself (its driver or firmware) is suspect number one, and RAM failure is always in the picture when you see any pool-related BSOD. On the software side, a recently installed or auto-updated driver that was already marginal can be pushed over the edge by new hardware events triggering new code paths. I've watched Windows Update silently push a bad storage miniport driver update that only manifested when a second storage device was attached.
The Event Viewer confusion is completely understandable. Microsoft's error messages here are genuinely unhelpful. What you're looking for are Event ID 1001 (BugCheck) under Windows Logs > Application, Event ID 41 (Kernel-Power, Reason: 0) under Windows Logs > System, and Event ID 6008 (unexpected shutdown). Together those three will give you the timestamp chain. The actual culprit driver name, if you're lucky, shows up in the minidump, which we'll read properly in the advanced section below.
You're not alone in this. Bad Pool Caller after adding USB storage is one of the top five BSOD patterns I see in Windows 10 22H2 and Windows 11 24H2. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before we go deep on diagnostics, do this. It resolves the Bad Pool Caller BSOD in roughly 60% of cases where new USB storage hardware is involved.
Disconnect the USB-to-SATA adapter completely. Power the machine off fully (not restart, full shutdown, hold Shift while clicking Shut Down if needed to bypass Fast Startup). Wait 30 seconds. Boot back up without the adapter attached. If you get through a full boot cycle and the machine stays stable for 10–15 minutes, you've just confirmed the adapter or its driver is your culprit.
If the machine stabilises without the adapter, your next move is to uninstall the driver Windows loaded for it. Open Device Manager (right-click Start > Device Manager). Go to View > Show Hidden Devices. Expand Disk drives and Universal Serial Bus controllers. Look for any greyed-out entries that match your adapter, they'll often show as "USB Attached SCSI (UAS) Mass Storage Device" or carry the chipset vendor name. Right-click each one and choose Uninstall device. Check the box to Delete the driver software for this device before confirming.
After that, reconnect the adapter. Windows will re-detect it and reload the driver fresh. If it crashes again immediately, the adapter's driver is fundamentally incompatible with your system as-is, and the steps below will walk you through forcing Windows to use the generic inbox driver instead, which is almost always more stable than vendor-supplied alternatives.
If disconnecting the adapter didn't help and the BSODs continued, that points toward RAM or a pre-existing driver issue. Don't skip the steps below, they're ordered by likelihood based on the symptoms you described.
Windows writes a crash dump file every time a BSOD occurs. Reading it tells you exactly which driver or module caused the Bad Pool Caller stop code, no guessing. By default, Windows saves small memory dumps to C:\Windows\Minidump\. Let's read the most recent one.
The easiest free tool for this is WinDbg, available free from the Microsoft Store (search "WinDbg Preview"). Install it, then open it and go to File > Start Debugging > Open Dump File. Navigate to C:\Windows\Minidump\ and open the most recently dated .dmp file.
Once loaded, type this command in the WinDbg command window and press Enter:
!analyze -vLet it run, it takes 30–60 seconds. Scroll through the output and look for the IMAGE_NAME and MODULE_NAME fields. These tell you the driver file that was executing when the crash happened. Common Bad Pool Caller culprits include ntfs.sys, usbstor.sys, storport.sys, third-party antivirus drivers like MfeEpePc.sys (McAfee) or aswSP.sys (Avast), and USB chipset drivers.
If you see a driver name you don't recognise, search it on Google alongside "bad pool caller", you'll usually find known conflicts immediately. If WinDbg reports nt!ExFreePoolWithTag or nt!ExAllocatePoolWithTag as the crashing function, that's the kernel's pool manager itself being called with bad parameters, almost always a driver passing garbage.
Write down whatever driver name you find. You'll need it for the next steps.
Even if Windows installed a vendor driver automatically, you can force it to use the stable, Microsoft-signed inbox UAS or USB Mass Storage driver instead. This is often enough to stop the Bad Pool Caller BSOD entirely while keeping the adapter functional.
Open Device Manager (right-click Start > Device Manager). With the adapter plugged in, expand Disk drives and find your SSD listed there. Right-click it and choose Update driver. On the next screen, choose "Browse my computer for drivers", then "Let me pick from a list of available drivers on my computer."
Uncheck the Show compatible hardware box. From the manufacturer list on the left, select Microsoft. On the right, you'll see options like USB Attached SCSI (UAS) Mass Storage Device and USB Mass Storage Device. Select USB Mass Storage Device, it's the older, more conservative driver and almost universally stable. Click Next and let it install.
Alternatively, if you suspect the UAS (USB Attached SCSI) protocol itself is causing the pool corruption, which does happen with certain adapter chipsets, you can disable UAS entirely for that device via PowerShell. Run PowerShell as Administrator and type:
$device = Get-PnpDevice | Where-Object {$_.FriendlyName -like "*UAS*" -or $_.FriendlyName -like "*SCSI*"}
$device | Disable-PnpDevice -Confirm:$falseReboot. The adapter will re-enumerate under the standard USB Mass Storage driver. You'll see a slight speed reduction but rock-solid stability, and for a diagnostic drive, that's exactly what you want.
If Device Manager shows the adapter worked before the BSOD and now shows an error code, look for Code 10 (device can't start) or Code 43 (driver reported failure). Both confirm a driver-level problem, not a hardware failure of the SSD itself.
You mentioned RAM as one of your two hardware suspicions, and you're right to include it. BAD_POOL_CALLER can absolutely be triggered by faulty RAM. If a memory cell returns a corrupted bit mid-operation while the pool allocator is writing a header, you get exactly this stop code. It's more common than people think, especially on systems with XMP/EXPO profiles enabled.
Start with the built-in Windows Memory Diagnostic. Press Win + R, type mdsched.exe, hit Enter. Choose "Restart now and check for problems." The machine will reboot into the diagnostic environment and run two passes by default. This takes 10–20 minutes depending on how much RAM you have.
When Windows restarts, the results appear in Event Viewer under Windows Logs > System, Event Source: MemoryDiagnostics-Results, Event ID 1201. If it reports errors, you have a bad RAM stick or a failing slot.
For a more thorough test, I strongly recommend MemTest86 (free from memtest86.com). Boot from a USB drive with MemTest86 and run at least two full passes, ideally overnight. The on-board diagnostic misses intermittent errors that MemTest86 catches. Pay attention to errors in the first 2GB of address space, as that's where the Windows non-paged pool lives and where Bad Pool Caller errors originate.
If you have two RAM sticks, pull one out and test each individually in your primary slot (usually Slot A2, check your motherboard manual). I've caught countless bad sticks that only failed when paired, not solo. If MemTest86 gives you a clean bill of health across both sticks individually and together, RAM is not your problem and you can move on.
Your third suspected cause, a software issue, often manifests as corrupted Windows system files. The storage driver stack (ntfs.sys, storport.sys, classpnp.sys) is part of the operating system, and if any of those files got corrupted by a bad shutdown, a failed update, or even a previous BSOD, subsequent crashes become self-reinforcing. SFC and DISM can fix this without reinstalling Windows.
Open Command Prompt as Administrator (right-click Start > Terminal (Admin) or search for "cmd" and run as administrator). Run DISM first, it repairs the Windows Component Store that SFC pulls from. If you run SFC first and the Component Store itself is corrupted, SFC just restores broken files from broken sources.
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealthThe RestoreHealth command contacts Windows Update to download clean replacement files. It takes 10–20 minutes. Don't close the window. Once it completes with "The operation completed successfully," run SFC:
sfc /scannowIf SFC reports "Windows Resource Protection found corrupt files and successfully repaired them," you've just fixed a contributor to your Bad Pool Caller BSOD. The detailed log of what was repaired lives at C:\Windows\Logs\CBS\CBS.log, search for the word "repair" to see the actual files that were touched.
If SFC reports it couldn't repair some files, run the DISM RestoreHealth again and then re-run SFC. Sometimes one pass isn't enough. If files remain unrepaired after two rounds, note the specific filenames from CBS.log, they'll point you toward which subsystem is affected.
If the minidump from Step 1 named a specific driver, or if you suspect Windows Update silently pushed a bad driver update around the time the BSODs started, this step addresses it directly. You can check exactly what Windows Update installed and when by running this PowerShell command as Administrator:
Get-WinEvent -LogName "Microsoft-Windows-Diagnostics-Performance/Operational" | Where-Object {$_.Id -eq 103} | Select-Object TimeCreated, Message | Format-ListAlso check Windows Update history: go to Settings > Windows Update > Update History. Look at the Driver Updates section. If you see a driver that updated within a day or two of your first BSOD, that's a prime suspect.
To roll back a driver in Device Manager: right-click the device > Properties > Driver tab > Roll Back Driver. If the button is greyed out, Windows didn't keep the previous version, you'll need to uninstall the driver completely and install an older version manually from the manufacturer's website.
To prevent Windows Update from automatically reinstalling a problematic driver, download and run Microsoft's Show or Hide Updates troubleshooter (wushowhide.diagcab, it's still available from Microsoft's support site). It lets you hide specific driver updates so Windows Update won't push them again.
If you want to block a specific driver update via Group Policy instead, open gpedit.msc, navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Update, and enable "Do not include drivers with Windows Updates." This is a permanent block, use it only if you're confident the driver in question is the culprit.
After rolling back or reinstalling, reboot and monitor for 24 hours before concluding the fix worked. Bad Pool Caller BSODs can be intermittent, one clean boot isn't enough to declare victory.
Advanced Troubleshooting
If the steps above haven't resolved your Bad Pool Caller BSOD, we need to go deeper. This section covers kernel debugger analysis, registry-level driver disablement, Group Policy for enterprise machines, and what to look for in Event Viewer's more obscure logs.
Reading the full kernel dump instead of minidump. If your system is configured to write only small memory dumps, you may not have enough data to identify the culprit. Change this: go to Settings > System > About > Advanced system settings (or search "View advanced system settings"). Under Startup and Recovery, click Settings. Change the Write debugging information dropdown from "Small memory dump" to "Kernel memory dump." The file will be written to %SystemRoot%\MEMORY.DMP on the next crash. This gives WinDbg's !analyze -v much more context to work with, including the full driver call stack at the time of crash.
Using the Pool Tag to identify the offending driver. When WinDbg shows BAD_POOL_CALLER, look in the analysis output for the POOL_ADDRESS and POOL_TAG_FOUND fields. Pool tags are four-character identifiers that every kernel driver registers when it allocates memory. Run this in WinDbg:
!poolfind [POOL_TAG_HERE]This searches the pool for all allocations with that tag and often directly names the module. Cross-reference the tag using the pooltag.txt file located at C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\triage\pooltag.txt if you have the Windows Driver Kit installed.
Event Viewer deep dive. Beyond the standard System and Application logs, check Applications and Services Logs > Microsoft > Windows > Kernel-PnP > Device Configuration. Event IDs 400 and 410 show device installation events. Cross-reference the timestamps with your first BSOD timestamp from Event ID 1001 in the Application log. If a device installed within minutes of the first crash, that's your hardware culprit confirmed.
Domain-joined / enterprise machines. If this PC is on a corporate domain, Group Policy may be automatically deploying drivers or enforcing Windows Update settings that brought in a bad driver. Run gpresult /h C:\gpresult.html in an elevated command prompt and open the resulting HTML file. Look under Computer Configuration > Windows Settings > Software Installation and Administrative Templates > System > Device Installation for policies that might be forcing driver installs.
Third-party antivirus as a hidden cause. Antivirus products inject kernel drivers that hook the storage stack. Products like Kaspersky (klhk.sys), Malwarebytes (mbamswissarmy.sys), and older versions of Norton have documented pool corruption issues. If you added the USB drive adapter and your AV immediately scanned it, that scan can trigger a race condition in the AV's kernel driver. Try booting in Safe Mode (hold Shift at restart > Troubleshoot > Advanced options > Startup Settings > Enable Safe Mode with Networking) and using the machine with the adapter attached. Safe Mode loads only Microsoft-signed drivers, so if it's stable there, a third-party kernel driver is the cause.
Check for overheating under new load. Adding a powered USB device can slightly increase CPU and chipset temperatures, especially on laptops. If your system was already running warm, this might be enough to tip it over. Download HWiNFO64 (free) and watch the CPU Package temperature and NVMe/SSD temperatures under load. If CPU hits 95°C or your SSD hits 70°C+, thermal throttling and potential hardware errors can cause pool corruption.
nt!KiSystemCall64 or hal.dll, you may be dealing with a hardware-level memory controller issue or a deeply corrupted Windows installation that needs in-place repair or a clean install. At that point, consider reaching out to Microsoft Support directly. Have your WinDbg output and Event Viewer exports ready, that dramatically speeds up their triage process.
Prevention & Best Practices
Once you've got the Bad Pool Caller BSOD under control, here's how to make sure it doesn't come back, and how to protect yourself if it ever does.
Buy quality USB-to-SATA adapters. I know this sounds basic, but the $8 no-name adapters on Amazon use bargain-bin chipsets with minimal Windows driver testing. The ASMedia ASM1153E and ASM235CM chipsets have solid Windows driver support and rarely cause pool issues. The JMicron JMS578 is hit-or-miss. Avoid anything that ships with a driver CD dated before 2020, the drivers are usually unsigned or incompatible with modern Windows kernel security requirements.
Configure crash dump settings proactively. Don't wait for a BSOD to discover your machine was set to write no dumps at all. Right now, go to Advanced System Settings > Startup and Recovery > Settings and confirm "Kernel memory dump" is selected and the path is set to %SystemRoot%\MEMORY.DMP. Also check that Automatically restart is checked, without it, some machines sit at the blue screen indefinitely instead of rebooting.
Keep a System Restore point before any hardware additions. Before plugging in any new device, create a restore point manually: search for "Create a restore point" in Start, click Create, name it something like "Before USB SSD adapter." If a driver installation goes wrong, you can roll back everything in under five minutes.
Monitor your Event Viewer weekly. Windows ships with a tool called Reliability Monitor (search for it in Start) that gives you a daily timeline of application crashes, hardware failures, and system warnings without requiring you to understand raw Event Viewer logs. Make it a habit to check it weekly. You'll often see warning signs, like intermittent hardware errors, days before a BSOD actually occurs.
Keep driver installations controlled. By default, Windows Update can push driver updates automatically. For a stable production machine, go to Settings > Windows Update > Advanced Options > Optional Updates and review driver updates before accepting them. Never let Windows auto-install a driver for critical components, storage controllers, GPU, network adapters, without checking if there are known issues with that version first.
- Always cold-boot (Shift + Shut Down) after installing any new USB storage device before trusting it's stable
- Stick to ASMedia or Realtek chipset USB-to-SATA adapters, they have the most mature Windows driver support
- Enable kernel memory dumps before you need them, not after the crash that matters
- Run MemTest86 for at least one full pass any time you experience a pool-related BSOD, even if RAM wasn't your first suspect
Frequently Asked Questions
Why did my Bad Pool Caller BSOD start right after I plugged in a USB to SATA adapter?
When Windows detects new USB storage hardware, it automatically installs a driver for it, often without asking you. If that driver has a memory management bug, or if it conflicts with an existing storage driver already loaded in your kernel, it can corrupt the Windows memory pool and trigger stop code 0x000000C2 immediately. The fix is usually forcing Windows to use its own inbox USB Mass Storage driver instead of the vendor's. Disconnect the adapter, uninstall the driver through Device Manager (View > Show Hidden Devices), reconnect, and then manually select the Microsoft driver when it re-installs. That solves the problem in the majority of cases I've handled.
How do I read a minidump file without installing WinDbg?
The easiest alternative is NirSoft BlueScreenView, it's free, portable (no install needed), and automatically reads all minidumps from C:\Windows\Minidump\ when you open it. It shows the crashing driver, the stop code, and the call stack in a simple table. It won't give you the full kernel debugger depth of WinDbg, but for identifying the problem driver it's usually more than enough. Look at the "Caused By Driver" column, that's your primary suspect. For deeper analysis you do need WinDbg, which is available free from the Microsoft Store as WinDbg Preview.
Can Bad Pool Caller BSOD damage my SSD or hard drive?
The BSOD itself doesn't cause physical drive damage, it's a memory error, not a storage error. However, a sudden unclean shutdown (which is what a BSOD is) can leave the NTFS file system in an inconsistent state. Windows usually repairs this automatically on the next boot with CHKDSK, but if BSODs are happening repeatedly, you should run chkdsk C: /f /r from an elevated command prompt and let it complete on restart to verify your drive's file system is intact. If you're seeing Bad Pool Caller and the affected drive is the one you just attached via USB, the SSD itself is almost certainly fine, the issue is almost always the adapter driver, not the drive.
My Event Viewer shows Event ID 41 Kernel-Power, is that the cause of my BSOD?
Event ID 41 with Reason: 0 (BugcheckCode not zero) is a consequence of the BSOD, not the cause. It gets logged whenever Windows restarts unexpectedly without completing a clean shutdown, which is exactly what happens during any blue screen. What you really want to look at is Event ID 1001 (BugCheck) in Windows Logs > Application, which will contain the actual stop code in hexadecimal. Paste that stop code (e.g., 0x000000C2) into a search along with any parameter values listed, those parameters encode information about which pool was corrupted and where the bad allocation came from.
Will reinstalling Windows fix Bad Pool Caller for good?
A clean install will fix it if the cause is a corrupted Windows system file or a deeply embedded bad driver, but it's overkill for most Bad Pool Caller situations, and it won't fix hardware problems at all. If your RAM is faulty, a fresh Windows install will BSOD again on the same stop code within days. If the USB adapter driver is incompatible, Windows will re-install the same bad driver automatically on the clean install when you plug the adapter back in. Before going to a clean install, exhaust the diagnostic steps above, particularly the minidump analysis and RAM testing. In my experience, less than 15% of Bad Pool Caller cases actually need a full reinstall.
I'm getting Bad Pool Caller even in Safe Mode, what does that mean?
Safe Mode loads only the core Microsoft-signed drivers that Windows needs to boot. If you're still crashing there, the pool corruption is happening in a fundamental system driver, which strongly suggests either faulty RAM or a corrupted Windows kernel file. Run MemTest86 immediately (at least one full pass, two overnight). If RAM passes clean, run DISM RestoreHealth and SFC as described in Step 4, then check if any core system files were repaired. If the BSOD persists even after SFC shows a clean result, you're likely looking at a hardware-level memory controller issue on the motherboard, and at that point I'd genuinely recommend calling Microsoft Support or consulting a hardware repair specialist.