Bart vs. BAD_POOL_CALLER

BAD_POOL_CALLER is one of those scary STOP errors that one may see in XP (that is, once you kill the duhfault "restart on system errors" setting) . This particular case was an XP SP2 system that was said to crash straight into this on startup.

Uneventful 12 hours in MemTest86 with no sponaneous lockups or booting of the Bart CDR I left in place during the test, motherboard caps OK. Bart CDR boot, HD Tune passes SMART, temperature and surface on both hard drives, file systems OK on ChkDsk all volumes.

Formal malware scans fine, until the first test that requires RunScanner to access the registry hives on the hard drive. As soon as I click RunScanner's dialog OK, the system STOPs.

Riiiight... next, I harvest spare registry hives from SR Restore Points in the C:\SVI subtree. Then I pick a trivial scanner that I've set to run via RunScanner; in this case, Stinger. It doesn't matter what it is; all I want to test-to-fix is whether I can initiate registry access to the hard drive hives. If that no longer dies, I may have fixed the problem.

I run Stinger in this way, each time choosing a different user account and not checking the "use all hives" checkbox in the RunScanner dialog box. Ever user account is fine except the one they actually use, which dies the blue death.

Now that I've narrowed it down to a single file, I rename away that user account's NTUSER.DAT (which is the per-user registry hive), copy in the most recent spare from the most recent Restore Point, rename that into action as NTUSER.DAT, and re-test; this time it works as well as the other accounts did.

I'm interested in a single hive causing this common head-scratching problem, so I keep the "bad" and "fixed" copies of the hive, which appear to be the same length. I'll FC them to see if there's some specific difference (either structural, or a recent install... tho I'd expect the latter to change the file length) that causes the problem, and update this article if that looks interesting.

Meantime, Bart has saved the day yet again; what could so easily been "just" wipe and re-install, turned out to be a few unattended hours on "the prelim" plus around one hour of interactive work in Bart. Did I mention I liked Bart?

That drill-down method again...

• check RAM and hardware first
• Boot into Bart CDR
• use a tool via RunScanner
• choose one user account at a time
• if all break, suspect a system hive (common to all accounts)
• if only one account breaks, it's that account's hive
• preserve damaged hive by renaming away, not delete
• harvest replacement hives from recent Restore Points
• try with newset, then second-newest etc.
• do not try any of the above in hard-drive-booted Windows
  
• compare bad and good copies of the hive for differences

There are probably scores of reasons to STOP on BAD_POOL_CALLER, and many of these may have no pattern if the underlying hardware level of abstraction is bad (as is often the case with registry damage). Even so, if you have a consistent STOP on every boot, at the same point in the boot, then this approach may find the solution if your case is like this one.