MFC+WinPcap 网络嗅探器：从原始抓包到协议解析

简介：面向网络协议分析与 Windows 桌面开发学习者的原创 MFC+WinPcap 网络嗅探器源码包，基于 Visual Studio 工程组织，重点解决抓包、协议识别与界面展示如何衔接的问题，适合具备一定 C++ 基础、希望参考完整桌面抓包程序结构的学生与开发者。压缩包共 22 个文件，约 1.92MB，以 7 个 .h 头文件和 4 个 .cpp 源文件为核心，辅以 sln、vcproj 工程文件、rc、rc2 界面资源及 ico、png 图标素材，便于直接打开工程阅读与调试。已有 5406 人学习，说明其在网络编程与嗅探器入门场景中具有一定参考价值。源码覆盖 IPv4、IPv6、ARP、ICMP、TCP、UDP、HTTP 等协议的捕获与解析思路，并配有较友好的 MFC 界面，可帮助读者理解 WinPcap 抓包流程、协议分层解析、数据展示与工程模块划分，也适合作为课程设计或网络实验的参考实现。

1. 一个能看懂每个字节的嗅探器：MFC + WinPcap 这套组合到底适合谁

排查内网某个服务连不上的问题时，通用抓包工具打开一看全是加密流量，想确认本机到底有没有往目标端口发包、三次握手卡在哪一步，最省事的办法往往是自己写个小工具。这份原创的 MFC + WinPcap 网络嗅探器（sniffer）就是干这个的：MFC 提供现成的对话框、下拉框和列表控件，WinPcap 负责把网卡上的原始帧原封不动交到回调函数里，核心抓包逻辑不到三百行就能跑起来。它适合两类人——一类是想亲手拆一遍以太网帧头、IP 头、TCP 头到底长什么样的开发者，另一类是在内网环境里需要一个不依赖第三方客户端、字段想加就加的轻量抓包工具的运维。它不打算替代通用抓包软件，胜在整条链路都在自己手里，想改过滤条件、想加一列时间戳，改几行代码就行。

2. 技术栈与环境：VS 工程、WpdPack 开发包和驱动怎么一次配好

2.1 MFC 和 WinPcap 各自负责哪一段

先把分工讲清楚，后面配环境才不容易乱。MFC 这一层解决的是「界面和消息循环」：对话框资源、控件绑定、窗口消息泵，全是它管的；它本身完全不懂网络，也不碰网卡。WinPcap 这一层解决的是「从网卡拿原始帧」：它由驱动和用户态库两部分组成，驱动挂在网卡上做数据拷贝，用户态导出wpcap.dll供程序调用，另外还有一个可选的Packet.dll提供更底层的接口。

真正在中间做胶水的是我们自己写的抓包线程和协议解析函数。抓包线程调用 WinPcap 的阻塞接口pcap_loop，每收到一帧就进一次回调；回调里做协议解析，把二进制拆成「源 IP、目的 IP、协议、长度」这样的文本，再通过自定义消息送回 UI 线程显示。这套分层很关键，因为 WinPcap 的回调运行在抓包线程上，不是 UI 线程，凡是涉及控件操作必须跨线程投递，这一点后面单独讲。

选型上没什么玄学：同一时期想做 Windows 桌面抓包，MFC 是现成的壳，WinPcap 是唯一成熟的免费抓包库。现在新项目多数会考虑 Npcap，但它对 WinPcap 的 API 基本兼容，pcap_*系列函数名和参数都没变，本文这套代码换个库照样能编，只是安装包和 dll 名字不同。

2.2 从零建一个 MFC 对话框工程

打开 VS，新建项目，选「MFC 应用」，项目名随意，比如SnifferDemo。向导里几个关键选项别选错：

• 应用程序类型选「基于对话框」，不要选单文档或多文档，嗅探器这类工具不需要文档视图架构，对话框足够；
• 项目样式选「MFC standard」，不要选「Windows 经典」；
• 如果向导最后一页有「使用 Unicode 库」之类的选项，保持默认勾选即可，代码里字符串统一用CString；
• 高级功能里可以勾掉「打印和打印预览」「ActiveX 控件」这些用不上的。

建完先编译一次，确认空对话框能跑起来，再往下加东西。这一步看着废话，但血泪经验是：很多人是在已经写了一堆抓包代码之后才发现 MFC 组件没装全，编译报一堆afxwin.h找不到，回头重装 VS 反而更慢。

如果 VS 安装时没勾「C++ MFC 组件」，打开项目会提示缺少 MFC 库。补救办法是打开 VS Installer，找到「使用 C++ 的桌面开发」工作负载，右侧的「可选组件」里勾上 MFC 支持，装完重启 VS。这一步不涉及代码，但版本差异主要就体现在这里，不同 VS 版本的 MFC 组件默认勾选状态不一样。

2.3 WpdPack 开发包的三处落地

WinPcap 分两个东西：一个是开发包 WpdPack，压缩包里有Include和Lib两个目录；另一个是运行时安装包，装完系统里才有wpcap.dll和驱动。很多人只装了后者，结果编译时报pcap.h找不到，就是漏了开发包。

开发包解压到任意路径，比如D:\dev\WpdPack，然后在工程里做三件事：

第一，配置头文件目录。项目属性 → C/C++ → 常规 → 附加包含目录，加上D:\dev\WpdPack\Include。

第二，配置库目录和库名。项目属性 → 链接器 → 常规 → 附加库目录，加上D:\dev\WpdPack\Lib；再到链接器 → 输入 → 附加依赖项，填wpcap.lib。如果打算用Packet.dll那套更底层的接口，再加一个Packet.lib，本文的代码只用到wpcap.lib。

第三，处理运行时的 dll。程序编译出来是 exe，但运行时需要wpcap.dll。最稳的做法是装上 WinPcap 的运行时安装包，它会往系统目录放 dll；如果不想装，把 dll 直接拷到 exe 同目录也行。这里有个 32 位 / 64 位的坑：工程是 Win32 就得配 32 位 dll，是 x64 就得配 64 位 dll，拿错了会在pcap_findalldevs第一次调用时直接崩或者返回 -1。

配置完可以用一段最小代码验证环境是否通：

// 放在对话框初始化里，能弹出网卡数量就说明环境通了 #include "pcap.h" void CSnifferDemoDlg::TestEnvironment() { pcap_if_t *alldevs = nullptr; char errbuf[PCAP_ERRBUF_SIZE] = { 0 }; // 枚举本机所有可抓包的网卡 if (pcap_findalldevs(&alldevs, errbuf) == -1) { CString msg; msg.Format(_T("枚举失败：%s"), CString(errbuf)); AfxMessageBox(msg); return; } int count = 0; for (pcap_if_t *d = alldevs; d != nullptr; d = d->next) count++; pcap_freealldevs(alldevs); // 枚举结果必须释放，否则内存泄漏 CString msg; msg.Format(_T("找到 %d 个网卡"), count); AfxMessageBox(msg); }

pcap_findalldevs的第二个参数是错误缓冲区，长度固定PCAP_ERRBUF_SIZE，失败时里面是英文错误串。返回的链表每一项是一个pcap_if_t，其中name是设备内部名（形如\Device\NPF_{GUID}），description是给人看的友好名。这里只数了个数，真正的嗅探器要把整个链表存下来，因为用户在下拉框里选网卡时还要用。注意pcap_freealldevs一定要调，它释放的是整条链表，漏掉就是每次刷新网卡列表泄漏一次。

如果这段代码能弹窗，说明头文件、库、dll 三层都对了，可以进入下一步。弹不出来就回头看错误串，Error opening adapter多半是 dll 位数不对，No interfaces found多半是驱动没装上。

3. 工程骨架：对话框类、抓包线程与协议解析层的职责边界

3.1 目录结构与文件清单

MFC 向导生成的工程文件比较散，实际写业务代码时我一般会把新增文件归到几个子目录，避免全堆在根目录里。这个嗅探器的结构大致如下：

SnifferDemo/ ├── SnifferDemo.sln ├── SnifferDemo/ │ ├── SnifferDemo.h / .cpp // 应用类，几乎不用改 │ ├── SnifferDemoDlg.h / .cpp // 主对话框：控件、消息、线程调度 │ ├── SnifferDemo.rc // 对话框资源和控件布局 │ ├── stdafx.h / pch.h // 预编译头，WinPcap 头文件在这里引 │ ├── PacketParser.h / .cpp // 协议解析：以太网、IP、TCP/UDP │ ├── PacketInfo.h // 解析结果的数据结构 │ └── res/ // 图标等资源 └── WpdPack/ // 开发包，放在工程外也行

PacketParser单独拆出来是有意为之：协议解析是纯函数，输入一段字节缓冲和长度，输出一个结构体，不依赖任何 MFC 控件，也不依赖全局状态。这样调试的时候可以脱离界面单独跑，写几个单元测试把抓到的十六进制串丢进去，验证解析出来的 IP 和端口对不对。所有跟界面耦合的东西全部留在对话框类里，职责就清晰了。

PacketInfo结构体是两层之间的契约，字段按需增减：

// PacketInfo.h 解析结果的数据载体 struct PacketInfo { CString strTime; // 抓包时间，精确到毫秒 CString strSrcMac; CString strDstMac; CString strSrcIp; CString strDstIp; CString strProtocol; // TCP / UDP / ICMP / ARP / 其他 UINT nSrcPort; UINT nDstPort; UINT nLength; // 帧总长度 CString strSummary; // 列表里显示的一行摘要 };

这里用CString而不是std::string，纯粹是为了省掉 UI 层再做一次编码转换。如果后续要往文件里导出，建议再加一组std::string或者宽字节原始字段，避免序列化时踩字符集的坑。

3.2 三个核心对象的分工

整个程序跑起来只有三个「活」的对象，边界必须划清楚：

主对话框CSnifferDemoDlg是唯一的 UI 持有者。它管下拉框（网卡列表）、按钮（开始 / 停止）、列表控件（抓包结果），还管一个pcap_t*句柄的生命周期。所有控件操作只允许在这个类里发生。

抓包线程是一个AfxBeginThread起的 worker 线程，函数体极短，就是调用pcap_loop进入阻塞循环，然后把对话框指针作为参数传进去当回调的上下文。线程本身不碰任何控件，它唯一的输出是往 UI 线程投递消息。

协议解析层是一组普通函数，被回调函数调用。它不做 IO、不弹窗、不打日志，纯计算。这种设计下，想加一个新协议（比如 ARP、IPv6）只需要改解析层，其他两个对象一行都不用动。

这里有个容易忽略的点：pcap_t*句柄到底谁负责关。我的做法是对话框持有、对话框关闭，抓包线程只是使用者。因为pcap_loop是阻塞的，如果让线程自己关句柄，主线程可能在它关之前又调用了别的pcap_*函数，直接踩到已释放内存。反过来，主线程要关句柄前必须先让线程退出循环，这个顺序在 4.4 节会详细写。

3.3 线程模型与数据通道

WinPcap 的抓包接口是同步阻塞的，pcap_loop一旦进去就不出来，直到抓够指定数量的包或者被pcap_breakloop打断。这就决定了它不能跑在 UI 线程上，否则消息循环被卡死，窗口直接变成「未响应」。所以模型必然是「UI 线程 + 一个抓包线程」。

两个线程之间只允许一条通道：PostMessage。为什么不是SendMessage？因为SendMessage是同步的，它会等 UI 线程处理完才返回，在高速抓包场景下等于把抓包线程也拖慢，队列越积越长。PostMessage是异步投递，塞进消息队列就返回，抓包线程可以立刻回去收下一个包。

投递的数据怎么传？回调函数里解析出来的PacketInfo是在堆上new出来的，把指针强转成WPARAM投过去，UI 线程处理完消息后delete。这块内存的所有权非常明确：谁 new 谁不管，谁收到消息谁 delete。如果中途投递失败（比如窗口已经销毁，PostMessage返回 FALSE），就必须在投递方自己 delete，否则泄漏。

消息号定义在对话框头文件里：

// 自定义消息号，避开 WM_USER 以下系统占用的区间 #define WM_PACKET_ARRIVED (WM_USER + 100) #define WM_CAPTURE_STOPPED (WM_USER + 101)

消息映射表里加上ON_MESSAGE(WM_PACKET_ARRIVED, &CSnifferDemoDlg::OnPacketArrived)，处理函数的签名是LRESULT OnPacketArrived(WPARAM, LPARAM)。这套机制是 MFC 跨线程更新 UI 的标准做法，比直接在工作线程里调SetWindowText安全得多——后者在 Debug 版可能只是偶尔崩，Release 版则是随机崩，属于最难查的那类问题。

数据通道定好之后，剩下的工作就是往两头填内容：一头是抓包线程怎么拿到包并解析，另一头是 UI 线程怎么把解析结果塞进列表控件。下一章从网卡枚举开始，把整条链路走一遍。

4. 抓包主链路：从枚举网卡到拆出 IP 头的一次完整走位

4.1 枚举网卡并打开适配器

用户在界面上点「刷新网卡」时，要做的事情是枚举、存链表、填下拉框。存链表这一步不能省，因为pcap_open_live需要的是pcap_if_t::name那个设备内部名，而不是友好名。我的做法是用下拉框的SetItemData存链表节点的指针，同时用一个成员变量保存链表头，关闭时统一释放。

// 枚举网卡，填充下拉框 void CSnifferDemoDlg::RefreshAdapterList() { // 先清掉上一次的结果 if (m_pAllDevs != nullptr) { pcap_freealldevs(m_pAllDevs); m_pAllDevs = nullptr; } m_cbAdapter.ResetContent(); char errbuf[PCAP_ERRBUF_SIZE] = { 0 }; if (pcap_findalldevs(&m_pAllDevs, errbuf) == -1) { AfxMessageBox(CString(_T("枚举网卡失败：")) + CString(errbuf)); return; } int idx = 0; for (pcap_if_t *d = m_pAllDevs; d != nullptr; d = d->next) { // description 可能为空，退回用 name 显示 CString show = (d->description != nullptr) ? CString(d->description) : CString(d->name); int pos = m_cbAdapter.AddString(show); // 把链表节点指针挂到条目上，选中时直接取用 m_cbAdapter.SetItemData(pos, (DWORD_PTR)d); idx++; } if (idx > 0) m_cbAdapter.SetCurSel(0); // 默认选第一个，省得用户再点 }

SetItemData的参数是DWORD_PTR，32 位工程下是 4 字节，64 位下是 8 字节，存指针没问题，但要注意 32 位工程里指针也是 4 字节，强转不会截断。如果哪天要改成存索引，记得同步改取值的地方。

打开适配器的函数是pcap_open_live，四个关键参数：

// 打开选中的网卡，准备抓包 bool CSnifferDemoDlg::OpenAdapter(pcap_if_t *pDev) { char errbuf[PCAP_ERRBUF_SIZE] = { 0 }; // 65536 是最大帧长，保证不截断；1 表示开启混杂模式； // 1000 是读超时毫秒数，影响 pcap_loop 的响应延迟 m_hAdapter = pcap_open_live(pDev->name, 65536, 1, 1000, errbuf); if (m_hAdapter == nullptr) { AfxMessageBox(CString(_T("打开网卡失败：")) + CString(errbuf)); return false; } // 确认链路层类型是以太网，否则后面的解析全错位 if (pcap_datalink(m_hAdapter) != DLT_EN10MB) { AfxMessageBox(_T("该网卡不是以太网链路，本程序暂不支持")); pcap_close(m_hAdapter); m_hAdapter = nullptr; return false; } return true; }

第二个参数snaplen设成 65536 是为了抓全整个帧。如果只关心头部，设成 96 甚至更小能减少内存拷贝，但列表里就看不到完整载荷了。第三个参数是混杂模式，置 1 之后网卡会接收所有经过它的帧，而不只是发给本机的；在交换式网络里这个开关的效果取决于接入交换机的镜像配置，不是开了就一定能看到别人的流量，这点要有预期。第四个参数是读超时，设 1000 毫秒意味着即使没包，pcap_loop也会每秒醒一次，这让「停止抓包」的响应不会太迟钝。

pcap_datalink那一步检查别省。有些虚拟网卡、回环网卡的链路层类型不是DLT_EN10MB，帧头结构完全不同，直接按以太网去解析会得到一堆乱码 IP。

4.2 pcap_loop 的回调签名与线程入口

抓包线程的入口函数只做一件事：把对话框指针当上下文传给pcap_loop，然后阻塞在那里。

// 抓包线程入口，pParam 是对话框 this 指针 UINT CSnifferDemoDlg::CaptureThreadProc(LPVOID pParam) { CSnifferDemoDlg *pThis = reinterpret_cast<CSnifferDemoDlg*>(pParam); // 第二个参数 0 表示不限制包数量，一直抓到 breakloop // 第四个参数会原样传给回调，用来找回对话框对象 pcap_loop(pThis->m_hAdapter, 0, &CSnifferDemoDlg::PacketHandler, reinterpret_cast<u_char*>(pThis)); // 循环退出后通知 UI，便于恢复按钮状态 pThis->PostMessage(WM_CAPTURE_STOPPED, 0, 0); return 0; }

回调函数的签名是 WinPcap 定死的，不能改：

// 每收到一个包进一次，运行在抓包线程上 void CSnifferDemoDlg::PacketHandler(u_char *param, const struct pcap_pkthdr *header, const u_char *pktData) { CSnifferDemoDlg *pThis = reinterpret_cast<CSnifferDemoDlg*>(param); // header->ts 是时间戳，header->caplen 是实际抓到的长度 // header->len 是帧在链路上的原始长度，可能大于 caplen if (header->caplen < 14) // 连以太网头都不够，丢弃 return; PacketInfo *pInfo = new PacketInfo(); ParseEthernetFrame(header, pktData, *pInfo); // 投递失败说明窗口已销毁，自己回收内存 if (!pThis->PostMessage(WM_PACKET_ARRIVED, reinterpret_cast<WPARAM>(pInfo), 0)) { delete pInfo; } }

回调里绝对不能做的事：弹窗、写控件、Sleep、做耗时超过几毫秒的运算。因为这个函数是串行调用的，它慢一点，内核缓冲区就可能溢出丢包。pcap_stats可以查到丢包计数，调试阶段建议在停止抓包时打一条日志出来，丢包率高就说明回调太重或者列表刷新太频繁。

静态成员函数才能当回调，这是 C++ 成员函数指针的限制。所以PacketHandler声明成static，靠param参数把对象找回来，这是 WinPcap 官方示例里就有的写法。

4.3 以太网帧头与 IP 头的按位解析

解析函数从帧的0字节开始，一层层往里剥。以太网帧头固定 14 字节：6 字节目的 MAC、6 字节源 MAC、2 字节类型。类型字段是网络字节序（大端），要自己拼：

// 解析以太网帧，填充 PacketInfo void CSnifferDemoDlg::ParseEthernetFrame(const struct pcap_pkthdr *header, const u_char *pktData, PacketInfo &info) { const u_char *p = pktData; // 前 6 字节目的 MAC，接着 6 字节源 MAC info.strDstMac = FormatMac(p); info.strSrcMac = FormatMac(p + 6); // 类型字段大端：高字节在前 USHORT ethType = (USHORT)((p[12] << 8) | p[13]); info.nLength = header->len; switch (ethType) { case 0x0800: // IPv4 ParseIpv4(pktData + 14, header->caplen - 14, info); break; case 0x0806: // ARP info.strProtocol = _T("ARP"); info.strSummary.Format(_T("ARP 包，长度 %u"), header->len); break; case 0x86DD: // IPv6，本程序只标记不深解析 info.strProtocol = _T("IPv6"); info.strSummary.Format(_T("IPv6 包，长度 %u"), header->len); break; default: info.strProtocol = _T("Other"); info.strSummary.Format(_T("以太网类型 0x%04X"), ethType); break; } }

FormatMac是个小工具函数，把 6 字节拼成AA-BB-CC-DD-EE-FF的形式，用CString::Format逐个字节拼即可，注意u_char要提升成unsigned int再格式化，否则某些编译器会按字符输出。

IP 头比以太网头复杂，因为首部长度是可变的（有选项字段）。首字节的高 4 位是版本号，低 4 位是首部长度，单位是 4 字节，所以要乘 4 才是真实字节数。这是初学者最容易写错的地方之一，直接按固定 20 字节算，遇到带选项的包后面全错位。

// 解析 IPv4 头，偏移 0 是 IP 头首字节 void CSnifferDemoDlg::ParseIpv4(const u_char *p, UINT remain, PacketInfo &info) { if (remain < 20) return; // 不足最小 IP 头，丢弃 int version = (p[0] >> 4) & 0x0F; int hdrLen = (p[0] & 0x0F) * 4; // 首部长度以 4 字节为单位 if (version != 4 || hdrLen < 20 || (UINT)hdrLen > remain) return; BYTE proto = p[9]; // 上层协议号 USHORT totalLen = (USHORT)((p[2] << 8) | p[3]); // IP 总长度 // 源 IP 在偏移 12，目的 IP 在偏移 16，各 4 字节 info.strSrcIp = FormatIp(p + 12); info.strDstIp = FormatIp(p + 16); const u_char *payload = p + hdrLen; // 跳过 IP 头 UINT payloadLen = (totalLen > (USHORT)hdrLen) ? (totalLen - hdrLen) : 0; switch (proto) { case 6: // TCP ParseTcp(payload, payloadLen, info); break; case 17: // UDP ParseUdp(payload, payloadLen, info); break; case 1: // ICMP info.strProtocol = _T("ICMP"); info.strSummary.Format(_T("%s -> %s ICMP"), info.strSrcIp, info.strDstIp); break; default: info.strProtocol.Format(_T("IP(%d)"), proto); break; } }

TCP 头里端口在前 4 字节，各占 2 字节，也是大端；数据偏移在首字节的高 4 位，单位同样是 4 字节。UDP 头简单，固定 8 字节，前 4 字节就是两个端口。这三个函数的写法基本一致，都是「按偏移取字节、拼大端、格式化」，唯一需要小心的是每次取数据前都校验长度，否则遇到畸形包或者被截断的包就会越界读，轻则解析出乱码，重则直接崩溃。

4.4 把解析结果 PostMessage 回 UI

UI 线程收到WM_PACKET_ARRIVED后，从WPARAM里取回指针，往列表控件插一行，然后立刻delete。

// 处理抓包线程投递过来的包 LRESULT CSnifferDemoDlg::OnPacketArrived(WPARAM wParam, LPARAM /*lParam*/) { PacketInfo *pInfo = reinterpret_cast<PacketInfo*>(wParam); if (pInfo == nullptr) return 0; // 每次插入前关重绘，避免列表逐行闪烁 m_list.SetRedraw(FALSE); int row = m_list.InsertItem(m_list.GetItemCount(), pInfo->strTime); m_list.SetItemText(row, 1, pInfo->strSrcIp); m_list.SetItemText(row, 2, pInfo->strDstIp); m_list.SetItemText(row, 3, pInfo->strProtocol); m_list.SetItemText(row, 4, pInfo->strSummary); m_list.SetRedraw(TRUE); // 限制列表最大行数，防止长时间抓包把内存吃光 if (m_list.GetItemCount() > 5000) m_list.DeleteItem(0); // 滚动到最后一行，看起来像实时刷新 m_list.EnsureVisible(m_list.GetItemCount() - 1, FALSE); delete pInfo; // 谁收到谁释放 return 0; }

SetRedraw(FALSE)那对调用是必须的，否则每插入一行都触发一次重绘，几千行下来界面会明显卡顿。更彻底的做法是把列表控件设成虚拟列表（LVS_OWNERDATA样式），只维护数据数组、由控件回调取数据，但那样改动量偏大，作为第一个版本不划算。

EnsureVisible在行数很多时也会触发滚动计算，如果发现卡，可以改成每 20 行才滚一次，或者干脆加一个「自动滚动」复选框让用户自己关掉。

4.5 BPF 过滤器与停止抓包的正确顺序

过滤器用的是 BPF 语法，在pcap_loop开始之前设置，符合条件的内核直接放行，不符合的在驱动层就丢了，比在用户态自己判断效率高得多。

// 设置 BPF 过滤器，filter 为空表示抓全部 bool CSnifferDemoDlg::SetCaptureFilter(const CString &filter) { if (filter.IsEmpty()) return true; struct bpf_program fp = { 0 }; // 第三个参数 1 表示按子网掩码优化，第四个是编译后的程序 if (pcap_compile(m_hAdapter, &fp, CT2A(filter), 1, 0) < 0) { AfxMessageBox(CString(_T("过滤表达式错误：")) + CString(pcap_geterr(m_hAdapter))); return false; } int ret = pcap_setfilter(m_hAdapter, &fp); pcap_freecode(&fp); // 编译结果装进驱动后即可释放 return ret == 0; }

CT2A是 MFC 的字符串转换宏，把CString转成char*给pcap_compile用。如果工程是 Unicode 字符集，不做转换直接传会编译报错。常见的过滤表达式比如tcp port 80、host 192.168.1.10、udp and port 53，写错了pcap_compile会返回 -1，错误信息用pcap_geterr取。

停止抓包是最容易写出 bug 的地方。正确的顺序是三步：先pcap_breakloop让pcap_loop返回，再等线程句柄确认线程真的退出了，最后才pcap_close释放句柄。

// 停止抓包，严格按 breakloop -> 等线程 -> close 的顺序 void CSnifferDemoDlg::StopCapture() { if (m_hAdapter == nullptr) return; // 第一步：通知 pcap_loop 退出，这个函数可以在别的线程调用 pcap_breakloop(m_hAdapter); // 第二步：等抓包线程真正跑完，避免线程还在用句柄 if (m_pThread != nullptr) { WaitForSingleObject(m_pThread->m_hThread, 3000); // 最多等 3 秒 m_pThread = nullptr; } // 第三步：此时已无人使用，可以安全关闭 pcap_close(m_hAdapter); m_hAdapter = nullptr; m_btnStart.EnableWindow(TRUE); m_btnStop.EnableWindow(FALSE); }

顺序反过来，先pcap_close再去breakloop，就是典型的 use-after-free，表现是停止抓包时偶发崩溃，且崩溃位置每次都不一样，查起来非常费劲。

5. 抓包翻车排查：五条踩过的坑和解法

5.1 编译期头文件冲突：winsock2.h 和 winsock.h 打架

现象：工程里加了#include "pcap.h"之后，编译报一堆重定义错误，提示fd_set、timeval、sockaddr_in之类的结构体「已经在 winsock.h 中定义」。

原因：MFC 的预编译头stdafx.h或者pch.h里会先引入afxwin.h，它内部间接包含了老的windows.h，而windows.h在没定义WIN32_LEAN_AND_MEAN的情况下会把winsock.h拉进来。pcap.h在 Windows 平台上又需要winsock2.h里的类型，两个头文件的结构体定义冲突，编译器就炸了。

解决：在预编译头的最顶部、任何其他 include 之前加上#include <winsock2.h>和#include <ws2tcpip.h>，让新头文件先进来。另一种做法是在项目属性 → C/C++ → 预处理器里加一个WIN32_LEAN_AND_MEAN宏，把windows.h里的网络部分裁掉。两种都行，我一般两个都用，双保险。改完记得清理解决方案再全量重编，增量编译有时候不会重新处理预编译头。

5.2 运行期找不到 wpcap.dll，或者位数不匹配

现象：编译零错误，双击 exe 直接弹「无法启动此程序，因为计算机中丢失 wpcap.dll」。或者 dll 放进去了，程序一启动调pcap_findalldevs就崩。

原因：前者是运行时库没装，开发包 WpdPack 只提供头文件和 lib，不提供运行期的 dll 和驱动。后者是 32/64 位不匹配——工程是 x64，却拷了一个 32 位的wpcap.dll过来，加载器能找到文件但入口点对不上，调用时直接崩。

解决：最省事的是装一遍 WinPcap 的运行时安装包，它会同时装驱动和 System32/SysWOW64 两份 dll。不想装的话，把正确位数的 dll 拷到 exe 同目录，同时确认网卡驱动也已经装上，否则pcap_findalldevs会返回 0 个网卡而不是报错。判断位数很简单，用 dumpbin 或者任务管理器看 exe 是 32 位还是 64 位，对着拷。这个坑的隐蔽之处在于它不报错、只是崩溃或者返回空列表，第一反应容易往代码上找。

5.3 回调里直接操作控件，Debug 不崩 Release 崩

现象：在PacketHandler里直接写m_list.InsertItem(...)，Debug 版跑半天没事，Release 版跑几分钟就崩，崩溃调用栈还每次都不一样。

原因：pcap_loop的回调运行在抓包线程上，CListCtrl这类控件是窗口对象，只能在创建它的 UI 线程里操作。跨线程直接调用会破坏 MFC 的内部状态，Debug 版因为有额外的断言和检查，有时候会提前拦住；Release 版什么保护都没有，就是随机踩内存。

解决：所有 UI 操作必须回到 UI 线程，用PostMessage把数据投过去，让消息处理函数去做插入。不要用SendMessage，它是同步的，会把抓包线程拖慢。另外注意PostMessage返回 FALSE 时说明窗口已销毁，投递失败的对象要自己 delete，不然就是内存泄漏。这条属于 MFC 多线程编程的基本纪律，但在抓包这种高频回调场景下尤其容易犯，因为一开始图省事就直接写了。

5.4 停止抓包时程序卡死或者崩溃

现象：点「停止」，界面直接假死不响应，或者过一两秒弹崩溃。任务管理器里能看到线程数没降下去。

原因：两种可能。一是先pcap_close再breakloop，抓包线程还在回调里访问已经释放的句柄。二是用WaitForSingleObject等线程时传了INFINITE，而线程因为某种原因没退出，UI 线程就永远等下去了。

解决：严格按pcap_breakloop→WaitForSingleObject(带超时)→pcap_close的顺序来，超时设 3 到 5 秒，超时了也别硬关句柄，先打日志确认线程状态。还有一个细节：pcap_breakloop不保证立刻生效，如果当前正在处理一个包，要等这个包处理完、下一次进入循环时才会检查退出标志，所以回调函数一定要写得快。回调里如果有耗时逻辑，停止响应就会明显变慢。

5.5 抓不到任何包，或者抓到几千行后界面卡顿

现象：点了开始，列表一行都不动。或者能抓，但抓了几千行之后滚动变卡、点击按钮延迟。

原因：抓不到包通常是三个原因之一——网卡选错了（多网卡机器上很常见，选了虚拟网卡）；混杂模式虽然开了，但交换机没做端口镜像，看不到其他机器的流量；或者 BPF 过滤器写错了，把所有包都过滤掉了。卡顿则是列表控件每插一行都触发重绘和布局计算，行数上万之后开销线性增长。

解决：抓不到包先在下拉框里逐个网卡试，同时把过滤器清空，确认基础链路通。列表卡顿按 4.4 节的做法关重绘，并且限制最大行数，超过就删最老的。再进一步可以改成虚拟列表，只在LVN_GETDISPINFO里按需提供文本，几万行也不卡。另外EnsureVisible每次调用都会触发滚动，行数多的时候建议节流，比如每 20 行滚一次，或者干脆做成可选。

6. 二次开发：把只会列表展示的嗅探器改成能用的工具

代码跑通只是起点，真拿去干活还得改几处。最值得先做的是「详情面板」：列表里只显示摘要，双击某一行时把这一帧的完整十六进制和 ASCII 对照显示出来。实现上不难，在PacketInfo里加一个std::vector<BYTE> raw保存原始帧，回调里拷贝一份（注意caplen可能很大，加个上限），双击处理函数里用CListCtrl或者自绘控件渲染。这个功能一加上，工具立刻从「看个热闹」变成「能查问题」。

第二处是保存成 pcap 文件。WinPcap 自带pcap_dump_open、pcap_dump、pcap_dump_close三件套，在回调里顺手写一份就行，格式是标准 pcap，抓到的东西能直接拖进通用抓包软件里做后续分析。这里有个细节：pcap_dump要在回调线程里调，句柄的打开和关闭在 UI 线程，中间要保证线程安全，最省事的做法是开始抓包时打开、停止时关闭，中间不切换。

第三处是协议解析的扩展。现在的ParseIpv4只认 TCP、UDP、ICMP，遇到 DNS 想看域名、遇到 HTTP 想看请求行，就得在 TCP 载荷上再剥一层。我的建议是别急着写死在ParseEthernetFrame里，而是定义一个解析器注册表，每个协议一个函数指针，按端口或者按内容特征分发，加新协议时只加一个函数、注册一行。

验证改造有没有搞坏原有功能，我习惯用一份固定的 pcap 文件回放：把pcap_open_live换成pcap_open_offline，其他流程完全不变，跑一遍看解析结果和预期是否一致。这样不用真的去构造流量，也能覆盖到畸形包、截断包这些边界情况。

从那以后我每次动抓包相关的代码，都强制先跑一遍离线回放再上真网卡，因为这个领域的问题太依赖真实流量，肉眼看着正常的代码，换个网络环境就可能翻车。希望这些能帮到你，少走几段弯路。

本文还有配套的精品资源，点击获取