svnscha - general

Introducing Native Windows Debugging for VS Code: Kernel & Remote Debugging

2026-06-07T00:00:00+00:00

Remember the Cliffhanger?

A while back I wrote about the joy of writing a debugger adapter for Visual Studio Code. It started with a simple wish - I just wanted a faster way to remote-debug a service running in a VM - and ended with a working proof of concept: VS Code driving WinDbg through a custom Debug Adapter Protocol implementation.

But that post ended on an honest note:

I have not implemented remote debugging or kernel debugging yet, but I now feel ready to take a real shot at both without getting lost in the basics again.

Well. I took the shot.

Remote debugging works. Kernel debugging works. And the whole thing is now a real, installable VS Code extension: Native Windows Debugging (dbgeng).

Debug native Windows code - C and C++ programs, services, and even the Windows kernel - straight from Visual Studio Code, using the same engine that powers WinDbg.

That's the whole pitch in under two minutes. Now let me show you what's behind it.

Get It Right Now

No waiting, no building from source:

Marketplace: Native Windows Debugging (dbgeng)
Source: github.com/svnscha/dap-dbgeng (MIT licensed)
Docs: svnscha.github.io/dap-dbgeng

The adapter is bundled inside the extension, so there's nothing separate to build, download, or point at. Install it, write a launch.json, press F5. That's it.

Four Ways to Debug - Two of Them Were Never Possible Before

VS Code has always had great local debugging for plenty of languages. But the moment you wanted native Windows remote or kernel debugging, you hit a wall. That stack lives in Visual Studio and WinDbg, not in VS Code - because of course it does.

This extension closes exactly that gap. One adapter, four scenarios:

Local - the debugger starts your program and debugs it from launch.
Attach - connect to a process that's already running, by its PID.
Remote - debug a user-mode process on another machine via dbgsrv.
Kernel - debug kernel-mode drivers and the OS around them.

The first two are the comfortable ones. The last two are the gap I set out to close. Let's walk through them.

Local: The Comfortable Starting Point

Start simple. The debugger launches your program and you step through it like any other debugger in VS Code. It's just a launch.json:

{
  "name": "Debug myapp",
  "type": "dbgeng",
  "request": "launch",
  "program": "${workspaceFolder}/build/Debug/myapp.exe",
  "stopAtEntry": true
}

program is the only thing you really have to provide. dbgeng.dll is found automatically from your installed Windows SDK, so you usually don't even set a path. Set a breakpoint, press F5, and you get the full loop: continue, step over, step into, step out, call stack, locals, watch expressions, and a Debug Console that evaluates expressions through the real engine.

If you use the CMake Tools extension, you can even drop the program line entirely - the adapter defaults to your selected CMake launch target. Point CMake's debug command at the dbgeng type and CMake: Debug just works.

Attach: Already Running? Just Connect

Sometimes the process is already alive and you don't want to restart it. Attach to it by its process ID:

{
  "name": "Attach to myapp",
  "type": "dbgeng",
  "request": "attach",
  "processId": 12345
}

Don't know the PID off the top of your head? Set "processId": "${command:dap-dbgeng.pickProcess}" and you get a process picker at debug time. Same familiar VS Code interface, with the real Windows debug engine underneath.

Remote: My Favorite Part

This was the first scenario I implemented: debugging a user-mode process on another machine while keeping the debug engine and symbols on the local system.

The trick is the Windows process server, dbgsrv. You run it on the target, and your machine connects to it over TCP (or a named pipe).

On the target, start the process server:

dbgsrv -t tcp:port=5005

On your machine, point a launch.json at it:

{
  "name": "Attach on TARGETPC",
  "type": "dbgeng",
  "request": "attach",
  "processId": "${command:dap-dbgeng.pickProcess}",
  "connectionString": "tcp:port=5005,server=TARGETPC"
}

Press F5, pick the remote process from the list (the picker now shows processes on the dbgsrv host), and you're debugging it remotely. The engine and symbols never leave your machine - only the debuggee lives on the other side.

This is precisely the workflow I wanted at the very beginning: compile locally, deploy to the VM, attach, get back to work. Now it's a one-keystroke thing.

Kernel: Yes, Really

And then there's the big one. Kernel-mode debugging from VS Code.

Kernel debugging is whole-machine, so you need two boxes: a host (VS Code + the adapter) and a target being debugged - almost always a throwaway VM, because kernel debugging halts the entire target at breakpoints.

On the target, enable kernel debugging and reboot:

bcdedit /debug on
bcdedit /dbgsettings net hostip:<HOST-IP> port:50005 key:1.2.3.4

On the host, point a kernel config at it:

{
  "name": "Debug driver (KDNET)",
  "type": "dbgeng",
  "request": "attach",
  "kernel": true,
  "connectionString": "net:port=50005,key=1.2.3.4"
}

kernel: true flips the adapter into kernel mode and turns connectionString into a kernel transport. There's no processId here - the session is the whole machine. Press F5, it connects over KDNET, and breaks at DriverEntry. From the same editor people keep telling me is "just a text editor."

Kernel debugging. Just another breakpoint. That still feels a little unreal to type.

KDNET isn't the only option, either - the same connectionString field speaks serial (named pipe), 1394, and USB transports too. Whatever your VM or test box gives you.

How It Works

A few things changed since the proof of concept, and they're worth a mention.

It talks to the engine natively. The adapter uses the real DbgEng APIs throughout - IDebugClient, IDebugControl, IDebugSymbols, IDebugSystemObjects, with IDebugEventCallbacks and IDebugOutputCallbacks for events. No fragile text-scraping of WinDbg console output. When the engine knows something, the adapter asks it directly.

The protocol layer is still generated. That code-generation step I was so happy about last time paid off again. src/protocol/ is generated from the official DAP schema, so every request, response, and event stays in lockstep with the spec instead of drifting from hand-written DTOs.

The POC grew up - and changed language. The original proof of concept was C#. Hardening it into something I'd actually ship meant rebuilding the adapter in C++20 (CMake + Ninja, vcpkg manifest mode), sitting much closer to the engine it wraps. That was part of the "harden the rough edges" plan, and it made the kernel and remote work far less painful.

It records itself. There's a built-in session-trace recorder that doubles as the project's replay-test format. Recorded sessions get replayed against real test debuggees in CI, so the behaviors you see in those videos are the same behaviors the test suite asserts on.

An Honest Word on Scope

I'm keeping the same promise I made in the first post: the adapter advertises only what it implements correctly, rather than dangling buttons that misbehave.

What works today: line and conditional breakpoints, step over/into/out, continue, pause, instruction-level stepping in the disassembly view, call stack with delayed frame loading, variables and scopes (including registers), set-variable, expression evaluation in the Watch pane and Debug Console, disassembly view, and clean terminate/disconnect.

What's planned but not advertised yet: function breakpoints, data breakpoints (watchpoints), hit-conditional breakpoints, logpoints, read/write memory, a modules view, evaluate-on-hover, and hex formatting toggles. The engine can do all of these - the adapter just doesn't expose them yet. The features reference keeps the full, deliberately conservative list.

And here's the escape hatch: anything the UI doesn't surface, you can usually still do by typing native debugger commands straight into the Debug Console. It's the real engine - it'll answer.

Getting Started

If you want to try it, the whole loop is about ten minutes:

Install Native Windows Debugging (dbgeng) from the Marketplace.
Make sure you have Debugging Tools for Windows (it ships dbgeng.dll, via the Windows SDK or WDK installer). The adapter finds it automatically.
Drop a dbgeng configuration into .vscode/launch.json - pick the scenario from above.
Set a breakpoint, press F5.

The Getting Started guide walks through it in detail, and each scenario has its own page in the docs.

Your Turn

This is open source, and it's at the stage where real-world usage is the most valuable thing it can get. So:

⭐ Star it on GitHub if it's useful to you.
🐛 Report a bug through the issue tracker - the templates tell you what to include.
🔧 Contribute if you're into native Windows debugging internals; see CONTRIBUTING.md.

Summary

Last time I closed with "I just want to remote debug a service on a VM." That was the entire ambition.

It turned into DAP, a code generator, a dbgeng wrapper, a pile of state-machine bugs - and now remote debugging, kernel debugging, a published extension, and a documentation site.

The gap between "VS Code can't do native Windows kernel and remote debugging" and "actually, now it can" is closed. With the same engine that powers WinDbg, sitting quietly behind the editor you already use every day.

And yes - it still started with "I just want to remote debug a service on a VM."

P.S. - One More Thing About Those Videos

While you're here: how did you actually like the videos? Be honest.

Because here's the fun part - this is the first time I generated end-to-end videos, all the way from Claude to YouTube. No editing suite, no timeline scrubbing, no manual voiceover takes. Just prompting and vibing until it looked right.

The stack, if you're curious:

Remotion for the video itself - everything you see is React, rendered to MP4. Code as video turns out to be a really nice fit for the "iterate fast" loop.
My DGX Spark doing the heavy lifting locally.
MOSS-TTS for the voice. And here's a little detour: I first deep-cloned my own voice. The result was genuinely impressive - but not quite perfect, and the "almost me" uncanny gap bugged me more than I expected. So I switched to a fully synthesized voice instead, and I was happier with that than with a not-quite-right clone of myself.

I think that's pretty cool. A little surreal, honestly. The same "describe what you want, iterate, ship" loop that built the debugger also produced the launch video for it.

So let me know what you think - of the extension and of the videos. What worked, what felt off, what you'd want next. There's no comment box here, so just hit me up (LinkedIn or GitHub) or open an issue. I'm genuinely curious.

The Joy of Writing a Debugger Adapter for Visual Studio Code

2026-04-15T00:00:00+00:00

Current State

Before I get into the story, here is the current result: Visual Studio Code debugging a C++ application with WinDbg under the hood through my first proof of concept integration.

Right now this is still an early POC, not a finished debugger experience. It proves the architecture works and that VS Code can drive WinDbg through a custom adapter, but it still needs a lot more iteration before I would call it really useful.

One detail I already like is that the debugger command window is not a fake simplified console. I can type regular WinDbg commands straight into it.

Why

Because I do what I always do when a workflow annoys me: I build a tool until the annoyance goes away.

This time the pain point was remote debugging a service application running inside a VM. My ideal flow was simple:

Compile locally
Deploy to the VM
Start or restart the service
Attach a debugger
Get back to work without ten minutes of clicking around

That sounded perfectly reasonable: a small helper extension for Visual Studio Code, a bit of automation, some launch configuration glue, and done.

That was the plan.

It did not stay the plan.

Removing Friction

I started with the pragmatic part first: automate the annoying steps.

I wired up a helper extension that could compile the service, copy the binaries to the VM, and prepare the remote machine for debugging. This is my favorite kind of productivity work, because the payoff is immediate. Every bit of friction you remove saves time again and again.

Once the plumbing was in place, I expected the final step to be easy: tell VS Code to remote debug the service and call it a day.

Instead, I hit a wall.

VS Code Is Not Visual Studio

At first glance, this feels like something that should already exist. Visual Studio has mature debugging capabilities. VS Code has debugging. Microsoft builds both. Surely there must be a supported path to do classic remote Windows debugging from VS Code, right?

Not really.

The more I dug into it, the clearer it became that the debugging stack in VS Code is a different world. VS Code speaks the Debug Adapter Protocol, or DAP. It expects debugger extensions to implement that protocol and sit between the editor and the actual debugger engine.

That part is good. DAP is a clean idea.

The frustrating bit was this: the specific native Windows remote-debugging flow I wanted was not available through a supported public route in VS Code. The Visual Studio native debugger stack is not something you can just plug into from your own VS Code extension and say, "Thanks, I will take remote debugging from here." And the VS Code side does not magically inherit Visual Studio's remote debugging capabilities just because both products come from Microsoft.

So after spending time exploring options, the conclusion was simple:

There was no supported way to get the workflow I wanted with the existing pieces.

Building It Anyway

Once I accepted that I would not be wiring together existing public APIs, the problem changed shape.

The question was no longer, "How do I enable remote debugging in VS Code?"

It became:

"What debugger engine can I control myself, and how do I make VS Code talk to it properly?"

That is where WinDbg entered the story.

WinDbg already knows how to do the important parts. User-mode debugging. Remote debugging. Kernel debugging. Crash dump analysis. It is a serious tool with decades of capability behind it.

But again, my tool of choice did not give me the VS Code experience I wanted out of the box.

So the next step was clear:

Build a debugger adapter for WinDbg.

Learning DAP

If you want to integrate a debugger with VS Code, DAP is the contract. Once I sat down and read it properly, a lot of things clicked.

The official home for it is the Debug Adapter Protocol website, and that site is worth bookmarking because it has both the overview and the actual specification. At the time I was working through this, the important mental model was simple: VS Code and the adapter exchange JSON messages with a very predictable shape, and the protocol defines what those messages are supposed to mean.

The protocol is straightforward. VS Code sends requests like initialize, launch, attach, setBreakpoints, stackTrace, variables, continue, next, and so on, and your adapter answers them while emitting events like initialized, stopped, continued, and terminated.

That sounds simple enough until you remember that a debugger is mostly state, timing, and edge cases.

Still, the protocol gave me exactly what I needed: a structured way to make VS Code think in terms of debugging, while I figured out how to translate that into WinDbg behavior.

This was the moment where the project stopped being a helper extension and became a real debugger adapter.

To make that a bit more concrete, a minimal launch payload for the current POC looks roughly like this:

The adapter currently points at the debugging engine directly, so the windbg setting names the WinDbg stack even though the configured path is dbgeng.dll rather than windbg.exe.

{
	"type": "dapwdbg",
	"request": "launch",
	"name": "Launch through WinDbg",
	"windbg": "C:/Program Files (x86)/Windows Kits/10/Debuggers/x64/dbgeng.dll",
	"program": "${workspaceFolder}/build/Debug/testapp.exe",
	"stopAtEntry": true
}

That stopAtEntry flag is a small but useful quality-of-life feature. I added it because it is a familiar debugger option and useful to have. By default it is false, so the adapter continues after configurationDone. If you set it to true, VS Code stays paused at entry and waits for the next command.

And on the wire, the messages are simple, which is exactly what you want from a protocol. A stop event coming back from the adapter looks roughly like this:

{
	"seq": 17,
	"type": "event",
	"event": "stopped",
	"body": {
		"reason": "entry",
		"description": "Paused at process entry.",
		"threadId": 1,
		"allThreadsStopped": true
	}
}

That might not look exciting, but it is the important part: once VS Code receives something in that shape at the right time, it knows how to show the stack, scopes, variables, and stepping UI around it.

Step 1: Parse the Schemas Instead of Hand-Writing Everything

One thing became obvious very quickly: I did not want to manually model the entire protocol by hand in C#.

That is the kind of task that feels fine for the first ten message types and becomes a waste of time by the next fifty.

DAP is defined by schemas. Machines should read schemas. Machines should generate code. Humans should not write all of that by hand.

So one of the first pieces I built was a small toolchain around the protocol definitions.

The idea was straightforward:

Parse the protocol schemas
Convert them into C# types
Use generated models for requests, responses, events, and payloads
Stop wasting time on repetitive plumbing

This bought me two things immediately:

Better consistency with the protocol
Faster iteration whenever I needed to expand coverage

It also reduced a whole category of annoying bugs where hand-written DTOs silently drift away from the spec.

That generator phase was not glamorous, but it kept paying off. Every time I added another request handler later, I was very happy not to be hand-authoring another stack of protocol classes.

The nice part is that the generated code stays very literal. For example, the generated LaunchRequest model is basically just a strongly typed wrapper around the DAP shape, with Command = "launch" baked in and a typed Arguments property. A generated event model like StoppedEvent then points at a generated StoppedEventBody class with fields such as Reason, Description, ThreadId, and AllThreadsStopped.

That is exactly the level of abstraction I wanted. The protocol layer should be boring and explicit so the interesting work can happen one layer above it.

Step 2: A Python Generator That Produces C#

Yes, the adapter is in C#.

Yes, I used Python to generate part of it.

That combination made sense for the job. Python is still one of the fastest ways to build a transformation tool, especially when the task is basically: read structured input, normalize it, and generate source code.

So I built a Python tool that parsed the protocol definitions and generated the corresponding C# code.

That generator handled the boring but important parts:

Request and response classes
Event payloads
Shared protocol types
Optional fields and enum-like shapes
Enough structure to keep serialization predictable

This turned out to be one of the highest leverage steps in the whole project. Instead of spending my time on protocol plumbing, I could focus on the parts that actually matter: session management, command execution, state transitions, and debugger behavior.

In other words, I automated the boring part so I could focus on the interesting part.

Step 3: Wrap WinDbg Through dbgeng

Once the protocol layer was under control, the next question was how to talk to the debugger engine itself.

For that I went with dbgeng, the Windows debugging engine behind the debugger family. That is where the real power is. It is also where some of the complexity is.

On the package side, the current codebase still reflects some iteration. The wrapper layer currently leans on the public DbgEng interop exposed through the ClrMD packages Microsoft.Diagnostics.Runtime and Microsoft.Diagnostics.Runtime.Utilities. Separately, the broader adapter codebase also references Microsoft.Debugging.Platform.DbgEng and Microsoft.Debugging.Platform.DbgX, which are part of the newer Microsoft debugging platform stack. That split is real in the code today, but I do not want to pretend it is already the final architecture.

In the wrapper itself, the core interfaces in use right now are IDebugClient, IDebugControl, IDebugSymbols, and IDebugSystemObjects. For callbacks, I register IDebugEventCallbacks and IDebugOutputCallbacks. That gives me the essential surface area I need to launch or attach, execute commands, inspect symbols, enumerate threads, and react to breakpoints, exceptions, exits, and debugger output.

This wrapper layer became the core of the adapter. Its job was to expose the debugger in a way that fit the expectations of DAP rather than the expectations of a human typing commands into a debugger console.

That means translating concepts like:

Launching or attaching to a target
Resuming and breaking execution
Enumerating threads
Building stack traces
Reading locals and variables
Handling modules and symbols
Surfacing exceptions, exits, and other stop reasons

If you have ever worked with debugger APIs, you know they do not hide much complexity. You need to be explicit. You need to think about ownership, state, timing, callbacks, and edge cases that often show up only once things are already going wrong.

One small example was line stepping. I had already enabled source line support and saw source locations show up, so for a moment I thought step over was working.

It did not.

What I had actually proven was that WinDbg could show me line information. That is not the same thing as telling it to do source-based stepping. I had forgotten to enable that part as well. The fix was one extra command:

public void EnableSourceLineSupport()
{
	ThrowIfDisposed();
	ExecuteDebuggerCommand(".lines -e", "Could not enable source line support");
	ExecuteDebuggerCommand("l+t", "Could not enable source-based stepping");
}

That was a very debugger-adapter kind of bug. Everything looked correct for just long enough to be misleading.

Step 4: Implement the Real Requests and Iterate

With the generated protocol types on one side and the WinDbg wrapper on the other, I could finally work on the adapter loop itself.

At this point, the adapter was useful for actual debugging.

I began with the core requests: initialize, launch, attach, setBreakpoints, configurationDone, threads, stackTrace, scopes, variables, continue, pause, next, stepIn, stepOut, disconnect, ...

On paper that looks like a clean checklist. In reality, each of those requests is a conversation between at least three parties:

VS Code and its expectations
The adapter and its internal state machine
The debugger engine and its current state

So the implementation loop looked roughly like this:

Add one request
Run it in VS Code
Watch it fail in an interesting way
Fix the translation layer
Hit the next state mismatch
Repeat until the experience works the way it should

This is also where you learn that "technically works" and "feels right to use" are not the same thing.

It is not enough to answer the request. You have to answer it in the right order, at the right time, and with enough fidelity that the editor can build a coherent UI around it.

That was one of the more interesting parts of the project.

Here is a tiny slice of what that translation layer looks like today. After launch, the adapter records whether it should remain paused at entry or continue once VS Code finishes sending its setup messages:

_launchAwaitingConfigurationDone = true;
_launchStopAtEntry = DapArgumentReader.TryGetBoolean(arguments, "stopAtEntry")
	?? DapArgumentReader.TryGetBoolean(arguments, "stopOnEntry")
	?? false;

This is the kind of code that looks harmless until you realize it decides whether the whole session feels smooth or broken.

When It Worked

At some point the pieces clicked together.

I could launch a debugging session from VS Code, talk to WinDbg through the adapter, and use the editor as if this had always been a normal supported workflow.

It also stopped being just about the original VM service scenario. Because the adapter sits on top of WinDbg, it opened the door to more than the first use case:

Local launch and local attach already work in the adapter
Dump-file attach is wired in
Remote attach and kernel scenarios are the next serious end-to-end targets
Crash dump debugging is now a realistic extension of the same architecture

That was the point where the project started to feel solid.

Why This Was Fun

This was fun for the same reason good tooling work is always fun: it changes how you work.

You remove friction once, then benefit from it every day after that. And along the way, you learn where the real product boundaries are. Visual Studio and VS Code may look adjacent from the outside, but their debugging plumbing is very different. Once that became clear, the path forward became clear too.

What I Learned

This project taught me a few things very clearly:

If a workflow matters enough, it is often worth productizing it for yourself
DAP is a really good abstraction for debugger integration
Code generation is the right answer when a protocol brings lots of repetitive structure
Debugger adapters are mostly about state, timing, and translation
WinDbg becomes much more approachable when you put a good UX in front of it

Also: if you think you fixed stepping, make sure you actually fixed it and did not just make the debugger show line numbers.

Most importantly, I was reminded again that some of the best side projects start as practical attempts to make tomorrow less annoying than today.

Summary

I only wanted a better remote debugging workflow for a service running in a VM.

That turned into DAP, schema parsing, code generation, dbgeng, and a long series of state-machine bugs.

The result so far is a working first proof of concept: a WinDbg-backed debugger adapter for Visual Studio Code with local launch, local attach, dump-file attach, stack traces, scopes, variables, breakpoints, and step commands working well enough to prove the architecture.

That matters because it means I finally have a base I can build on. I have not implemented remote debugging or kernel debugging yet, but I now feel ready to take a real shot at both without getting lost in the basics again.

Next Steps

The next step is to use this base for the work I actually set out to do:

Harden the current adapter and clean up rough edges in the state machine
Start implementing the actual remote debugging flow for the VM scenario
Take a first real implementation shot at kernel debugging too
Keep the scope under control so the project does not drift again like it did at the start
Open source the project once the foundation is stable enough
Keep turning WinDbg power into something that feels normal inside VS Code

And yes, this all started with "I just want to remote debug a service on a VM."

That is usually how the best tools start.

The Passenger Seat Developer

2025-10-27T00:00:00+00:00

The Great Prototype Experiment

Here's what nobody tells you about AI-assisted rapid prototyping: After six months and nearly 100 projects, I had to face an uncomfortable truth.

Every prototype feels like success. But is it really?

Why, You Ask?

Picture this: Me, armed with Claude, spinning up project after project like I'm some kind of coding machine gun. A productivity suite here, a file manager there, throw in some web scrapers, automation tools, data processors - you name it, I've probably built a prototype of it in the past six months.

Nearly 100 projects. The dopamine hits were insane. Every idea that popped into my head, no matter how half-baked, could become a working prototype in hours instead of weeks. The velocity felt otherworldly.

The result took me too long to acknowledge: out of nearly 100 prototypes, only one reached production.

One. Literally. One.

That project? mcp-windbg. And guess what made it special? It's the only one where I spent those classic, grinding hours sitting there, actually understanding every line of code, debugging the edge cases, and wrestling with the gnarly implementation details.

The Dopamine Factory

Let me be real with you about what those early days felt like. I'd wake up with some random idea - "What if I built a tool that automatically organizes screenshots by content?" or "I need a better way to manage my development environments" - and by lunch, I'd have a working prototype.

Six months ago, I was writing about vibe coding like I'd discovered fire. The euphoria was real - watching AI refactor entire codebases, generate complex implementations, solve architectural problems in seconds. I was living in that perfect state where "the barrier between thinking and implementing just got so much thinner."

Me: Build me a screenshot organizer that uses OCR to categorize images
Claude: *Generates Python app with OCR integration, file management, GUI*
Me: This actually works perfectly!

The rush was incredible. Idea to implementation in hours. No tedious boilerplate. No debugging mysterious dependency issues. No wrestling with documentation. Just pure, frictionless creation.

I felt like a goddamn wizard. Every prototype that worked felt like validation that I'd cracked some secret code of productivity. Friends would ask what I was working on, and I'd rattle off a dozen projects like I was running a software factory.

That euphoric beginning? It was exactly six months ago. Time has a funny way of providing perspective.

The Reality Check: Why Nothing Shipped

After several months, my project folder had grown to nearly 100 directories, but I still had not shipped anything.

Why? Because prototypes aren't products.

Every time I'd come back to one of these AI-generated prototypes to actually finish it - to handle edge cases, add proper error handling, write tests, or make it production-ready - I'd hit the same wall: I had no clue how the thing actually worked.

The code looked familiar. The structure made sense at first glance. But when it came time to:

Debug why it crashed with certain file types
Add a feature that required understanding the data flow
Optimize performance bottlenecks
Handle edge cases the AI hadn't considered

I was lost. Completely, utterly lost.

The One That Made It: mcp-windbg

So why did mcp-windbg succeed when 99 others failed? It wasn't because I spent months on it - it was a small weekend project. But I approached it differently.

I started by vibe-coding with Claude, just like the other prototypes. Got the basic structure working, had it generating and parsing WinDBG commands. But then - and this is the crucial difference - I actually went back and reviewed what the AI had built. Debugged the edge cases myself. Traced through the subprocess communication to understand how it really worked.

When pytest failures popped up, I didn't just ask Claude to fix them. I sat there and figured out why they were failing. When the CDB interaction got weird with certain commands, I debugged it manually until I understood the communication protocol.

The result? A weekend project that actually solved a real problem in my daily work. Something I could confidently maintain, extend, and explain to others.

I owned the code because I'd taken the time to understand what Claude had built.

The Brutal Truth About AI-Generated Prototypes

Those 99 failed projects weren't failures because the code was bad. Most of them actually worked pretty well for their basic use cases. They failed because I'd delegated understanding to AI instead of using it as a tool to support my understanding.

Here is what was happening:

Week 1: "Holy shit, look at this amazing prototype!"
Week 2: "I should probably clean this up and ship it"
Week 3: "Hmm, there are some edge cases I need to handle"
Week 4: "Why is this crashing? Let me ask Claude to fix it"
Week 5: "The fix broke something else. This is getting messy"
Week 6: "Maybe I'll just start a new project instead..."

Sound familiar? This cycle repeated so consistently I could set my calendar by it.

The Sitting-There Hours: Why They Matter

You know those classic hours every developer has experienced? The ones where you're just sitting there, staring at code, trying to figure out why something isn't working the way you expect? Those moments when you're debugging line by line, tracing execution paths, and slowly building up a mental model of how everything fits together?

Those hours aren't wasted time. They're investment time.

When you skip those hours - when you let AI generate the solution and just accept it - you never build that intimate knowledge of your own system. You become a tourist in your own codebase.

With mcp-windbg, I didn't spend weeks wrestling with it - it was just a weekend project. But during that weekend, when I hit issues with subprocess communication or weird CDB behavior, I actually debugged them myself instead of immediately asking Claude for fixes. I took the time to understand why certain commands failed and how the debugging session management worked.

That weekend of actually understanding what I was building made the difference between prototype #99 and shipped product #1.

The False Productivity Trap

I felt productive while building those 99 prototypes. Each working demo felt like progress, and my GitHub activity supported that impression. It did not mean I was finishing useful products.

But productivity isn't about how much code you generate. It's about how much value you ship. And by that metric, I had a 1% success rate.

The problem was not AI itself, but how I used it. I treated it as a replacement for understanding instead of a debugger or knowledge base that could help me learn faster.

How I Use AI Now

I still use AI regularly, but now I treat it like any other development tool.

AI as a knowledge base: "How does subprocess communication work in Python?" "What are the edge cases for file parsing?" "Show me different approaches to error handling."
AI as a debugging partner: "Here's my stack trace, what could be causing this?" "This function isn't behaving as expected, help me trace through the logic."
AI for the boring repetitive stuff: Boilerplate code, test scaffolding, documentation generation, refactoring patterns I've done a million times.
AI as a code reviewer: "Does this implementation handle edge cases properly?" "Are there performance issues with this approach?"

The key difference: I use AI to accelerate my understanding, not replace it.

For anything I might ship, the rule is simple: If I can't explain how the core functionality works without looking at the code, I don't ship it. AI can help me get there faster, but it can't get there for me.

This isn't about being a purist or rejecting AI assistance - it's about maintaining professional competence and shipping software you can actually support.

What Success Actually Looks Like

After six months of this experiment, here's what I've learned about successful AI-assisted development:

Delegate the repetitive stuff: Boilerplate generation, test scaffolding, documentation, refactoring patterns you've done before.
Use it as a knowledge multiplier: Research APIs, explore different approaches, get explanations of complex concepts, debug tricky issues.
Keep the understanding: Architecture decisions, core business logic, data flow design, system integration points.
Invest in the sitting-there hours: For anything you plan to ship, spend the time to truly understand how it works.

AI is similar to a good debugger or profiler: it can make you more effective, but it does not replace understanding the system you are building.

The Uncomfortable Question

Here's the question that keeps me up at night: How many developers are building careers on AI-generated code they don't understand?

This is also a matter of professional responsibility. If you own a piece of code, you should be able to explain, modify, and debug it, especially when a production issue occurs and the AI assistant is unavailable.

I don't have a good answer to that question. I just know I don't want to be that kind of developer.

Summary

After six months and nearly 100 AI-assisted prototypes, only mcp-windbg shipped. The difference was that I used AI to speed up my learning instead of asking it to replace that learning.

Remember that uncomfortable truth from the beginning? Every prototype feels like success, but success is measured by shipping, not building. The dopamine hits from rapid prototyping are real, but they're not the same as the satisfaction of maintaining code you actually understand.

The lesson isn't to use less AI. The lesson is to use it better.

AI is like having a brilliant research assistant, debugger, and code reviewer all rolled into one. Use it to explore ideas faster, understand concepts deeper, and eliminate the boring repetitive work that burns you out. But don't delegate the understanding itself.

Next Steps

If this resonates with you, here's what I'd suggest doing right now:

Audit your current projects: Look at your recent work. Can you explain how the core functionality works without looking at the code? If not, spend some time diving into those systems.
Set a new rule: For anything you plan to ship, implement the "explain it without looking" test. If you can't walk someone through how it works from memory, you're not ready to ship.
Change how you prompt: Instead of "Build me X," try "Help me understand how to build X" or "What are the key concepts I need to know for X?"
Embrace the sitting-there hours: When you hit a bug or weird behavior, resist the urge to immediately ask AI for a fix. Spend 15-20 minutes trying to understand it yourself first.

Someone still needs to own the code. AI can help you move faster, but it cannot take that responsibility from you.

🚀 New Release: mcp-windbg 0.10.0

2025-10-11T00:00:00+00:00

mcp-windbg 0.10.0: Now Available on PyPI

Five months after the initial release of mcp-windbg, I'm releasing version 0.10.0 with significant improvements and simplified deployment.

mcp-windbg is now officially available on PyPI. Installation no longer requires cloning repositories or setting up development environments:

pip install mcp-windbg

This represents a significant simplification from the original setup process described in my first article.

Additionally, mcp-windbg is now listed on the official Model Context Protocol registry, which should improve discoverability and enable integrations with various MCP-compatible tools.

Release 0.10.0: Key Features and Improvements

Version 0.10.0 incorporates community feedback and focuses on improving usability across different experience levels with debugging tools.

New Features

Live Debugging Sessions

Added open_windbg_remote and close_windbg_remote functions
Support for connecting to live processes beyond crash dump analysis
Real-time debugging through conversational AI interface

Extended Dump File Support

Full compatibility with .mdmp and .hdmp formats
Microsoft Store WinDbg CDB compatibility
Improved automatic discovery of crash dump files

Development Infrastructure

Migrated to uv package manager for improved build performance
Significantly reduced development setup and build times
Streamlined dependency management

Community Contributions

@sooknarine contributed several key improvements that made this release possible:

#6: Find local dumps with other common extensions - Enhanced automatic discovery of crash dump files
#10: Add support for remote debugging - Implemented live debugging session support

These contributions demonstrate the value of community involvement in open source development.

Infrastructure Improvements

Several behind-the-scenes improvements enhance reliability and maintainability:

Continuous Integration: Automated testing across Python versions 3.10 through 3.14
Dependency Management: Automated security updates and dependency maintenance
Release Process: Streamlined deployment for faster delivery of updates

Documentation Updates

The documentation has been restructured for better usability:

AGENTS.md: Comprehensive debugging instructions specifically for AI assistants
Structured Templates: .github/prompts/dump-triage.prompt.md for consistent crash analysis (inspired by my prompt engineering article)
Repository Wiki: All documentation now lives in an easily searchable wiki
Simplified README: Focused on getting you started in minutes, not hours
This Changelog: So you know what's changing and why

Installation: From Tedious to Trivial

Remember the old installation process? Clone, setup virtual environment, install dependencies, configure paths... ugh.

Here's the new process:

# Install mcp-windbg
pip install mcp-windbg

# That's it. Seriously.

Then add this to your .vscode/mcp.json:

{
	"servers": {
		"mcp_windbg": {
			"type": "stdio",
			"command": "python",
			"args": [
				"-m",
				"mcp_windbg"
			],
			"env": {
				"_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
			}
		}
	}
}

The installation process is now considerably simplified compared to the previous manual setup requirements.

Next Steps

With 0.10.0 released, these are the next areas I plan to work on:

More AI integrations beyond VS Code
Enhanced live debugging capabilities
Performance optimizations for large dump files
Community-requested features (keep them coming!)

The development roadmap will continue to incorporate community feedback and feature requests.

Getting Started

To begin using mcp-windbg 0.10.0:

Install: pip install mcp-windbg
Configure: Add the MCP server to your VS Code configuration
Use: Load crash dumps and interact through natural language queries
Contribute: Report issues, suggest features, or contribute code improvements

Links:

Community Response and Impact

Since the initial release in May, the project has received significant community engagement. The original article generated over 40,000 page views within the first two days, along with thousands of LinkedIn impressions and direct messages from developers worldwide.

The feedback has been constructive and encouraging. Developers have shared how the tool helped reduce time spent on crash analysis, and several teams have integrated it into their debugging workflows. I've had opportunities to present this work both internally and externally, leading to valuable discussions about AI-assisted development tools.

The open source community response has been particularly gratifying. Contributors like @sooknarine have stepped in to add functionality that benefits all users. The GitHub repository has gained considerable attention, and the project's inclusion in the official MCP registry should further improve its discoverability.

Building something that genuinely helps other developers solve real problems has been rewarding beyond what I expected when I first started working on this as a way to improve my own debugging workflow.

Thanks to everyone who has contributed, shared feedback, or simply tried the tool. The community response has made this project much better than it would have been otherwise.

When Citrix App Protection Becomes App Obstruction

2025-07-01T00:00:00+00:00

When Your Own Product Keeps You Honest

You're trying to connect to your virtual desktop through Citrix Workspace, ready to access your work environment and get stuff done, when suddenly you're greeted with this delightfully cryptic message:

App protection component is restricting this launch. Contact your system administrator for further assistance.

Ah yes, classic. Especially when you ARE the system administrator and this error message tells you absolutely nothing useful. It's like getting a "something went wrong" alert - technically accurate, but not exactly actionable.

In my case, Nextcloud running on the host caused the problem. Closing Nextcloud allowed Citrix to connect; starting it again blocked the connection. I work at Citrix on a different team, which made this an interesting problem to debug in my spare time.

So, why?

Here's what's happening: When you have Nextcloud running on your host machine, it uses LD_PRELOAD as part of its Flatpak sandboxing mechanism. This is a perfectly legitimate system mechanism that allows applications to override or extend library functions at runtime.

App Protection sees a process using LD_PRELOAD on the host and treats it as suspicious, even though the process is unrelated to the virtual desktop connection.

The solution? A gentle conversation with the allow list to explain that these specific LD_PRELOAD patterns from Nextcloud are actually friends, not foes.

The Essential References

Before we fix this, credit where credit is due. The Citrix documentation that actually helped:

The Fix: Configuring the LD_PRELOAD Allow List

First, open the App Protection allow list configuration file:

sudo nano /opt/Citrix/ICAClient/config/AppProtection_Preload_Allowlist.json

Add the following entries to diplomatically inform App Protection that these specific LD_PRELOAD patterns from Nextcloud are legitimate and shouldn't trigger its protective instincts:

{
  "LD_PRELOAD=/app/bin/../lib/libzypak-preload-host.so:/app/bin/../lib/libzypak-preload-host-spawn-strategy.so:/app/bin/../lib/libzypak-preload-host-spawn-strategy-close.so" : "Nextcloud",
  "LD_PRELOAD=/app/bin/../lib/libzypak-preload-child.so:/app/bin/../lib/libzypak-preload-child-spawn-strategy.so" : "/app/lib/com.nextcloud.talk/Nextcloud",
  "LD_PRELOAD=/app/bin/../lib/libzypak-preload-child.so:/app/bin/../lib/libzypak-preload-child-spawn-strategy.so" : "/app/lib/com.nextcloud.talk/Nextcloud"
}

What do these entries mean?

Each line maps a specific LD_PRELOAD pattern to the application that uses it. The first entry handles Nextcloud's main process, while the second handles child processes. By adding these to the allow list, App Protection will graciously step aside and allow your virtual desktop connections to proceed without further interrogation.

Bonus: Finding Your Own LD_PRELOAD Patterns

If you're dealing with other applications that get blocked, here's a handy script to identify which processes are using LD_PRELOAD on your system (copied from the linked documentation):

#!/bin/bash
for pid in /proc/*/; do
    pid=${pid%*/}
    pid=${pid##*/}
    environ_file="/proc/$pid/environ"

    if [[ ! -f "$environ_file" ]]; then
        continue
    fi

    ld_preload_entry=$(tr '\0' '\n' < "$environ_file" | grep -w "LD_PRELOAD")
    if [[ -n "$ld_preload_entry" ]]; then
        cmdline_file="/proc/$pid/cmdline"
        cmdline=$(tr '\0' ' ' < "$cmdline_file" | awk '{print $1}')
        echo "\"$ld_preload_entry\" : \"$cmdline\""
    fi
done

This script scans all running processes and outputs the exact format you need for the allow list configuration.

Apply the Changes

Once you've updated the configuration file, restart the App Protection service:

sudo systemctl restart AppProtectionService-install.service

Et voilà! Harmony restored. Error banished, virtual desktop connection established, and you can finally keep Nextcloud running on your host machine while accessing your work environment without any diplomatic incidents.

Pro tip: Document this fix somewhere you'll actually remember to look. Future you will thank present you when setting up a new machine or after a product update kindly resets your allow list. This post is basically my way of creating searchable breadcrumbs for anyone (including future me) who encounters that cryptic error message and wonders why Nextcloud seems to be the culprit.

AI Meets WinDBG: A Different Way to Analyze Crashes

2025-05-04T00:00:00+00:00

Old Meets New: Bringing Crash Analysis into 2025

Let's face it - while the rest of software development has evolved at warp speed, crash dump analysis feels like it's been preserved in digital amber for decades. We've got self-driving cars and pocket-sized supercomputers, yet here we are, still pecking away at command prompts like it's the dawn of the internet. Why is debugging the only area where we cling to tools that look like they belong in a computer history museum?

Picture this: You, a professional software engineer in 2025, hunched over a terminal, manually typing arcane commands like !analyze -v and .ecxr, squinting at hexadecimal memory addresses, and mentally translating stack traces. All while your friends in other industries are delegating their work to AI assistants that can write entire documents, create art, or automate complex workflows.

Something's wrong with this picture, right?

I wanted a simpler workflow: ask questions in plain language and let an AI assistant run the relevant debugger commands. This is more than a new interface for WinDBG; it changes how you interact with the debugger.

When Inspiration Strikes

During a debugging session at work, I had one of those lightning bolt moments. What if - and stick with me here - we could apply the same AI-assisted "vibe coding" approach to crash dump analysis?

Picture this: instead of manually slogging through memory dumps and command outputs, you simply ask, "Hey, why did this application crash?" and get an intelligent, contextual answer that actually helps you solve the problem.

The idea was too compelling not to pursue. So I built it.

See It In Action: AI-Powered Crash Analysis

Before diving into the technical details, let me show you what this looks like in practice. I have prepared a demo application to showcase two different use cases:

Video 1: Crash Analysis and Automated Bugfix

In this video, I show how Copilot can analyze a crash dump, identify the bug and auto-fix the issue.

Your browser does not support the video tag.

As you can see in the video, instead of manually running WinDBG commands and interpreting the cryptic output, I'm having a natural conversation with GitHub Copilot. The AI quickly identifies that the application crashed, explains which specific conditions led to the crash, and suggests a fix.

Video 2: Automated Crash Dump Analysis of multiple crash dump files

This video demonstrates a different capability: analyzing multiple crash dump files at once. It shows how the tool can quickly identify which dumps belong to your application and which don't.

Your browser does not support the video tag.

Worth noting, it takes just a few seconds until you get your first useful answer. I've played around with this for many hours and let me tell you one thing: You can really go deep. If you ask the right questions, the AI runs WinDBG/CDB commands that I haven't seen in all these years of debugging, and that is simply amazing.

How can this help the industry?

I believe this is one of the really good examples of how AI can boost productivity. Analyzing crash dumps is a very tedious task. It begins with quickly checking and identifying whether crashes are the same or different, and often requires very advanced knowledge when a crash is challenging - really challenging.

Copilot can help here tremendously; it knows how to:

Interpret assembly code (without you having to remember what EAX stands for)
Check memory contents (so you don't have to count hex bytes on your fingers)
Traverse structures with symbols (goodbye to manual pointer arithmetic!)
And so much more

This can help engineers, support teams, and QA staff work with crash dumps without memorizing every debugger command.

How did I build this?

If you've ever worked with WinDBG, you know the drill: cryptic commands, obscure syntax, and endless scrolling through memory addresses and stack traces that make your eyes glaze over. It's the kind of specialized knowledge that takes years to master and feels like speaking an alien language even when you do.

The trick here is connecting WinDBG with AI. To do that, you first need to programmatically control a debugging session, right? There are plenty of options on how to do this. I prefer to keep things simple, so I have chosen CDB, which is Microsoft's Console Debugger. It operates on standard input and output, and that's so much more fun to deal with than setting up COM APIs or similar approaches.

The second part is "connecting with AI." That's where Model Context Protocol Servers come into the game.

Understanding Model Context Protocol Servers

MCP is an open standard developed by Anthropic, released in November 2024. This protocol allows AI models to interact with external tools and data sources - think of it as giving AI assistants "hands" to work with other software. It defines a way for AI assistants to discover, access, and use tools through a consistent interface. In essence, it's what allows GitHub Copilot to "talk" to external programs like WinDBG.

An MCP server acts as the intermediary between the AI model and the tool. It:

Registers available tools with the client
Handles requests from AI models to use these tools
Executes the tool operations and returns results
Maintains context across interactions

Any tool can be made available to an AI model through an MCP server. I built one for WinDBG's CDB debugger.

Why MCP Instead of LanguageModelTool API?

The LanguageModelTool API might eventually be a better fit for this specific use-case. Creating a Visual Studio Extension that "just works" out of the box would potentially simplify the integration process significantly.

However, using MCP directly offers several notable advantages. It works with any AI model, not just limiting itself to Copilot. The server can be used outside VS Code, functioning with various other tools. New features can be easily added without necessitating changes to the core integration. Moreover, it remains platform-independent, avoiding lock-in to any single company's implementation.

The MCP-WinDBG Project

I've implemented a Model Context Protocol server that wraps WinDBG/CDB and exposes its capabilities to AI models within VS Code. Better yet, I've made it open source so everyone can experience this new workflow.

The project, mcp-windbg, connects VS Code and GitHub Copilot to WinDBG's analysis commands.

The actual "hard part" was implementing the CDB (Command-Line WinDBG) interaction layer. And by "hard", I mean vibe-coding with two coffees on a Saturday morning, where I spent more time being annoyed by pyTest failures than actual coding difficulties. The core implementation came together surprisingly quickly!

The rest is primarily wrapper code that implements the Model Context Protocol specifications. Now that I've established and defined the core WinDBG interaction logic, I'm considering refactoring the project to TypeScript. This would enable me to create both an MCP Server in TypeScript and a dedicated Visual Studio Extension, with both implementations leveraging the same underlying CDB interaction layer.

What Does This Mean In Practice?

Let me walk you through what this enables:

Natural language crash analysis: "Why is this application crashing with an access violation at this address?" (Instead of: "What the $%#@ is this heap corruption!?")
Contextual debugging: "Show me the stack trace for thread 5 and explain what each function is doing based on the symbols." (Instead of staring at call stacks like they're ancient hieroglyphics)
Root cause identification: "What's causing this null pointer dereference and where should I look in the code to fix it?" (Instead of playing detective with memory addresses)

Instead of typing obscure commands like !analyze -v followed by a series of manual investigations, you simply ask questions in plain language, and the AI interprets the crash data for you. It's like having a WinDBG expert whispering in your ear, except it doesn't get annoyed when you ask the same question five times.

How It Works

The MCP server connects GitHub Copilot to WinDBG:

It provides a set of tools that Copilot can use to interact with crash dumps
It translates natural language questions into appropriate WinDBG commands
It parses and interprets the often cryptic WinDBG output into more useful information
It maintains context throughout a debugging session, enabling follow-up questions to work naturally

The technical implementation uses Python to spawn and communicate with CDB (the command-line version of WinDBG), parses the output, and exposes the functionality through the Model Context Protocol to VS Code.

Getting Started With mcp-windbg

Ready to try it yourself? Here's how to get started:

First, make sure you have the Windows SDK installed with Debugging Tools for Windows
Clone the repository: git clone https://github.com/svnscha/mcp-windbg.git
Set up a Python virtual environment and install the package
Configure VS Code to use the MCP server

For complete details, check out the repository README.

Once configured, create a .vscode/mcp.json file in your project that points to the server:

{
    "servers": {
        "mcp_server_windbg": {
            "type": "stdio",
            "command": "python",
            "args": [
                "-m",
                "mcp_server_windbg"
            ],
            "env": {
                "_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
            }
        },
    }
}

You might need to update the command, depending on where and how you have installed the mcp_server_windbg to.

The Human Touch Still Matters

Just like with code refactoring, the AI assistance isn't perfect. The human element - your experience, intuition, and domain knowledge - remains crucial. Sometimes you'll need to guide the analysis, ask follow-up questions, or provide additional context.

The useful part is the combination: AI can process a large amount of debugger output quickly, while you provide the context needed to judge the result. It still needs supervision and can follow the wrong lead, so treat its findings as a starting point rather than a final answer.

Join The Experience

I'd love for you to try this out, contribute to the project, and share your experiences. If you're interested:

Star the GitHub repository
Try it on your own crash dumps
Report issues, suggest improvements, or contribute code
Share your success stories (or even failures - we learn from those too!)

The Magic Is In The Flow

Just like with my code refactoring experience, the real magic isn't about any single capability - it's about the flow. When debugging stops being a tedious chore and becomes a fluid conversation, something fundamentally changes in how you approach problem-solving.

Gone are the days of dreading crash analysis. Instead, each debugging session becomes an opportunity for collaboration with an AI partner that helps you understand what's happening at a deeper level.

Summary

Crash dump analysis has traditionally been one of the most technically demanding and least enjoyable parts of software development. It's like archaeology with a keyboard - painstakingly excavating through layers of memory and CPU state to unearth what went wrong. With AI assistance through tools like mcp-windbg, it becomes another area where we can experience that perfect "vibe state" of frictionless problem-solving.

If you're still manually typing WinDBG commands and squinting at memory dumps in 2025, you're not just missing out on productivity - you're missing out on a fundamentally more enjoyable way to work.

Try it. Debug it. Vibe it.

Vibe Coding is So Damn Real

2025-04-27T00:00:00+00:00

Why, You Ask?

Ever had that moment when your coding flow is so perfect it feels like you and your tools are in some kind of cosmic alignment? That's vibe coding. It's when the friction between thought and implementation practically disappears. And let me tell you, with GitHub Copilot and VS Code, this isn't just a fleeting sensation-it's a consistent reality.

I'm tired of writing about theoretical capabilities. Let me show you something concrete.

A Childhood Dream Come True

Let me share something personal: since I first started coding, I've had this recurring dream. A dream where I could simply talk to my computer, tell it what I want in plain language, and watch as it translates my intentions into working code. No syntax gymnastics. No hunting for semicolons. Just pure, frictionless creation.

"Hey computer, refactor this module to use dependency injection instead of globals."
"Computer, optimize this database query, it's running too slow."
"Add translation support to all user-facing strings in this module."

For decades, this remained firmly in the realm of science fiction-something for Star Trek episodes where they casually ask the computer to "reconfigure the deflector dish" and it just... happens.

DAMN, we're just there now. Not in some distant future, not as a tech demo, but as a practical, everyday reality in my development workflow.

Real-World Context: Nofidoc

A little context: In my free time, I've been pushing the boundaries of what's possible with AI-assisted coding-well beyond just casual experiments. While I also use these workflows at work, Nofidoc has become my personal playground for exploring how far I can take this technology. It's a space where I can try things that aren't always ready for the spotlight, but the results have been too compelling not to share (even if I'm keeping things a bit low-key for now).

The codebase uses Qt for the UI components, has a wizard-based document import flow, and handles various document formats with a focus on PDFs. It's exactly the kind of mid-sized C++ project where refactoring used to be tedious and error-prone.

The Perfect Pairing

VS Code with GitHub Copilot doesn't just assist your coding-it transforms it. No more wasting precious brain cycles on trivial tasks. No more tedious refactoring operations that make you question your career choices at 2 AM.

I recently needed to refactor the document import workflow to remove direct database dependencies in the wizard component. Why having that in the first place? Well, getting something proof-of-concept-ish is the answer. Anyways, this is a classic case of improving architecture by decoupling components, but it typically requires careful changes across multiple files and understanding the entire call hierarchy.

See The Entire Workflow In Action

I've recorded a full ~6-minute video showing the entire refactoring process from start to finish. You'll see me:

Prompt Copilot with my refactoring requirements
Watch the initial code changes being proposed
Hit compilation errors (because real-world code is messy!)
Provide additional guidance to Copilot
Get a complete, working solution

Your browser does not support the video tag.

What's remarkable here is not just that Copilot could make the changes, but how the entire interaction feels like working with a senior developer who deeply understands your codebase.

The Real Example: DocumentImportWizard Refactoring

Here's a snapshot of what happened in the video. I needed to update the DatabaseWidget class to use the new API of our DocumentImportWizard that we had refactored to remove direct database dependencies.

Copilot analyzed the code and came up with this solution:

// Before refactoring, direct database dependency:
void DatabaseWidget::onDocumentImportWizard()
{
    auto importWizard = new DocumentImportWizard(_database, this);
    importWizard->exec();
}

// After refactoring, using callback approach:
void DatabaseWidget::onDocumentImportWizard()
{
    auto importWizard = new DocumentImportWizard(this);
    importWizard->setGetDocumentTypesCallback([this]() {
        if (!_database)
            return QList<DocumentType>();
            
        auto docTypeService = _database->getDocumentTypeService();
        if (!docTypeService)
            return QList<DocumentType>();
            
        return docTypeService->getDocumentTypes();
    });
    importWizard->exec();
}

Copilot explained its reasoning:

"I've updated the onDocumentImportWizard() method in DatabaseWidget to use the new refactored API of our DocumentImportWizard class. The key changes were:

1. Removed passing the _database parameter directly to the DocumentImportWizard constructor 2. Added a call to setGetDocumentTypesCallback() with a lambda that:

Checks if _database is valid

Gets the document type service from the database

Returns the document types list from the service

Returns an empty list if any step fails

This completes the refactoring work by updating all the calling code to use the new API. The change maintains the same functionality but with a cleaner design that removes direct dependencies on the database pointer.

The implementation follows modern C++ practices by using a lambda to encapsulate the specific functionality needed (getting document types) while keeping the rest of the database access logic out of the wizard class. This makes the code more maintainable and easier to test."

This is exactly the kind of architectural improvement that typically takes deep understanding of both the codebase and software design principles. Yet Copilot produced it in seconds.

The Key Lesson: Human-AI Collaboration

My main takeaway is simple: AI tools work best when you bring your own domain knowledge.

Just before that, I was debugging a frustrating issue with field registration in that document import wizard. The fields weren't passing values between pages correctly. I asked Copilot to help fix the bug and it initially proposed an overly complex workaround that would have been a maintenance nightmare.

So I gave it a hint:

"I think there's an issue with the registerField calls for 'importSuccessCount' and 'importErrorCount'. The implementation doesn't specify the property name correctly."

And just like that, it had an "aha!" moment. It immediately identified the real issue:

// Before (buggy implementation):
registerField("importSuccessCount", this);

// After (Copilot's correct fix):
registerField("importSuccessCount", this, "importSuccessCount");

This simple fix resolved the entire issue. The fix works because it properly uses the Qt property system (third parameter) as the remaining code and pages expected, whereas Copilot's initial workaround was mega ugly - setting properties directly with setProperty() calls. With just a small hint about the actual problem, we were back on track. This perfectly illustrates why domain expertise remains critical - AI tools can suggest solutions, but knowing which ones make sense in your framework requires human judgment.

Sometimes AI tools need a gentle nudge in the right direction, and then they're off to the races again.

Not Always Perfect Magic

Let me be real with you - it's not all sunshine and rainbows. AI assistance sometimes misses the mark, and when it does, you need to steer it in the right direction. But I've found that:

The initial attempt is usually close
AI is exceptionally good at understanding feedback
With the right hints, it can quickly recover and find the optimal solution

The collaboration workflow is what makes all the difference. Instead of wrestling with a tool, it feels like having a junior developer who's eager to learn and quick to adapt.

What I Learned

This isn't just about saving time (though I saved HOURS). It's about changing how we think about coding. When you can express your intent in natural language and have it accurately translated into code changes, you're no longer programming computers-you're conversing with them.

The barrier between thinking and implementing just got so much thinner.

Getting This Setup Yourself

Want this superpower? Here's what you need:

VS Code
GitHub Copilot
A clear understanding of your codebase - To craft effective prompts

That's it! No complex configuration, no elaborate plugin chains.

Oh, which model? Right now I am using Claude 3.7 - it's so good.

Where This Is Going

You know that saying about technology and magic? This is it. We're witnessing the early days of a transformation in how software gets built. The tools are evolving to understand not just the syntax of our code, but the intent behind it.

Could I have written a complex bash script to do some of this refactoring? Maybe. Could I have used search-and-replace with regex? Probably. Would either approach have understood the semantic meaning of my code well enough to know which strings need translation? Absolutely not.

Summary

Vibe coding isn't just some feel-good developer term. It's that perfect state where you and your tools are in sync, where expressing your intent feels natural and immediate. With GitHub Copilot and VS Code, I'm experiencing this daily while building Nofidoc.

If you're still doing manual refactoring in 2025, you're not just missing out on productivity-you're missing out on the pure joy of frictionless development.

Try it. Feel it. Vibe code.

🚀 New Release: antispy SDK 2025.1.0

2025-04-22T00:00:00+00:00

I work on system insights and observability with the uberAgent team at Citrix. Outside work, Rene Windegger and I maintain the antispy SDK. We have worked on it for six years, and version 2025.1.0 is now available.

What began as a weekend experiment to confuse disassemblers has grown into an SDK for developers who want to make binary analysis more difficult.

What's New?

📚 Comprehensive Documentation

We've documented everything-every macro, every intricate detail of the virtual machine, and even the obscure compile-time tricks. Explore it all at antispy.xyz/docs. Plus, you can test examples live.

✨ Compiler Explorer Integration

Meet play.antispy.xyz, your in-browser playground for experimenting with the SDK. Adjust macros, tweak compile options, and analyze disassembly to your heart's content. Think of it as godbolt, but tailored for the paranoid.

Example

Explore the demo showcasing libantispy::encrypted_ptr, a feature that compiles into 22 basic blocks of obfuscated code-serious protection in action.

#include <antispy/libantispy.h>

int main() {
    libantispy::encrypted_pointer<int> ptr;
}

Try it yourself: play.antispy.xyz - libantispy::encrypted_pointer

Unlike libantispy::encrypted_pointer, the standard std::shared_ptr behaves quite differently, as demonstrated below:

After all, std::shared_ptr isn't designed to be obfuscated, is it?

🧠 Constexpr Code Generation

The antispy virtual machine now supports full compile-time constexpr functionality. Transform data, encrypt logic, and generate obfuscation layers-all before runtime. Who needs CPU cycles anyway?

⚙️ Updated Toolchains

We've modernized everything so you don't have to:

Android + iOS SDKs: ✅
Outdated compilers: 🪦
Legacy baggage: 🔥

If you're still using GCC 4.x, well, good luck.

Why antispy SDK?

The antispy SDK is useful for high-assurance binaries, anti-reversing work, or experiments with disassemblers. It includes documentation and a live explorer so you can try the available techniques before adding them to a project.

Platforms & Architectures

The antispy SDK supports the following major compilers and CPU architectures when C++20 is available:

Windows: x86, x64, ARM64
Linux: x86, x64, ARM64
macOS: ARM and Intel
iOS: Including tvOS, watchOS, visionOS
Android: x86, x86_64, armeabi-v7a, armv8a
Bare Metal SOCs: Fully supported

This gives you the same API across the supported platforms.

TL;DR: If C++ metaprogramming excites you and you believe binaries should fight back, this SDK is your perfect match.

Got feedback, feature requests? Let us know-we're probably not sleeping anyway.

Where's /etc/pve/firewall/cluster.fw in rescue images?

2024-10-04T00:00:00+00:00

Why, You Ask?

If a firewall rule has locked you out of a Proxmox server, you can disable the firewall from a rescue system. Here is the process I used to regain access.

Step 1: Mount the Proxmox System

First, you need to access your Proxmox filesystem. If you're using LVM (Logical Volume Management), this step is pretty straightforward:

mount /dev/mapper/vg0-root /mnt

With your filesystem mounted, chroot into it:

chroot /mnt/

Now you're inside your system, ready to work some magic.

Step 2: Disabling the Firewall

The firewall is likely what caused you to get locked out, so we'll need to disable it temporarily. Run the following commands:

systemctl disable pve-firewall
systemctl mask pve-firewall

Once you've done that, reboot the server. You should now be able to reconnect to your system normally, without the firewall cutting you off.

Step 3: Fix the Issue and Restore the Firewall

After fixing whatever issue got you locked out, it's time to re-enable the firewall. Run these commands to restore it:

systemctl unmask pve-firewall
systemctl enable pve-firewall
systemctl start pve-firewall

Your firewall should now be back up and running, but without the lockout problem.

A Note About `/etc/pve/firewall/cluster.fw`

If you're hunting for /etc/pve/firewall/cluster.fw while in rescue mode, hoping it's a typical file you can modify directly, you're out of luck. This file is part of Proxmox's cluster-wide configuration and is not stored as a regular file on the disk. Instead, it's managed through Proxmox's internal database, which is part of the Proxmox Cluster File System (pmxcfs). As such, it doesn't exist as a standalone file you can access from rescue mode. To modify this configuration, you'll need to regain full access to Proxmox and make changes from within the Proxmox interface or by editing it via the proper tools once you're back online.

Summary

And there you have it! With your system back up and running, and the firewall behaving, you can get back to managing your Proxmox server. Just be cautious next time you tweak the firewall rules - locking yourself out isn't the most fun way to spend your day!