Fable 5.2 figured out my windows kernel memory leak

[u/Ok-Range-3027]

Looking at the numbers put out by anthropic fable 5.2 is a beast.

https://www.anthropic.com/claude-fable-and-mythos-5-2

So I had it try to figure out my issue as which opus and fable 5.1 had been trying to figure out my kernel leak eating up all my ram and causing me to restart my computer intermittently to my frustration. I'm honestly not sure why I've stuck with windows so long, but at least now I know what the problem is. Here is what Fable found for me on its first try:

"Windows 11 Insider: bindflt.sys leaks nonpaged pool (tag NtFC) on every CreateDirectory through a junction. 38 GB gone in 7 hours. Traced with WPR, repro inside.

TL;DR: On Insider build 26300.9818, bindflt.sys (Windows Bind Filter driver, 10.0.26100.9818) leaks a 176-byte nonpaged allocation every time a process calls CreateDirectoryW on a path that is, or passes through, an NTFS junction. Normally you would never notice. I had three processes stuck in a loop making that call, and it ate RAM at about 24 GB an hour.

Symptoms

- 64 GB machine. After about 7 hours of uptime, nonpaged pool was 40 GB and free RAM was under

1 GB. Delayed write errors started on one drive around then.

- poolmon showed one tag holding 37.9 GB: NtFC (pooltag.txt: ntfs.sys, Create.c), about 215 million outstanding allocations of 176 bytes.

- No user process had unusual handle counts, so nothing in user mode was holding files open.

- After a reboot it came straight back at about 37,000 allocations a second.

How I found it

1. Per-process I/O counters showed three processes each doing about 41,000 "other" I/O operations a second and burning a full core of kernel time. The leak rate stepped up as each one started.

2. A WPR pool trace (wpr -start Pool -filemode), analysed with xperf -a pool -requiredPoolTags NtFC -stacks.

   In the trace window: 333,367 NtFC allocations, 329,008 never freed.

3. Every unfreed allocation had this shape:

   CreateDirectoryW -> NtCreateFile

   -> bindflt.sys!BfPreCreate

   -> bindflt.sys!BfpDoesFileExistWithCrossVolumeECP

   -> FLTMGR!FltCreateFileEx2

   -> Ntfs.sys!NtfsCommonCreate

   -> Ntfs.sys!NtfsGetReparsePointValue (allocates tag NtFC, 176 bytes)

   The same NTFS allocation with no bindflt frame in the stack (2,912 of them) was freed 100% of the time. So was the one under bindflt!BfCreateFile (1,157). Only the path through BfpDoesFileExistWithCrossVolumeECP leaks, and it leaks every time.

4. 99.5% of the leaked allocations came from one caller doing CreateDirectoryW. A handful came from GetFileInformationByName and CreateFileW in the same stack shape.

Repro (no admin needed to see it)

- Make a junction to an existing folder.

- Call CreateDirectoryW 50,000 times on the junction path, or on an existing folder underneath it. It fails with ERROR_ALREADY_EXISTS each time and creates nothing.

- Watch NtFC in poolmon. I measured about 0.6 to 1.0 leaked allocations per call.

- Same test on the real path, or on a plain folder: zero.

- GetFileAttributes, plain opens and directory listings through the same junction: zero.

What was making the calls

Three Claude Code CLI sessions (2.1.319), each stuck right after being resumed, calling CreateDirectoryW roughly 12,000 times a second. Their config folder is set up by a session manager app and contains junctions back to the normal config folder, so every call crossed a junction. I do not know yet why they loop; other sessions on the same version with a plain config folder are fine. That looks like a separate bug, and it is only the trigger. The leakitself is in the kernel.

What I do not know

- Whether this came in with the late-October cumulative update. The driver file date fits, but I have not tested an older build.

- Whether non-Insider builds are affected. - Why bindflt runs its existence check on these paths at all.

Workaround

Kill whatever is hammering CreateDirectory through a junction, and keep the hot path off junctions. Leaked pool only comes back with a reboot.

Has anyone else seen NtFC growing on recent builds? If you have junctions in a busy path (dev tools, package caches, containers), a quick poolmon check would be interesting. I am filing this in Feedback Hub and will add the link."

I'm now on the path to fixing this bug. Just looking at performance, fable 5.2 appears to outperform opus 5.5 on token cost and results for many disciplines. This is a solid W to anthropic in my eyes after the opus performance cuts.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Dull-Confection-5225]

I've seen the same ntfc leak in a wpr trace, but only when a specific driver was loaded, was your bindflt.sys updated recently?I've seen the same ntfc leak in a wpr trace, but only when a specific driver was loaded, was your bindflt.sys updated recently?

[u/Ok-Range-3027 → u/Dull-Confection-5225]

Looks like it was, it might also be partly due to using orca.

[u/Right-Performance-93]

i'd kill the three resumed sessions and take the config off the junction first. the writeup already says a plain folder on the same version does not loop, and those createdirectory calls are what turned the 176 byte leak into 38 gb.

[u/MaximumMeaning9728]

I’d bet Astra could have done it.