Earlier this year, Sven Scharmentke wrote an article entitled The Future of Crash Analysis: AI Meets WinDBG, documenting a fascinating project using AI to analyze Windows crash dumps. Specifically, it uses Model Context Protocol (MCP) as an interface between an LLM, GitHub Copilot within Visual Studio Code, and a crashdump file to query and explain root cause of an application crash. I found this article fascinating, as it’s yet another step in democratizing both the creation and triage of bad code, with applications in debugging, reverse engineering and threat analysis. What this means is that it’s now possible for people of less experience to interact with complex tools in natural language to do malware research; and subject matter experts to easily get an “AI Assist” in performing the above.
Why is this important? As I covered in my webinar Advanced Threat Analysis and Reverse Engineering using AI, IDA, and the SourcePoint JTAG Debugger, AI, when used properly, allows engineers to increase their productivity and output. It can abstract away the complexity of some tools that can take months or even years to master; and one example of that is Microsoft’s WinDbg application. Although it does support a GUI, it originated as a Command Line Interface (CLI) tool, and most of its raw power is not available within the visual interface. This applies in particular to its Language-Integrated Query (LINQ) syntax support, to query debugger objects; here’s an example:
dx -g Debugger.Sessions.First().Processes.Select(p => new { Name = p.Name, ThreadCount = p.Threads.Count() }).OrderByDescending(p => p.ThreadCount),5
Although it might not be obvious to the uninitiated, the above identifies the top 5 processes with the most threads in a debug session. Easy, right? 😊
As Sven has said, and I quote:
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?
And Sven’s article just touches the tip of the iceberg; this technology has a huge potential to extend beyond simple Windows crash dump analysis, as I’ll write about in a later edition in this series.
But first, some background: the essence of this project was to develop a tool that enables AI to interact with WinDbg for both crash dump analysis and live debugging, using Model Context Protocol (MCP). MCP is an open standard, developed by Anthropic, that allows AI systems like large language models (LLMs) to efficiently interact with external tools and data sources. It connects many tools together and allows for a natural language interface to them: for example, for a marketer, a simple prompt like “please generate my weekly performance report for last week” could allow instant read/write connections to a company’s HubSpot, Google Analytics, Salesforce, LinkedIn, and other accounts to gather and update data. But MCP is new, with documented vulnerabilities in authentication and authorization, supply chain risks, exposure to malicious prompt injections, and many more risks.
If you’re interested in these topics, an excellent reference is in the Git repository Model Context Protocol Servers, where the different categories of MCP servers are listed, with some caveats:
Reference Servers
These servers aim to demonstrate MCP features and the official SDKs.
Third-Party Servers
Official integrations are maintained by companies building production-ready MCP servers for their platforms.
Community Servers
A growing set of community-developed and maintained servers demonstrates various applications of MCP across different domains.
Note:
Community servers are untested and should be used at your own risk. They are not affiliated with or endorsed by Anthropic.
Quick note: if you are interested in extending GitHub Copilot with MCP to other IDEs other than VS Code, this is an excellent reference: https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp/extend-copilot-chat-with-mcp.
Sven’s project is clearly in a development stage, and is documented in his Git repository, complete with source code and examples: https://github.com/svnscha/mcp-windbg. The README, although well-written, assumes a level of knowledge that some non-programmers and those new to WinDbg might not have. As such, I’ve created a tutorial below to help newcomers get started. Note that I have a brand-new PC, so I started everything from scratch, perhaps making it more helpful for novices. I want to help mass adoption of this technology – even for those who might not be developers themselves. So, here comes the tutorial, so anyone with a modicum of experience can follow:
- Install Visual Studio Code and the Python extension. Run VS Code.
- Enable scripts running from within PowerShell. Note you might not want to do Bypass; read here for the Exception Policies guidelines here: https:/go.microsoft.com/fwlink/?LinkID=135170 (which currently takes you to: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.5):
PS C:\WINDOWS\system32> Get-ExecutionPolicy
Restricted
PS C:\WINDOWS\system32> Set-ExecutionPolicy -ExecutionPolicy Bypass
Execution Policy ChangeThe execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the About Execution Policies help topic mentioned above. You’ll be prompted to confirm that you want to change the execution policy.
But I do trust Sven. 😊
- From within the VS Code Terminal window, clone the repository, and change directories into it:
git clone https://github.com/svnscha/mcp-windbg.git
cd mcp-windbg
Create and activate a virtual Python environment:
python -m venv .venv
.\.venv/Scripts\activate
Install the package in development mode, and install the test dependencies:
pip install -e .
pip install -I “.[test]”
Just as an aside, for future developments, integrating the MCP server with VS Code is accomplished by placing an mcp.json file with the below contents into the .vscode directory (it should be already there):
{
"servers": {
"mcp_server_windbg": {
"type": "stdio",
"command": "${workspaceFolder}/.venv/Scripts/python",
"args": [
"-m",
"mcp_server_windbg"
],
"env": {
"_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
}
},
}
}- At the bottom right of the GitHub Copilot Chat window, select “Agent” (from the choice of Agent, Ask and Edit) and the model you want (I used Claude Sonnet 3.5 at this time of writing, but there are other choices available, including Manage Models and Add Premium Models – wow).
- From here on in, it should be smooth sailing. You can use GitHub Copilot to help you ensure that WinDbg (actually, it’s CLI foundation, which is CDB, short for Console Debugger) is installed, Windows SDK is present, the demo crashdump file is available, etc. etc. Here’s the unabridged Chat window (where I made a bunch of mistakes, so you won’t have to) from Copilot within VS Code, for those who might want to follow along:
alansguigna1: open_windbg_dump
GitHub Copilot: I notice you want to use the `open_windbg_dump` command. I see there's a crash dump file in the test directory at DemoCrash1.exe.7088.dmp. Let me analyze it for you.
Ran `open_windbg_dump`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"include_stack_trace": true,
"include_modules": true,
"include_threads": true
}
I apologize for the error. It seems that WinDbg/CDB (the Windows Debugger) is not installed or not properly configured on your system. To analyze crash dumps, you'll need to:
1. Install the Windows Debugging Tools which includes CDB (Command-Line Debugger)
2. Ensure CDB is in your system PATH or configured in your environment
Would you like me to help you set up the Windows Debugging Tools on your system?
alansguigna1: Yes
GitHub Copilot: I'll help you install the Windows Debugging Tools. There are two main ways to get WinDbg and CDB:
1. Through the Windows SDK (recommended)
2. Through the Windows Store (WinDbg Preview)
Let's use the Windows SDK method as it's more complete. I'll run a command to check if you have the Windows SDK installed first.
Ran terminal command: Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object { $_.DisplayName -like "*Windows SDK*" } | Select-Object DisplayName, InstallLocation
It seems you don't have the full Windows SDK installed. Here's what we need to do:
1. Download the Windows SDK installer
2. Install it with the Debugging Tools component
3. Add the debugger to your PATH
Let me help you with these steps:
Ran terminal command: $url = 'https://go.microsoft.com/fwlink/?linkid=2164145'; $outPath = 'winsdksetup.exe'; Invoke-WebRequest -Uri $url -OutFile $outPath
I've downloaded the Windows SDK installer. Now you'll need to:
1. Run the downloaded winsdksetup.exe file
2. When the installer opens:
- Select "Debugging Tools for Windows"
- You can uncheck other components if you don't need them
- Click Install
After installation completes, we'll need to add the debugger to your PATH. The default installation path for the debuggers is:
- 64-bit debugger: `C:\Program Files (x86)\Windows Kits\10\Debuggers\x64`
- 32-bit debugger: `C:\Program Files (x86)\Windows Kits\10\Debuggers\x86`
Would you like me to help you add the debugger to your PATH after you complete the installation? Just let me know when you've finished installing the SDK, and I'll help with the next step.
alansguigna1: Yes, I am finished. Please proceed.
GitHub Copilot: Great! I'll help you add the debugger to your PATH. Let's add both the x64 and x86 debugger paths to make both available. First, let's verify the installation paths:
Ran terminal command: Test-Path 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe'
Excellent! The debugger is installed. Now let's add it to your PATH environment variable permanently:
Ran terminal command: $x64Path = 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64'; $x86Path = 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86'; $currentPath = [Environment]::GetEnvironmentVariable('Path', 'Machine'); if (-not $currentPath.Contains($x64Path)) { [Environment]::SetEnvironmentVariable('Path', $currentPath + ';' + $x64Path, 'Machine') }; if (-not $currentPath.Contains($x86Path)) { [Environment]::SetEnvironmentVariable('Path', $currentPath + ';' + $x86Path, 'Machine') }
I apologize for the error - it seems we need administrator privileges to modify the system PATH. Let me provide you with the steps to do this manually:
1. Press Windows + X and select "System"
2. Click on "Advanced system settings" on the right
3. Click "Environment Variables" at the bottom
4. In the "System variables" section (bottom half), find and select "Path"
5. Click "Edit"
6. Click "New" and add these two paths:
```
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
```
7. Click "OK" on all windows to save
After you've done this, please open a new PowerShell window and verify the installation by running:
Ran terminal command: cdb -version
You'll need to restart your PowerShell session after adding the paths to your system environment variables. Please:
1. Complete the manual PATH addition steps I provided above
2. Close all PowerShell windows
3. Open a new PowerShell window
4. Let me know when you're ready, and I'll help you verify the installation
Once that's done, we can proceed with analyzing the crash dump!
alansguigna1: I am ready, please proceed with verifying the installation.
GitHub Copilot: Let's verify that CDB is now properly installed and accessible in your PATH:
Ran terminal command: cdb -version
It seems CDB is still not accessible. Let's double-check the installation path and make sure the file exists:
Ran terminal command: Get-ChildItem 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe'
Good news! The CDB executable exists in the correct location. Let's try running it with the full path to verify it works:
Ran terminal command: "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" -version
Let me try a different way to run it (PowerShell can be picky about spaces in paths):
Ran terminal command: & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe' -version
Excellent! CDB is installed and working correctly. The issue might be that the PATH environment variable hasn't been refreshed in your current PowerShell session. Let's refresh it:
Ran terminal command: $env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")
Now let's try the CDB command again:
Ran terminal command: cdb -version
I see that we're still having some issues with the PATH. For now, we can proceed with analyzing the crash dump using the full path to CDB. Let me try to analyze the crash dump:
Ran `open_windbg_dump`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"include_threads": true,
"include_modules": true,
"include_stack_trace": true
}
I apologize for the continued issues. Let me suggest a few things to try:
1. Make sure you've completely closed and reopened VS Code after adding the paths to your environment variables.
2. Verify the path addition in a new PowerShell window by running:
```powershell
$env:Path -split ';' | Where-Object { $_ -like '*Debuggers*' }
```
3. If that doesn't show the debugger paths, you might need to verify the environment variable was added correctly:
- Press Windows + X
- Select "System"
- Click "Advanced system settings"
- Click "Environment Variables"
- Under "System variables", find "Path"
- Verify these paths are present:
```
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
```
Would you like me to help you verify these settings? Also, as a workaround, we could temporarily configure the project to use the full path to CDB by examining the `cdb_session.py` file and updating it if needed.
alansguigna1: Yes
GitHub Copilot: Let's verify the environment settings and then look at configuring the project with the full path. First, let's check the current PATH for debugger entries:
Ran terminal command: $env:Path -split ';' | Where-Object { $_ -like '*Debuggers*' }
I see the x64 debugger path is there. Now, let's look at the `cdb_session.py` file to see how it's configured to find CDB:
Read [](file:///c%3A/Users/alans/OneDrive/mcp-windbg/mcp-windbg/src/mcp_server_windbg/cdb_session.py#1-1), lines 1 to 50
Great, I can see that the code already has a list of default CDB paths and can accept a custom path. Let's verify which CDB path exists and use that to configure the project:
Ran terminal command: $paths = @('C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe','C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe','C:\Program Files\Debugging Tools for Windows (x64)\cdb.exe','C:\Program Files\Debugging Tools for Windows (x86)\cdb.exe'); foreach ($path in $paths) { if (Test-Path $path) { Write-Host "Found CDB at: $path" }}
Perfect! We found both the x64 and x86 versions of CDB. Let's try to analyze the crash dump now, explicitly specifying the x64 CDB path:
Ran `open_windbg_dump`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"include_threads": true,
"include_modules": true,
"include_stack_trace": true
}
Let me check if there are any specific permissions or requirements needed for the dump file:
Ran terminal command: Get-Acl "c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp" | Format-List
The permissions look good. Let's try running CDB directly on the dump file to see if we get any helpful error messages:
Ran terminal command: & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe' -z "c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp"
Ah! Now we have a clear error message: "Could not match Dump File signature - invalid file format". This suggests that either:
1. The dump file might be corrupted
2. The dump file might be in a different format than what CDB expects
3. The dump file might be incomplete
Let's check the dump file's size and contents:
Ran terminal command: Get-Item "c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp" | Select-Object Length, CreationTime, LastWriteTime
The dump file is only 132 bytes, which is too small for a valid crash dump. A Windows crash dump should typically be several MB in size as it contains memory contents, register states, and other debugging information.
This suggests that:
1. The file might be a placeholder or test file
2. The dump file wasn't properly created
3. The file might have been truncated or corrupted during creation or transfer
Would you like me to:
1. Help you generate a new crash dump using one of the example programs in the examples folder?
2. Look for other dump files in the workspace?
3. Help you configure Windows to create proper crash dumps?
Please let me know which option you'd prefer to proceed with.
alansguigna1: I replaced the file with a valid one. Please try again.
GitHub Copilot: I'll try to analyze the dump file again now that you've replaced it with a valid one:
Ran `open_windbg_dump`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"include_threads": true,
"include_modules": true,
"include_stack_trace": true
}
Great! Now I can analyze the crash dump properly. This appears to be a null pointer dereference crash. Here are the key findings:
1. **Crash Type**: Null Pointer Write Access Violation (0xC0000005)
```
ExceptionCode: c0000005 (Access violation)
Attempt to write to address 0000000000000000
```
2. **Crash Location**: In `DemoCrash1.exe` at offset 0x1ee4
```
DemoCrash1+0x1ee4: mov dword ptr [rax],2Ah
```
The code is trying to write the value 0x2A (42 in decimal) to the memory location pointed to by the RAX register, but RAX contains 0 (null).
3. **Register State at Crash**:
```
rax=0000000000000000 (null pointer that caused the crash)
rip=00007ff700131ee4 (instruction pointer at crash location)
```
4. **Stack Trace**:
```
DemoCrash1+0x1ee4
DemoCrash1+0x5730
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21
```
The crash occurred during program initialization, as evidenced by the presence of `BaseThreadInitThunk` and `RtlUserThreadStart` in the call stack.
This appears to be from one of the example programs in the repository, specifically designed to demonstrate crash analysis. Looking at the examples directory, this might be from the `nullptr-dereference.cpp` sample.
Would you like me to:
1. Run more analysis commands to get additional details about the crash?
2. Look at the source code of the example that caused this crash?
3. Close this debugging session and analyze a different crash dump?
Please let me know how you'd like to proceed!
alansguigna1: Show me the call stack with k
GitHub Copilot: I'll use the `run_windbg_cmd` tool to execute the 'k' command on the dump:
Ran `run_windbg_cmd`
Completed with input: {
"command": "k",
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp"
}
This call stack shows the sequence of function calls at the time of the crash, reading from bottom to top:
1. The program started with `RtlUserThreadStart` (normal Windows process initialization)
2. Through `BaseThreadInitThunk` (thread startup)
3. Into the `DemoCrash1.exe` application at two locations:
- `DemoCrash1+0x5730`
- `DemoCrash1+0x1ee4` (where the crash occurred)
4. The rest of the stack shows the Windows error handling chain after the crash occurred:
- `KiUserExceptionDispatch` (exception handling)
- `RtlDispatchException` (exception dispatch)
- `UnhandledExceptionFilter` (system error handling)
- `WerpReportFault` (Windows Error Reporting)
The crash occurred at `DemoCrash1+0x1ee4` which is where the null pointer dereference happened. Since this is a stripped executable (no debug symbols), we're seeing offsets instead of function names in the `DemoCrash1` module.
Would you like me to:
1. Show more details about any specific frame in the call stack?
2. Look at the disassembly around the crash point?
3. Run any other WinDbg commands to gather more information?
alansguigna1: Look at the disassembly around the crash point, and give me some detail on the last three instructions leading up to the null pointer dereference.
GitHub Copilot: I'll use the `run_windbg_cmd` tool to look at the disassembly around the crash point. I'll use `u` command to show instructions before and after the crash location:
Ran `run_windbg_cmd`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"command": "u DemoCrash1+0x1ee4 L8"
}
Let me get a few instructions before the crash point to see what led up to it:
Ran `run_windbg_cmd`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"command": "ub DemoCrash1+0x1ee4 L3"
}
Now I can analyze the last three instructions leading up to the crash:
1. `mov rcx,rbx`
- This copies the value from the rbx register into rcx
- Likely preparing a parameter for the function call
2. `call DemoCrash1+0x2660`
- Makes a function call to another location in the program
- This function likely returns some value that should be stored in rax
3. `xor eax,eax`
- This instruction zeros out the eax register (lower 32 bits of rax)
- This is why rax was 0 when the crash occurred
- This is a common way to set a register to 0 in x86/x64 assembly
Then the crash occurs at:
```
mov dword ptr [rax],2Ah
```
This instruction attempts to write the value 0x2A (42 decimal) to the memory location pointed to by rax. However, since rax was explicitly set to 0 by the `xor eax,eax` instruction, this results in a null pointer dereference.
This looks like intentional crash-inducing code (which makes sense since it's from an example program). The code:
1. Makes a function call
2. Explicitly sets rax to 0
3. Immediately tries to write to the memory location pointed to by rax
This pattern is typical of test code designed to demonstrate null pointer crashes, and matches what we'd expect to see in the `nullptr-dereference.cpp` example from the repository.
Would you like me to:
1. Look at the function that was called (at `DemoCrash1+0x2660`)?
2. Examine the values in other registers at the time of the crash?
3. Look at the source code in `nullptr-dereference.cpp` to correlate with this assembly?
alansguigna1: run_windbg_cmd .ecxr
GitHub Copilot: Ran `run_windbg_cmd`
Completed with input: {
"dump_path": "c:\\Users\\alans\\OneDrive\\mcp-windbg\\mcp-windbg\\src\\mcp_server_windbg\\tests\\dumps\\DemoCrash1.exe.7088.dmp",
"command": ".ecxr"
}
The `.ecxr` command shows us the exception context record, which gives us the state of all CPU registers at the time of the crash. Here's what we can see:
1. `rax=0000000000000000` - The null pointer that caused the crash
2. `rbx=00007ff700160320` - Points to somewhere in the DemoCrash1 module
3. `rip=00007ff700131ee4` - The instruction pointer at crash location
4. `efl=00010246` - CPU flags showing:
- `zr` (zero flag) is set
- `pl` (sign flag) is clear
- `ei` (interrupt flag) is set
The instruction `mov dword ptr [rax],2Ah` is trying to write the value 0x2A to address 0, which triggers the access violation. The `ds:00000000`00000000=????????` indicates that the memory at address 0 is not accessible (as expected for a null pointer).
Most of the other registers (rsi, r12-r15) are zero, which is typical at program startup. The non-zero value in `rbx` (pointing into the DemoCrash1 module) might be a this pointer or other object reference that was being manipulated when the crash occurred.
You can see that I ran the open_windbg_dump to automatically find and analyze the DemoCrash1.exe.7088.dmp. That is extremely cool. After a few missteps on my part, it did a great job of providing root cause insight into the crash.
I wanted to point something out to those who might wonder about using both GitHub Copilot AND Claude Sonnet 3.5 in the example above…aren’t they both LLMs and chatbots? And the answer is emphatically no in this instance: Copilot is the front end service within the VS Code UI, and Claude is the back end LLM. In other words, Copilot is just a VS Code extension that uses the Claude LLM behind the scenes. So, when I asked for help in setting up the environment variables, it was Claude that gave the answer, and Copilot relayed it to me.
And one other thing: I’m often asked about how many tokens these researches take, and if all of this can be done via the free versions of the LLMs and applications, or if we have to upgrade to the paid versions. For myself, I upgraded to ChatGPT Pro ($20/month) quite some time ago, as I wanted the largest token context window I could get (within my budget, of course); which appears to be 32K tokens for the Plus plan, and 8K tokens for the Free plan. I did this to process large Intel Processor Trace files per my prior blog: Microsoft WinDbg Time Travel Debugging versus Intel Processor Trace. And early in the work for this blog, Microsoft paused my questions for a period of time, asking for the upgrade to GitHub Copilot Pro ($10/month). I did this upgrade as well, and haven’t run into any pauses since. Yes, it’s an expense, but in my mind, very much worth it.
If you want to see the whole MCP/WinDbg configuration process visually, check out my video here:
Where do we go from here? I believe that this is a new and emerging technology approach that will play a huge role in the future of offensive security engagements. In a previous White Knight Labs blog post, Understanding Null Pointer Dereference in Windows Kernel Drivers, we explored similar access violations, but within the Windows kernel. We’ll see how MCP is used to triage Windows kernel driver vulnerabilities in a future post.
