Failures & Dead Ends

Why Document Failures?

Success stories are everywhere. Failure post-mortems are rare. But failures teach more than victories—they show the edges of what's possible and the assumptions that break under pressure.

This is a candid account of approaches that didn't work, debugging rabbit holes, and hard lessons learned the expensive way.

The File-Watching Vaporware

What Went Wrong

• FileSystemWatcher is unreliable on Windows—events missed under load
• Polling introduces latency and CPU waste
• Race conditions when multiple writes happen quickly
• No delivery confirmation—messages lost silently
• Cross-subsystem (Windows ↔ WSL2) file watching is even worse

Weeks spent debugging phantom missed events. The watcher would work for hours, then silently stop firing. No errors. No warnings. Just... nothing.

SendMessage Desktop Freeze

The Cause

Raw SendMessage() calls to a window that's not responding. SendMessage is synchronous—it blocks until the target processes the message. If the target is hung, the sender hangs. If the sender is the UI thread, the whole desktop hangs.

// NEVER DO THIS:
SendMessage(hwnd, WM_COPYDATA, ...)  // Blocks forever if target is hung

// ALWAYS DO THIS:
SendMessageTimeoutW(hwnd, WM_COPYDATA, ..., 
    SMTO_ABORTIFHUNG, 1000, &result)  // Times out after 1 second
        

KALIC's Goldfish Memory

Failed Approaches

• Single memory file - Grew too large, token expensive to load
• "Just remember" - Context windows reset. Discipline doesn't persist.
• Conversation history - Too verbose, mostly noise

The core issue: relying on the agent to check its own memory without enforcement.

.NET MCP Configuration Hell

Specific Issues

• Logging pollution - .NET logging writes to stdout, corrupts JSON-RPC
• Runtime mismatches - .NET 6 vs 7 vs 8, SDK versions
• NuGet cache - Old packages cached, wrong versions loaded
• Path differences - Different users, different drive letters

// The magic incantation to silence .NET logging:
Environment.SetEnvironmentVariable("Logging__LogLevel__Default", "None");

// But this only works if set BEFORE any logging initialization...
        

Battle.net TCP Deadlock

The Investigation

Network analysis with SigCon6 revealed TCP connections in FIN_WAIT_1 state—the localhost connection between Agent.exe and Setup.exe. Agent sends FIN, Setup never receives it. Connection hangs forever.

Cause: Windows Defender's network inspection was interfering with localhost traffic in specific edge cases. Disabling real-time protection allowed the install to complete.

Defender Flagging Itself

The Loop

1. Defender blocked from cloud (firewall)
2. Sets DisableBlockAtFirstSeen=1 (offline fallback)
3. Downloads new signatures (different endpoint)
4. New signatures flag DisableBlockAtFirstSeen=1 as malware
5. Defender detects its own registry write
6. Resets to 0, tries cloud, blocked, sets to 1...
7. Infinite loop
        

Microsoft shipped a signature to protect Defender from Defender's own offline-mode behavior.

Electron ControlSend Failures

Electron's Chromium renderer handles input differently than native Windows controls. The window hierarchy is unusual, focus management is async, and input events get swallowed.

Lessons Learned

1. Reliability Over Features

A tool that works 99% of the time is worse than one that works 100% of the time. That 1% failure rate means you can never fully trust it.

2. Enforcement Over Discipline

Don't rely on remembering to check. Build systems that force the check. Hooks, pre-commit scripts, automated gates.

3. Document the Weird Stuff

Edge cases that took hours to debug will happen again. Write them down. Create PhiSHRI doors. Future you will thank past you.

4. Rewrite When Fixing Isn't Enough

Some architectures are fundamentally broken. No amount of patching fixes bad foundations. Sometimes starting over is faster than continuing to debug.

5. Test the Failure Modes

Happy paths are easy. What happens when the network is down? When the target process is hung? When the disk is full? Test those.