简介：一套基于VC6的完整源码工程，主要功能是获取U盘等移动设备的厂商识别码、产品识别码、盘符及物理序列号。运行后输出形如“盘符＼厂商识别码＆产品识别码＼物理序列号”的设备路径，例如“G盘＼VID_0951＆PID_1623＼001CC0EC32CDEA10969B011D”，信息层级清晰，便于程序直接解析。该源码通过Windows底层接口完成设备枚举，不仅支持U盘，对移动硬盘、手机卡、MP3/4等便携存储设备同样适用，适合设备识别、存储管控、数据恢复等开发场景，也适合学生和嵌入式开发者参考。压缩包共31个文件，包含C++源文件、头文件、可执行程序、静态库及调试信息文件，整体仅4.89MB，轻量易用，在VC6环境下打开即可编译运行。目前已有1742人学习下载，方案经过较多实践验证。拿到后可直接查看本机设备信息，也可提取核心逻辑嵌入到U盘加密、设备管理等项目中，省去从头研究底层接口的麻烦。 前阵子一个客户紧急找过来，说员工反馈新买的一批U盘用着用着就报错，插上电脑有盘符但一点开就让格式化。我把其中一支插到自己的Windows机器上，第一件事不是跑数据恢复，而是用一个随手写的小工具，把U盘的VID、PID、盘符、物理序列号全部拉出来。为什么先做这一步？因为这些信息基本决定了一支U盘的“真实身份”——主控是谁、方案是什么、能不能找到对应的量产工具，甚至是不是扩容盘，都会在这里露出马脚。
这篇文章就把这套可运行的源码一起放出来。它的作用很简单：枚举当前系统里所有USB设备节点，取出VID/PID和硬件序列号，再遍历所有盘符，找到哪个盘符对应这块USB存储设备，把物理序列号也对上。适合做U盘检测工具、量产工具辅助选型、资产盘点脚本、以及研究Windows存储栈的开发人员参考。代码不依赖第三方库，直接编译就能跑。
1. 这个工具解决什么问题：拿不到真身信息，处理U盘故障全靠猜
1.1 一次扩容盘处理带来的痛点
回到开头那个客户场景。那批U盘从外观到属性界面全都是正常的，容量显示也对，复制小文件也没问题，但文件稍微一多，复制到一半就报冗余循环检查错误。这种故障十有八九是扩容盘——主控的实际Flash容量远小于标称容量，容量参数被量产工具改过。
这时候如果手里只有一个U盘，没有任何软件辅助，你能做的就是拆壳看主控丝印。可现在的U盘很多是金属外壳或者一体封装，拆开就报废。就算拆开了，主控上的丝印往往也看不清。正确做法是直接读设备本身暴露出来的硬件信息：VID、PID决定了主控方案，物理序列号则是这一颗主控固件里的唯一标识。
用这套工具，插上U盘、运行程序，设备节点信息直接打出来。拿到 VID_xxxx&PID_yyyy 之后去搜索对应量产工具，基本一分钟就能锁定方案。那批U盘后来确认是低端主控配小容量Flash冒充64G，直接退货处理。
1.2 VID、PID和物理序列号到底代表什么
VID（Vendor ID，厂商识别码）和PID（Product ID，产品识别码）是一对USB设备标识，由USB-IF组织分配。VID代表厂商，比如金士顿常见的是0951，群联主控常见的是13FE；PID则是厂商内部定义的具体产品型号。这两个ID合在一起，能定位到设备的品牌和主控方案。
物理序列号稍微特殊一点。它对应USB设备描述符里的iSerialNumber字段，是主控固件写入的一串字符，可以理解为这个设备的“身份证号”。很多U盘出厂时序列号是16进制字符串，也有的是带字母的组合。需要特别说明的是，这个序列号跟你在Windows里右键盘符看到的“卷序列号”完全是两回事。卷序列号是格式化时随机生成的32位数字，只存在文件系统里，换一台电脑或者重新格式化就会变；物理序列号则固化在硬件里，只要主控不被重新量产，它就不变。
1.3 这类信息可以用在哪
除了鉴别扩容盘和找量产工具，这套能力还能用在几个很实际的地方。
企业IT资产盘点时，如果用U盘作为加密狗的替代方案，就需要把“哪台电脑插过哪个U盘”记录下来。记录的字段不能是盘符，因为盘符会变；也不能是卷序列号，重新格式化就失效。最可靠的资产标识就是物理序列号加VID/PID组合。
另外，做U盘启动盘工具时也有用。Rufus、Ventoy这一类软件识别U盘，如果只按盘符显示，多插几个U盘用户根本分不清谁是谁。把VID/PID和序列号也显示出来，就能精确区分两个同品牌同型号的U盘。标题相关的热搜词里也有U盘启动盘制作相关的需求，本质上都会用到这一层信息。
2. Windows如何向开发者暴露U盘信息
2.1 设备实例ID：从USB节点拿到VID/PID
Windows里查看设备信息，最推荐的方式是SetupAPI，而不是直接去翻注册表。因为注册表里的设备键路径在不同Windows版本上可能有差异，而SetupAPI是微软官方提供的稳定枚举接口，一套代码通吃XP到Windows 11。
枚举USB设备时，重点用的是设备实例ID（Device Instance ID）。它的格式一般是这样的：
USB\VID_0951&PID_1666\0001E7A2D3C4三段拆开看：第一段是设备类别，第二段是VID和PID，第三段是设备实例的序列号部分。这里有个细节很多人容易忽略：第三段并不一定等于USB描述符里的iSerialNumber，但它是由总线驱动根据设备信息生成的设备实例标识，在大多数U盘上恰好就是物理序列号。源码里我直接用这一串作为USB层面的序列号，实测99%的U盘都能正确对应。
2.2 盘符背后是一整条设备栈
很多初学者会以为盘符就是一个字母加冒号这么简单。实际上盘符是Mount Manager（挂载管理器）为卷（Volume）分配的访问入口。在Windows的存储设备栈里，一个U盘设备从底层到顶层大致是：USB设备节点 → USB大容量存储驱动 → 磁盘设备 → 分区 → 卷 → 盘符。
所以想从盘符反查硬件信息，不是读注册表就能解决的。代码上通常是先枚举所有盘符，然后用CreateFile打开这个卷的设备路径，再向设备栈发送IOCTL查询命令。能直接拿到盘符对应的物理存储设备属性，包括总线类型、厂商字符串、产品字符串、序列号，这就是我们想要的。
常用的查询方式是IOCTL_STORAGE_QUERY_PROPERTY，属于SCSI/ATA查询机制的Windows封装。它的返回值是一个STORAGE_DEVICE_DESCRIPTOR结构体，里面包含BusType、VendorIdOffset、ProductIdOffset、SerialNumberOffset等字段。注意这些Offset是相对于整个返回缓冲区的偏移量，不是指针，直接当指针用会读到乱七八糟的数据。
2.3 物理序列号藏在SCSI层
还有一个点需要理解：物理序列号虽然叫“物理”，但Windows应用层并没有一个直接叫“物理序列号”的API。它必须通过设备控制命令，一路穿透到存储协议层去取。
USB U盘在Windows里通常表现为USB大容量存储设备，内部用的是SCSI命令集（具体是UFI协议或者BOT协议）。IOCTL_STORAGE_QUERY_PROPERTY的底层，就是向设备发送SCSI INQUIRY命令，从标准INQUIRY数据的Serial Number字段里把这个值抠出来。这也是为什么我说物理序列号和卷序列号不能混为一谈：一个是走SCSI层跟硬件对话拿到的，一个是文件系统层的随机数。
这种设计带来的一个直接影响就是，如果一个U盘的主控固件本身没写入序列号，或者写入的字符串不合法，那么IOCTL查出来的序列号字段可能是空的或者全是空格。这种情况在使用山寨主控的U盘上很常见，后文会聊到。
3. 核心源码实现与逐段讲解
3.1 枚举USB设备节点并解析VID/PID
先看第一段，枚举USB设备节点。这里使用SetupApi中的SetupDiGetClassDevsA，配合GUID_DEVCLASS_USB，只枚举USB类型的设备节点。
#include <windows.h> #include <setupapi.h> #include <devguid.h> #include <winioctl.h> #include <ntddstor.h> #include <iostream> #include <string> #pragma comment(lib, "setupapi.lib") void EnumUsbDevices() { HDEVINFO hDevInfo = SetupDiGetClassDevsA( &GUID_DEVCLASS_USB, NULL, NULL, DIGCF_PRESENT); if (hDevInfo == INVALID_HANDLE_VALUE) return; SP_DEVINFO_DATA devInfo = { sizeof(SP_DEVINFO_DATA) }; for (DWORD index = 0; SetupDiEnumDeviceInfo(hDevInfo, index, &devInfo); index++) { char instanceId[512] = { 0 }; if (SetupDiGetDeviceInstanceIdA(hDevInfo, &devInfo, instanceId, sizeof(instanceId), NULL)) { std::string id(instanceId); char vid[16] = { 0 }, pid[16] = { 0 }, serial[128] = { 0 }; if (sscanf_s(id.c_str(), "USB\\VID_%4s&PID_%4s\\%s", vid, 16, pid, 16, serial, 128) == 3) { std::cout << "VID: " << vid << " PID: " << pid << " 序列号: " << serial << std::endl; } } } SetupDiDestroyDeviceInfoList(hDevInfo); }这里有个关键选择：为什么用SetupDiGetDeviceInstanceId，而不是直接看注册表枚举。因为注册表里面键值关系复杂，不同版本位置有差异，遇到中文系统还有编码问题，而SetupAPI这套接口在Windows国际化版本和所有版本的系统上行为一致。实测下来最省心。
解析字符串的时候用sscanf_s严格按固定格式去拆。设备实例ID的格式是稳定的，VID和PID都是4位十六进制大写字母，直接用掩码%4s取。这样遇到格式特殊的设备也能保证不会崩。
3.2 遍历盘符并读取底层设备的序列号
第二段是盘符和序列号查询的核心。先用GetLogicalDriveStringsA拿到所有盘符，再逐个打开卷设备路径，发IOCTL查询。
void EnumDrives() { char drives[256] = { 0 }; GetLogicalDriveStringsA(sizeof(drives), drives); char* p = drives; while (*p) { std::string root = p; UINT type = GetDriveTypeA(root.c_str()); if (type == DRIVE_REMOVABLE || type == DRIVE_FIXED) { std::string devicePath = "\\\\.\\" + root.substr(0, 2); HANDLE hDisk = CreateFileA(devicePath.c_str(), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); if (hDisk != INVALID_HANDLE_VALUE) { BYTE buffer[1024] = { 0 }; STORAGE_PROPERTY_QUERY query = {}; query.PropertyId = StorageDeviceProperty; query.QueryType = PropertyStandardQuery; DWORD bytesReturned = 0; if (DeviceIoControl(hDisk, IOCTL_STORAGE_QUERY_PROPERTY, &query, sizeof(query), buffer, sizeof(buffer), &bytesReturned, NULL)) { STORAGE_DEVICE_DESCRIPTOR* desc = (STORAGE_DEVICE_DESCRIPTOR*)buffer; std::string vendor, product, serial; if (desc->VendorIdOffset) vendor = (char*)(buffer + desc->VendorIdOffset); if (desc->ProductIdOffset) product = (char*)(buffer + desc->ProductIdOffset); if (desc->SerialNumberOffset) serial = (char*)(buffer + desc->SerialNumberOffset); std::cout << "盘符: " << root.substr(0, 2) << " BusType: " << (int)desc->BusType << " 厂商: " << vendor << " 产品: " << product << " 序列号: " << serial << std::endl; } CloseHandle(hDisk); } } p += strlen(p) + 1; } }这里有几个细节值得展开。第一，为什么用1024字节的缓冲区，而不是直接定义一个STORAGE_DEVICE_DESCRIPTOR变量。因为结构体里那些Offset指向的数据是紧跟在结构体后面存放的，缓冲区太小可能读不全，太大会浪费，实验下来1024字节足够覆盖几乎所有U盘的信息长度。
第二，偏移量的使用。desc->VendorIdOffset是ULONG类型的偏移值，必须用它加上缓冲区首地址才能取出真正的字符串。新手头一次写这个十有八九会直接取desc->VendorId当指针用，然后发现读出来都是乱码。这是整个代码里最容易翻车的地方。
第三，CreateFile的共享模式用了FILE_SHARE_READ | FILE_SHARE_WRITE。如果不加共享标志，当U盘里的文件正被Explorer打开时，CreateFile会返回拒绝访问。
3.3 自动关联输出：盘符加VID/PID加序列号
两段代码都有了，最后把它们合起来。main函数里先枚举设备节点，再枚举盘符，加上一个BusType过滤条件只显示USB设备，这样非USB硬盘不会混进结果里。
int main() { std::cout << "===== USB 设备节点 =====" << std::endl; EnumUsbDevices(); std::cout << "\n===== 盘符对应的物理存储设备 =====" << std::endl; EnumDrives(); return 0; }运行后大致输出如下：
===== USB 设备节点 ===== VID: 0951 PID: 1666 序列号: 0001E7A2D3C4 ===== 盘符对应的物理存储设备 ===== 盘符: E: BusType: 7 厂商: Kingston 产品: DataTraveler 3.0 序列号: 0001E7A2D3C4BusType为7即BusTypeUsb，看到这个值就说明当前盘符确实对应USB设备。两个序列号一致，说明USB设备层面的实例ID和SCSI层查询到的序列号对上了，信息可靠。
4. 编译运行与几个必须注意的配置
4.1 编译环境准备与链接库
代码使用Win32 API和SetupAPI，不依赖运行库之外任何第三方组件。编译环境用Visual Studio 2019或2022均可。如果是VS 2019以上版本，源代码里已经加好了#pragma comment(lib, "setupapi.lib")，不需要手动在工程属性里再配置一次。
只需要注意，创建项目时选择“控制台应用程序”，语言选C++，然后把上面的代码完整复制进去编译即可。如果你的代码放在纯C环境里，需要把sscanf_s改成sscanf，把文件后缀改成.cpp，否则编码类型会有差异。
4.2 管理员权限、平台位数与实际输出
程序建议以管理员身份运行。原因在于CreateFile打开“\.\E:”这种设备路径时，如果当前用户无管理员权限，在某些Windows配置下会被拒绝访问。U盘如果是普通数据盘还好，遇到量产过、带只读分区或者厂商特殊协议的U盘，普通权限直接打不开设备句柄。
平台位数建议编译为x64。现在的主流系统是64位，U盘主控驱动也基本都是64位。如果你在Windows 10/11上跑32位版本也没问题，只要系统有对应的WOW64支持，但这属于没必要踩的坑。
运行环境不需要额外安装Windows SDK，系统自带的头文件和库就能编译通过。
4.3 扩展为命令行工具或GUI工具的建议
这套源码是控制台输出，实际做工具时一般不会直接这么裸用。有两个扩展方向比较实用。
一个是改成命令行扫描模式，通过参数指定盘符。例如UDetect.exe E:，程序只对指定盘符做检测，输出格式化后的JSON字符串，这样就能被其他脚本调用，做自动化巡检。
另一个方向是做成GUI展示。界面左边列出所有USB U盘，右侧显示选中的U盘详细参数。实现上不需要改源码逻辑，只需要把std::cout输出改成回调函数，把数据填充到列表控件里就行。核心的枚举和查询函数可以原样保留。
5. 常见问题与排查技巧实录
5.1 读不到盘符怎么办
程序输出里USB设备节点有记录，但盘符列表完全没有这个设备，这种场景最常见的原因是U盘在系统里被识别为无介质设备，也就是常说的“掉盘”。遇到这种情况，硬件层面先换USB口、换电脑试，如果所有机器都不出盘符，基本上主控已经进入异常状态，需要用量产工具重新初始化。
软件层面还有一种情况：U盘存在但没有被分配盘符。在磁盘管理里能看到磁盘，显示“未分配”。此时GetLogicalDriveStringsA当然遍历不到它。这种情况的典型场景是U盘量产失败之后的分区处于RAW状态，或者刚拿到手的新主控板还没写入分区表。此时程序可以用SetupAPI按磁盘设备路径枚举PhysicalDrive，绕过盘符直接读取存储设备信息。但这个扩展比较复杂，普通检测场景盘符足够用。
5.2 读出来的序列号是空的
如果IOCTL查询成功，BusType也是USB，但SerialNumber是空字符串或者全空格，这说明U盘主控固件根本没写入序列号，或者量产工具生成序列号时使用了非法字符。
这种情况在山寨U盘上特别多。VID和PID可能是盗用的正品ID，但序列号因为量产参数设置问题没有正确生成。从检测角度看，这本身就是一个风险信号。正品U盘几乎都有序列号，批量采购检测如果发现同型号U盘里有一批序列号全空，基本可以判断来源有问题。
还有一种情况是某些U盘的序列号包含非ASCII字符，程序里直接按char读取中文或者日文字符可能乱码。如果需要处理这类设备，建议代码里再做一次从UTF-8或GBK到宽字符的转换。
5.3 读卡器、主控兼容性和扩容盘判断
很多U盘本身其实是读卡器加存储卡方案，比如一些两用U盘、手机U盘，甚至某些“固态U盘”。这类设备插上电脑后，BusType显示的是USB，但Vendor字段往往写的是读卡器桥接芯片的厂商，产品字段是“Card Reader”之类。这时候序列号是读卡器主控的，不是存储卡的。程序把两条信息都打出来，就是为了让使用者能区分这一类混血设备。
扩容盘的判断逻辑也需要多一步。以太网设备序列号正常不代表容量没问题，序列号只能证明主控的真实身份，而容量真假要靠写入读取测试或者量产工具读取Flash实际型号来确认。本工具的定位是提供硬件身份信息，在这个基础上再叠加容量验证逻辑，就是一套完整的U盘质检工具。
5.4 排错速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 程序找到设备节点但盘符为空 | 量产失败/无分区 | 磁盘管理确认，用量产工具重建分区 |
| CreateFile打开设备失败 | 权限不足或盘符被占用 | 以管理员运行，关闭资源管理器窗口 |
| 序列号全为0或空格 | 固件未写入iSerialNumber | 标记为可疑设备，重点检查来源 |
| BusType不是7 | 设备走的是非USB驱动栈 | 看Vendor/Product字段确认桥接芯片 |
| 一个U盘显示多个盘符 | 多分区或带CDROM区 | 用设备节点信息区分不同分区归属 |
| 结果和WMI不一致 | 缓存或查询接口差异 | 以IOCTL设备层结果为准，WMI只做参考 |
最后再分享一个小技巧。做U盘启动盘的时候，比如用Rufus或Ventoy写入镜像，如果担心选错盘，先把本工具跑一遍，记下目标U盘的序列号后几位，再在写入工具里对这个号。写入工具一般只显示盘符和容量，两个一模一样型号的U盘很容易拿错，但序列号是唯一的，照着这个选就不会出事故。
本文还有配套的精品资源，点击获取
