它能直接告诉我 bug 在哪并修好吗？

不能。它只是把自然语言请求转成调试器命令、把输出交给模型分析，修不修复、结论准不准，取决于调试器输出本身和模型的解释，关键结论仍需人工复核。

只想在图形界面里点一点，能用吗？

不太适合。这个项目的定位就是无界面驱动调试器，如果需求只是在 WinDbg 图形界面里用内置的自然语言能力，先比较其他方案更省事。

客户端兼容性和 HTTP 认证怎么确认？

据项目说明之外的细节，包括客户端兼容矩阵、HTTP 认证机制与多用户隔离能力，仓库摘要里没有完整说明，部署前务必先读仓库文档或源码确认，不要默认它自带隔离。

内核调试连不上，先查什么？

先查目标端：KDNET、命名管道、串行三种方式的目标端配置各不相同，目标端没准备好，客户端这边换什么参数都没用。

批量处理转储时要注意什么？

控制资源占用，分批扫描、逐批看结果，一次性把上百个转储全塞进去，超时与输出量都会失控。

mcp-windbg：通过 MCP 驱动 CDB

25次阅读

没有评论

获取下载链

微信关注「软件教程管家」公众号，回复 mcp-windbg

官方渠道：GitHub 仓库

30秒速读：分析 Windows 崩溃转储时，最费时间的往往不是看结果，而是把“看调用栈、查模块、翻线程”这些操作一步步敲进调试器。mcp-windbg 把这套流程交给了 MCP：支持 MCP 的客户端可以用自然语言向它下指令，它再去驱动真实的 CDB 或 KD，把命令输出拿回来分析。覆盖的范围不小，转储分析、用户态远程调试、内核调试都能走同一套会话机制，但前提是你本来就有可用的 Windows 调试器和调试目标。

前往 GitHub 仓库

GitHub 国内访问较慢，如打不开可多刷新几次

项目信息表

项目	mcp-windbg，通过 MCP 驱动 CDB 与 KD 的 Windows 调试服务器
实现语言	Python 编写的 MCP 服务器
运行要求	Python 3.10 或更高版本，另需可用的 cdb.exe 或 kd.exe
调试对象	崩溃转储文件、用户态远程调试服务、内核调试目标
连接方式	转储文件直读；远程可用 TCP、命名管道或 COM；内核可用 KDNET、命名管道或串行
会话机制	每个转储或调试会话分配独立会话编号，支持超时恢复
许可证	MIT 许可证

上手指南

先把 Windows 调试工具装好，确认 cdb.exe 或 kd.exe 能正常启动，再谈接 MCP，否则客户端连上服务器也跑不起来。
按仓库说明准备 Python 3.10 以上的环境并启动服务器，启动后先不要直接上生产转储，拿一个手头已有的转储文件做一次初步分析，验证调用栈、模块和线程信息都能正常输出。
在支持 MCP 的客户端里配好服务器入口，第一次调用只做一件事：打开转储并做初步分析，确认输出格式符合预期，再逐步加远程会话或内核目标。
需要远程调试时，先在目标端把对应的调试服务或连接方式准备好，TCP、命名管道、COM 三种方式按目标端实际情况选，不要在客户端这边反复试错。
内核调试目标要等目标就绪后再进入调试，连接方式与目标端的配置必须事先对齐，串行与 KDNET 的准备工作完全不同。

核心能力一览

转储一次看全：打开 .dmp、.mdmp、.hdmp 文件后，一次调用就能做初步分析，并查看调用栈、模块与线程信息。
真调试器，不是模拟：它驱动的是真实的 CDB 与 KD 命令，kb、!process、!heap、lm 这类命令都可以直接执行，输出就是调试器本身的输出。
三类场景同入口：转储分析、用户态远程调试、内核调试走同一套会话管理，不用为每种场景另搭工具。
多会话并行：多个转储、多个远程会话、多个内核会话各有独立编号，互不干扰，适合对照着排查。
批量转储排查：可以扫描一个目录里的多个转储，做发现与比较，适合先批量分类、再挑重点深入的流程。
远程驱动：支持通过 HTTP 从另一台机器驱动调试器，无界面运行，便于接入自动化排查流程。

装完先调的 4 个设置

调试器路径先指对：cdb.exe 与 kd.exe 的路径是整个链路的起点，路径不对后面所有调用都会失败，升级调试工具后也要回来复查一次。
符号配置提前准备：没有符号，调用栈里就只剩地址，分析价值大打折扣。开始正式排查前先确认符号能正常加载，再谈让模型解释结果。
超时预期先定好：复杂转储或内核目标的命令耗时差异很大，超时后的会话重新同步机制要先理解，避免把一次超时误判成调试器挂了。
连接方式按场景分开：本地转储、用户态远程、内核目标三种场景的连接准备完全不同，配置时按场景分别记录，不要共用一套参数硬套。

注意事项与常见问题

它能直接告诉我 bug 在哪并修好吗？不能。它只是把自然语言请求转成调试器命令、把输出交给模型分析，修不修复、结论准不准，取决于调试器输出本身和模型的解释，关键结论仍需人工复核。
只想在图形界面里点一点，能用吗？不太适合。这个项目的定位就是无界面驱动调试器，如果需求只是在 WinDbg 图形界面里用内置的自然语言能力，先比较其他方案更省事。
客户端兼容性和 HTTP 认证怎么确认？据项目说明之外的细节，包括客户端兼容矩阵、HTTP 认证机制与多用户隔离能力，仓库摘要里没有完整说明，部署前务必先读仓库文档或源码确认，不要默认它自带隔离。
内核调试连不上，先查什么？先查目标端：KDNET、命名管道、串行三种方式的目标端配置各不相同，目标端没准备好，客户端这边换什么参数都没用。
批量处理转储时要注意什么？控制资源占用，分批扫描、逐批看结果，一次性把上百个转储全塞进去，超时与输出量都会失控。

适合谁，不适合谁

结论先行：经常要啃 Windows 崩溃转储、驱动问题或远程调试会话，并且愿意维护调试器、符号与目标端配置的人，用它收益最大。自然语言入口省掉的是重复敲命令的时间，批量转储比较省掉的是逐个打开的人工，而多会话机制让“几个转储对照着看”成为可能。反过来，如果团队连调试器路径、权限和符号环境都维护不起来，或者需求只是偶尔看一个本地转储，那这套配置成本很可能超过它省下的时间，先把图形界面的调试流程跑顺更实际。

推广