简介一份使用Visual C编写的项目源码演示如何通过Windows注册表获取EDID扩展显示标识数据二进制数据并解析出显示器设备参数面向需要学习注册表编程、硬件信息读取或显示设备管理的开发者。压缩包共21个文件体积仅2.38MB以.h头文件和.cpp源文件为主同时包含工程配置、对话框资源及说明文档项目结构清晰便于在Visual Studio中直接打开研读。已有1713人学习下载。源码按模块拆分注册表封装类负责打开和查询键值EDID解析类专门处理128字节数据块MFC对话框负责结果展示完整演示了定位HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video下的显示设备子键、读取EDID键值、逐字节解释制造商与型号、计算最大分辨率和刷新率等步骤。对于想掌握注册表API、二进制数据分析及显示器通信机制的开发者具有很高的参考价值项目代码可直接复用为系统监测、硬件诊断或显示器配置管理工具的基础也适合作为课程设计或项目实战参考资料。1. 用 VC 读取注册表 EDID一套源码把显示器信息彻底搞明白用 VC 写一个从 Windows 注册表读取 EDID、解析显示器设备信息的小工具听起来冷门实际上在硬件资产管理、显示器质检、屏幕信息采集这类场景里非常好用。EDID 是显示器出厂时固化的一块 128 字节数据里面带着厂商、序列号、生产周期、物理尺寸和最佳分辨率Windows 启动时会把这份原始数据回写到注册表里所以只要你机器能点亮屏幕就能把它读出来。这套源码解决的就是“不接任何额外硬件纯软件拿到显示器完整信息”的问题适合做设备上报脚本的信息采集端也适合给显卡驱动排查当参照。我自己用这套思路拆过几台机器读出来的数据和厂商标称几乎一致但过程里也踩了几个容易翻车的地方。2. EDID 在系统里的存放链路为什么注册表是最稳的读法2.1 显示器信息是怎么进注册表的显示器里有一颗很小的 EEPROM存着 VESA 标准定义的 EDID 数据块。显卡上电后会通过 DDC 通道本质是 I2C 总线去读这颗芯片读回来的 128 字节带扩展块的话是 256 字节交给 Windows 的显示器驱动链最后由 PnP 管理器写进注册表。具体落点是这个名字很长的键HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\{MonitorId}\{InstanceId}\Device Parameters\EDID这个键的类型是 REG_BINARY值就是显示器的原始 EDID 字节。注意{MonitorId}不是人类可读的显示器型号而是 PnP 硬件 ID常见格式是DEL40F9这种厂商三字母编码加数字{InstanceId}是一段 GUID。路径里带空格的字符串要用宽字符处理后面代码里我会注意这一点。这里有一个关键点凡是系统能正常枚举出来的显示器这个键就一定存在。因为显示器驱动在枚举设备时会把 EDID 当作物资源属性回写。所以只要你在“显示设置”里能看到这块屏用代码去注册表里读就一定拿得到数据这是整套方案最稳的根基。2.2 三种读取方式对比API、WMI 和注册表原始字节很多人第一反应是用EnumDisplayDevices这个 API它能枚举显卡和显示器返回设备名、设备描述、状态这些字段。但它的结构体里根本没有 EDID 原始数据的字段只能拿到一个“显示器设备名”有时候这个设备名还是显卡驱动编的比如“通用即插即用监视器”信息量约等于零。第二个常见方案是走 WMI 的WmiMonitorID它能拿到厂商名、产品名、序列号这些字符串。但有个问题WMI Provider 返回的是已经格式化好的字符串不是原始字节不同系统版本上字段长度和内容格式不完全一致而且拿不到物理尺寸和 DTD 里的分辨率时序。我用它做过一轮排查发现部分系统上返回的序列号被截断最后放弃了。注册表读法的优势在“原始”。你拿到的是显示器固件里原封不动的 EDID 字节想解析哪个字段自己说了算不受系统层二次加工影响。这对于做资产台账工具来说很重要字段口径统一不会因为系统版本不同而拿到五花八门的字符串。代价是解析逻辑要自己写但 EDID 结构是公开标准主要字段固定且好算代码量并不大。2.3 三种方式的选型关系读取方式能拿到什么是否含原始 EDID 字节依赖适用场景EnumDisplayDevices设备名、描述、状态标志否user32.dll判断屏幕是否连接、是否为镜像WMI WmiMonitorID厂商/型号/序列号字符串否已格式化WMI 服务快速展示不要求字段完整注册表 EDID 键完整 128/256 字节是无系统自带深度解析、资产管理、离线分析我一般会把注册表读法作为主解析通道WMI 做交叉验证注册表读到原始字节自己解WMI 的字符串拿来核对厂商名对不对。两条路各有用途真要做信息采集工具注册表这条最值得写进源码。3. 注册表定位与 C 读取解析完整实现3.1 注册表键路径结构和定位思路读取的第一步不是直接拼路径而是枚举。因为DISPLAY子键下有多个{MonitorId}子键每个{MonitorId}下还有多个 GUID 实例子键后面避坑章节会讲为什么会有多个。正确姿势是两层枚举先枚举DISPLAY下的所有显示器子键再对每个显示器子键枚举实例最后拼出Device Parameters\EDID路径。子键名里的非 ASCII 字符和 GUID 里的连字符都要用宽字符 API 处理std::wstring拼路径最省事。枚举子键用RegEnumKeyExW它按索引依次返回子键名返回ERROR_NO_MORE_ITEMS就说明枚举完了。3.2 读取 EDID 原始字节的 C 代码这一节给核心读取函数。它会打开指定显示器的Device Parameters子键先查 EDID 值的大小再分配缓冲区读取#include windows.h #include winreg.h #include vector #include string #include cstdio // 打开指定显示器实例的 Device Parameters 子键读取 EDID 原始字节 bool ReadMonitorEDID(const std::wstring displaySubKey, const std::wstring instanceSubKey, std::vectorunsigned char edid) { std::wstring path LSYSTEM\\CurrentControlSet\\Enum\\DISPLAY\\ displaySubKey L\\ instanceSubKey L\\Device Parameters; HKEY hKey nullptr; // KEY_WOW64_64KEY即使编译成 32 位程序也强制读 64 位注册表视图 LONG ret RegOpenKeyExW(HKEY_LOCAL_MACHINE, path.c_str(), 0, KEY_READ | KEY_WOW64_64KEY, hKey); if (ret ! ERROR_SUCCESS) { return false; } DWORD size 0; DWORD type 0; // 第一次调用只拿大小和类型EDID 常见为 128 字节或 256 字节 ret RegQueryValueExW(hKey, LEDID, nullptr, type, nullptr, size); if (ret ! ERROR_SUCCESS || type ! REG_BINARY) { RegCloseKey(hKey); return false; } edid.resize(size); // 第二次调用把数据读进缓冲区 ret RegQueryValueExW(hKey, LEDID, nullptr, type, edid.data(), size); RegCloseKey(hKey); return ret ERROR_SUCCESS size 128; }逻辑不复杂第一次RegQueryValueExW传空缓冲区让系统把值的大小和类型告诉我们第二次才真正把字节拷进std::vector。这里有两个关键参数值得说明。第一个是KEY_WOW64_64KEY如果你在 64 位 Windows 上跑 32 位程序不带这个标志的话注册表访问会被重定向到 WOW64 视图可能找不到 EDID 键或者读到不完整的值第二个是REG_BINARY类型判断EDID 键在规范里一定是二进制但某些显卡驱动异常时可能写错类型做防御式判断更稳。读取成功后edid里就是完整的 EDID 字节流。接下来是枚举所有显示器的调用方// 枚举注册表 DISPLAY 节点下的所有显示器实例 void EnumerateAllMonitors() { const wchar_t* base LSYSTEM\\CurrentControlSet\\Enum\\DISPLAY; HKEY hRoot nullptr; if (RegOpenKeyExW(HKEY_LOCAL_MACHINE, base, 0, KEY_READ | KEY_WOW64_64KEY, hRoot) ! ERROR_SUCCESS) { return; } for (DWORD m 0; ; m) { wchar_t displayKey[256] {0}; DWORD keyLen 256; // 枚举第 m 个显示器子键比如 DEL40F9 if (RegEnumKeyExW(hRoot, m, displayKey, keyLen, nullptr, nullptr, nullptr, nullptr) ! ERROR_SUCCESS) { break; } std::wstring monPath std::wstring(base) L\\ displayKey; HKEY hMon nullptr; if (RegOpenKeyExW(HKEY_LOCAL_MACHINE, monPath.c_str(), 0, KEY_READ | KEY_WOW64_64KEY, hMon) ! ERROR_SUCCESS) { continue; } // 对每个显示器子键再枚举实例子键GUID for (DWORD i 0; ; i) { wchar_t instKey[256] {0}; DWORD instLen 256; if (RegEnumKeyExW(hMon, i, instKey, instLen, nullptr, nullptr, nullptr, nullptr) ! ERROR_SUCCESS) { break; } std::vectorunsigned char edid; if (ReadMonitorEDID(displayKey, instKey, edid)) { MonitorInfo info; if (ParseEDID(edid.data(), info)) { // PrintMonitorInfo 按统一格式输出解析结果 PrintMonitorInfo(info, edid.data()); } } } RegCloseKey(hMon); } RegCloseKey(hRoot); }这段枚举逻辑覆盖了“多显卡多显示器”的情况。每个显示器子键下的 GUID 实例可能不止一个全部读一遍再由上层去重即可。注意RegEnumKeyExW的缓冲区长度参数在调用前要赋成缓冲区实际大小返回值不是ERROR_SUCCESS就结束循环不要无脑加一继续。3.3 EDID 二进制解析代码与字段映射拿到 128 字节后按 EDID 1.3 标准布局解析。先看整体字段布局这张表后面解析代码会用到偏移长度字段含义编码说明0x008固定头部00 FF FF FF FF FF FF 000x082厂商 ID3 个字母每个 5 bit大端存放0x0A2产品 ID小端无符号0x0C4序列号小端 uint320x101生产周0xFF 表示未知0x111生产年值 19900x151可视水平尺寸单位 cm0 表示未知0x161可视垂直尺寸单位 cm0 表示未知0x3618第一个详细时序描述符 DTD像素时钟 有效/消隐区域0x7E1扩展块数量0 表示没有扩展块0x7F1校验和前 127 字节和 该值 256 的倍数解析函数如下#include cmath struct MonitorInfo { char vendor[4]; // 厂商三字母 unsigned short productId; // 产品 ID unsigned short year; // 生产年份 unsigned char week; // 生产周 float sizeInch; // 物理尺寸英寸 unsigned short hActive; // 水平有效像素 unsigned short vActive; // 垂直有效像素 unsigned int refresh; // 刷新率Hz }; // 解析 EDID 前 128 字节基础块 bool ParseEDID(const unsigned char* d, MonitorInfo out) { // 头部固定字节校验避免把扩展块或损坏数据当 EDID if (d[0] ! 0x00 || d[1] ! 0xFF || d[2] ! 0xFF || d[7] ! 0x00) { return false; } // 厂商 ID大端拼成 uint16再按 5bit 一位拆三个字母 unsigned short mfr (unsigned short)((d[8] 8) | d[9]); int c1 (mfr 10) 0x1F; // 第一个字母A1 int c2 (mfr 5) 0x1F; // 第二个字母 int c3 mfr 0x1F; // 第三个字母 out.vendor[0] (char)(A c1 - 1); out.vendor[1] (char)(A c2 - 1); out.vendor[2] (char)(A c3 - 1); out.vendor[3] 0; // 产品 ID 是小端 out.productId (unsigned short)((d[11] 8) | d[10]); out.year (unsigned short)(1990 d[17]); out.week d[16]; // 屏幕物理尺寸宽和高都是 cm0 表示显示器没填 unsigned char w_cm d[21]; unsigned char h_cm d[22]; if (w_cm 0 h_cm 0) { // 对角线长度换算成英寸注意这是 cm 不是英寸 out.sizeInch (float)(std::sqrt((double)w_cm * w_cm (double)h_cm * h_cm) / 2.54); } else { out.sizeInch 0.0f; } // 第一个 DTD 从偏移 0x36 开始共 18 字节 const unsigned char* dtd d 0x36; unsigned int pixelClock (unsigned int)(dtd[0] | (dtd[1] 8)) * 10000; // 水平有效/消隐低 8 位在对应字节高 4 位在 dtd[4] unsigned int hActive (dtd[2] | ((dtd[4] 0xF0) 4)); unsigned int hBlank (dtd[3] | ((dtd[4] 0x0F) 8)); // 垂直有效/消隐低 8 位在 dtd[5]/dtd[6]高 4 位在 dtd[7] unsigned int vActive (dtd[5] | ((dtd[7] 0xF0) 4)); unsigned int vBlank (dtd[6] | ((dtd[7] 0x0F) 8)); unsigned int hTotal hActive hBlank; unsigned int vTotal vActive vBlank; // 刷新率 像素时钟 / (总行 * 总列)像素时钟单位是 10kHz out.hActive (unsigned short)hActive; out.vActive (unsigned short)vActive; out.refresh (vTotal 0 || hTotal 0) ? 0 : (pixelClock / (hTotal * vTotal)); return true; }解析的核心是把 128 字节当成一个紧凑位流来看而不是按字节的“直观语义”读。厂商标识是最典型的例子三个字母挤在两个字节里每个字母占 5 bitmfr 10拿第一组 5 bitmfr 5拿第二组mfr 0x1F拿第三组。字母 A 对应数值 1所以产出字符串时要减一再加A。DTD 里有效区域和消隐区域的高 4 位分散在另一个字节中这是 EDID 里最容易算错的部分。hActive的算法是“低 8 位 高 4 位左移 8 位”也就是把高位拼到 16 位整数的上半段。刷新率公式pixelClock / (hTotal * vTotal)可以直接算出一台显示器在标准时序下的真实刷新率不用去看系统的“刷新率”显示这个数值在显示链路排查里很有用。3.4 解析输出与主要参数说明解析完成后的输出格式我一般做成这样Vendor : DEL Product ID : 0x1234 Serial : 1122334455 Year / Week : 2019 / W12 Physical Size : 23.8 inch (523mm x 294mm) Best Timing : 1920x1080 60Hz Checksum : VALID厂商、产品 ID、序列号、生产周期这些字段直接对应前面表格里的偏移物理尺寸我习惯同时输出厘米和英寸因为换算公式在部分显示器上有 0.2 到 0.5 英寸的偏差只给一个单位容易让下游误判。Best Timing来自第一个 DTD很多显示器把最佳分辨率放在这一条后面的 DTD 放低分辨率的备用时序所以取第一条就够。这套代码跑通后接在资产扫描脚本里就是一个标准的“显示器上报模块”读取注册表原始 EDID解析成结构化字段再和数据库里的资产记录比对。我自己给某单位做的设备台账工具里这部分稳定运行了一整年中途除了新机型头一次插入时需要更新厂商编码对照表几乎没有维护成本。4. 避坑五个让解析结果翻车的细节4.1 同一台显示器被枚举出多个实例解析出三条重复记录现象系统里明明只有两台显示器程序却打印出三四条解析结果而且厂商、产品 ID、序列号完全相同的记录出现了两三次。还有的实例读取失败但设备明明亮着。原因DISPLAY子键下每个显示器有多个 GUID 实例子键。显卡驱动在分辨率切换、独显直连切换、外接显示器热插拔之后注册表里会留下历史实例不清理。扩展坞、视频采集卡还会贡献额外的虚拟实例。解决解析完以厂商、产品 ID、序列号三元组做去重相同三元组只保留第一次成功的结果。序列号可以用d[12]到d[15]拼成 uint32 再比对。读取失败的实例单独写日志不直接丢弃这样既能排查热插拔历史又不会重复上报。4.2 厂商 ID 用位段结构体解出来是乱码现象屏幕上明明是某品牌的显示器解析出来的厂商名却是两个错位字母加一个不相关的字母。原因EDID 厂商字段是“一个 16 位整数塞三个 5 bit 字母”的紧凑布局。有人习惯定义结构体加位段来读比如unsigned char c1 : 5;。但位段在 Windows 上的内存布局依赖编译器和字节序直接映射字节数组经常方向搞反导致三个字母整体错位。解决用移位运算代替位段。先把d[8]、d[9]按大端拼成unsigned short再分别右移 10、5、0 位做掩码。这套写法在任何编译器上结果一致。我见过不止一个初版工具毁在这个细节上改完移位之后一次通过。4.3 屏幕尺寸“英寸数”算出 63 寸或 0 寸现象27 寸的显示器解析出来是 63 寸或者干脆是 0 寸。拿着这个数据去对资产表完全对不上。原因EDID 的d[21]、d[22]单位是厘米不是英寸。有人直接拿水平的厘米数除 2.54 当“长边英寸”也有人两个值都是 0显示器固件未填写时没做判断尺寸计算就出错。解决先判断宽高是否为 0再按对角线公式sqrt(w_cm*w_cm h_cm*h_cm) / 2.54换算英寸。同时保留厘米原始值输出。另外要有个预期厂商标称的是外壳对角的公称尺寸EDID 里填的是可视区域差 0.3 英寸左右是正常的不要拿这个差异去对显示器吹毛求疵。4.4 32 位程序在 64 位系统上读不到 EDID 键现象开发机上编译运行一切正常打包成 Release 后拷到别的 Windows x64 机器上程序启动后一个显示器都扫不到。原因项目编译目标是 Win32运行时被 WOW64 重定向。RegOpenKeyExW不带KEY_WOW64_64KEY时打开的SYSTEM\CurrentControlSet\Enum\DISPLAY是 32 位视图而显卡驱动回写 EDID 走的是 64 位注册表视图两边数据不一致。解决所有注册表调用统一带KEY_READ | KEY_WOW64_64KEY32 位进程就强制读 64 位视图。如果工具要同时跑在 32 位和 64 位系统上用_WIN64条件宏控制标志位或者干脆只出 x64 包省掉这层麻烦。我后来在发布脚本里强制检查输出目标位数再也没出过这种问题。4.5 带 CEA 扩展块的 EDID 被误当成第二台显示器现象部分 4K 显示器读出的 EDID 是 256 字节程序把第二个 128 字节也拿去解析结果多了个“幻影显示器”分辨率时序还特别离谱。原因HDMI/DP 显示器的 EDID 在基础块后跟着 CEA-861 扩展块里面存放 4K 时序、色深、音频支持等数据。扩展块的格式和基础 EDID 不同但头几个字节恰好能被一些宽松的解析代码“蒙混过关”。解决只解析前 128 字节的基础块用d[126]判断扩展块数量大于 0 时打印日志说明“含 N 个扩展块跳过”。解析 DTD 时也只在第一个 DTD 足够拿到最佳分辨率时就停止不要硬扫后续区域。显示器信息采集中基本用不到扩展块跳过反而更干净。5. 收尾技巧把解析器改成离线工具再和系统信息交叉验证5.1 给解析函数加一个文件输入模式注册表读法依赖系统在线但平时排查显示器固件、分析别人导出的.bin文件时需要能直接解析文件的入口。给ParseEDID包一层文件读取代码很短// 从 .bin 文件读取 EDID 并解析常用于离线分析固件 dump bool ParseEDIDFromFile(const char* filePath, MonitorInfo out) { FILE* fp nullptr; fopen_s(fp, filePath, rb); if (!fp) return false; unsigned char buf[256] {0}; size_t n fread(buf, 1, sizeof(buf), fp); fclose(fp); if (n 128) return false; return ParseEDID(buf, out); }文件模式用来验证从系统里提取出来的 EDID 是否完整也方便把解析器当成独立命令行工具用。我一般会在调用前先看文件大小128 字节是基础块256 字节带扩展块其他长度直接拒绝。5.2 三个交叉验证项确认解析结果没跑偏解析器写完别急着收工做三个对照验证项对照来源判定标准最佳分辨率系统显示设置里的“分辨率”下拉框解析出的 DTD 分辨率应和系统推荐分辨率一致刷新率显示设置→高级显示设置误差不超过 1Hz物理尺寸拿卷尺量屏幕可视区域误差在 0.5 英寸内前两项验证了解析是否正确第三项验证厂商填的物理尺寸是否可信。这三项全过了解析器基本可以放心进资产采集工具。这几年做显示器信息采集印象最深的坑就是尺寸换算第一版工具把水平厘米直接当英寸除一台 27 寸屏报成了 63 寸差点被当成数据采集事故处理。从那以后我每次跑完解析器都会强制走一遍“物理尺寸对照”拿着尺子量一下再确认输出。这个习惯虽然土但确实能挡住一大半低级错误。希望帮到你。本文还有配套的精品资源点击获取