简介这份VC项目源码聚焦Windows系统下显示器EDID信息的读取与解析面向具备一定C基础、希望深入系统编程与硬件信息获取的开发者。项目通过Windows注册表API定位HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video下的显示设备子键读取名为EDID的二进制值并按EDID规范解析出制造商、型号、物理尺寸、最大分辨率与刷新率等参数最终转换为可读的显示器信息。资源包共21个文件约2.38MB以h头文件与cpp源文件为核心辅以vcproj工程文件、rc资源脚本、ico图标及ReadMe说明工程结构完整可直接编译运行。目前已有1713人学习下载。读者可借此掌握RegOpenKeyEx、RegQueryValueEx等注册表操作理解EDID的128字节结构与二进制数据转换方法并学习将底层硬件信息以友好方式呈现适用于系统监测、硬件诊断与显示器配置管理等场景。1. 从一块黑屏说起为什么我要把 EDID 从注册表里挖出来去年帮一个做多屏拼接的客户排查问题现场六台显示器系统识别出来五台是同一型号剩下一台分辨率死活上不去Windows 显示设置里连原生分辨率选项都没有。换线、换口、换驱动全试过最后用 MonitorInfoView 一读 EDID发现那台显示器的 EDID 校验和是错的——厂商烧录时算错了 checksumWindows 直接把它当未知显示器处理只给个 1024×768 兜底。问题定位到这一步剩下的就是改 EDID 重烧但前提是你得先把原始 EDID 从系统里完整读出来。这就是 VC 项目源码 Monitor 注册表获取 EDID 解析显示器设备信息 这类工具存在的意义。它干的事很具体通过 Windows 注册表路径HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY遍历所有显示器设备节点读取每个节点下的 EDID 二进制值然后按 VESA 标准解析出厂商代码、产品代码、序列号、生产周、物理尺寸、支持的分辨率列表、刷新率范围这些字段。适合做显示设备管理、KVM 切换器兼容性测试、批量部署时硬件资产盘点、以及像我这样需要排查显示器兼容性问题的工程师。源码是 VC 工程意味着可以直接在 Visual Studio 里编译调试不需要额外装运行时。2. EDID 数据结构与注册表读取路径先搞懂 128 字节里装了什么2.1 EDID 的 128 字节布局与关键字段偏移EDID 全称 Extended Display Identification Data标准版本 1.3 和 1.4 都是 128 字节一个 block1.4 可以扩展多个 block。前 8 字节是固定头00 FF FF FF FF FF FF 00用来标识这是一个合法的 EDID 数据块。第 8 到第 17 字节是厂商和产品信息区其中厂商 ID 用 2 字节表示每个字符占 5 bit需要做位运算还原成三个字母。产品代码 2 字节小端序序列号 4 字节小端序生产周 1 字节生产年份 1 字节加 1990 才是实际年份。第 18 到 24 字节是 EDID 版本和视频输入参数第 25 到 34 字节是屏幕尺寸和 gamma其中水平尺寸和垂直尺寸单位是厘米gamma 值需要除以 100 再加 1。第 35 到 37 字节是支持的特性位包括待机、挂起、模拟输入等标志。第 38 到 53 字节是色度坐标第 54 到 125 字节是四个 18 字节的描述符块通常第一个是详细时序描述符包含像素时钟、水平有效像素、垂直有效行数等后面几个可能是显示器名称、序列号字符串或范围限制描述符。最后 1 字节是校验和要求前 127 字节之和模 256 等于 0。解析时最容易翻车的是厂商 ID 的 5 bit 编码。比如厂商代码 DEL 对应二进制 00100 00101 01100合并成 16 bit 是 0x10AC但注册表里存的是小端序读出来要按字节交换再解码。很多网上抄来的代码在这里直接按 ASCII 处理结果厂商名全是乱码。2.2 注册表路径遍历与 EDID 值提取Windows 把每个显示器的 EDID 存在注册表HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY下面每个显示器是一个子键键名类似DELA0B2这种格式下面还有Device Parameters子键EDID 就存在这个子键的EDID值里类型是REG_BINARY。但注意不是所有显示器都会在DISPLAY下出现有些走 DisplayPort 的显示器可能挂在HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY的更深层子键里需要递归遍历。遍历逻辑用 Windows API 写起来不复杂核心是RegOpenKeyEx、RegEnumKeyEx、RegQueryValueEx三个函数配合递归。下面这段代码是遍历并提取 EDID 的核心逻辑我把它拆成独立函数方便复用// 递归遍历注册表键查找名为 EDID 的 REG_BINARY 值 bool EnumDisplayKeys(HKEY hRoot, const std::wstring subKey, std::vectorBYTE edidOut) { HKEY hKey nullptr; // 打开子键KEY_READ 权限足够读取 EDID LONG ret RegOpenKeyExW(hRoot, subKey.c_str(), 0, KEY_READ, hKey); if (ret ! ERROR_SUCCESS) return false; // 先尝试直接读取当前键下的 EDID 值 BYTE buf[256] {0}; DWORD bufSize sizeof(buf); DWORD type 0; ret RegQueryValueExW(hKey, LEDID, nullptr, type, buf, bufSize); if (ret ERROR_SUCCESS type REG_BINARY bufSize 128) { edidOut.assign(buf, buf bufSize); RegCloseKey(hKey); return true; } // 当前键没有 EDID递归遍历所有子键 WCHAR childName[256] {0}; DWORD childIndex 0; DWORD nameLen 256; while (RegEnumKeyExW(hKey, childIndex, childName, nameLen, nullptr, nullptr, nullptr, nullptr) ERROR_SUCCESS) { std::wstring childPath subKey L\\ childName; if (EnumDisplayKeys(hRoot, childPath, edidOut)) { RegCloseKey(hKey); return true; } childIndex; nameLen 256; } RegCloseKey(hKey); return false; }这段代码的逻辑说明RegOpenKeyExW打开指定子键如果当前键下直接有EDID值且类型是REG_BINARY且长度不小于 128 字节就拷贝出来返回。否则用RegEnumKeyExW枚举所有子键递归调用自身。参数上注意KEY_READ就够了不需要写权限bufSize传入时是缓冲区大小返回时是实际数据大小所以每次循环要重置。RegEnumKeyExW的nameLen参数在每次调用前必须重置为缓冲区字符数否则第二次调用会失败这是血泪经验。调用入口一般从HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY开始但有些系统上显示器信息也可能在HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY的兄弟节点下稳妥做法是同时遍历DISPLAY和PCI下的显示相关节点。不过对于大多数场景只遍历DISPLAY已经能覆盖 95% 以上的显示器。2.3 解析函数实现从字节数组到可读字段拿到 EDID 字节数组后解析成可读字段需要按偏移逐段处理。下面这个解析函数覆盖了最常用的字段包括厂商 ID、产品代码、序列号、生产信息、物理尺寸和首选分辨率struct EdidInfo { std::string manufacturer; // 三字母厂商代码 uint16_t productCode; // 产品代码 uint32_t serialNumber; // 序列号 int week; // 生产周 int year; // 生产年份 int widthCm; // 水平尺寸(cm) int heightCm; // 垂直尺寸(cm) int prefWidth; // 首选水平分辨率 int prefHeight; // 首选垂直分辨率 double prefRefresh; // 首选刷新率 }; bool ParseEdid(const std::vectorBYTE edid, EdidInfo info) { if (edid.size() 128) return false; // 校验固定头 const BYTE header[8] {0x00,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x00}; if (memcmp(edid.data(), header, 8) ! 0) return false; // 厂商 ID偏移 8-95bit 编码 uint16_t mfg (edid[8] 8) | edid[9]; info.manufacturer.clear(); info.manufacturer (char)(((mfg 10) 0x1F) A - 1); info.manufacturer (char)(((mfg 5) 0x1F) A - 1); info.manufacturer (char)((mfg 0x1F) A - 1); // 产品代码偏移 10-11小端序 info.productCode edid[10] | (edid[11] 8); // 序列号偏移 12-15小端序 info.serialNumber edid[12] | (edid[13] 8) | (edid[14] 16) | (edid[15] 24); // 生产周和年份 info.week edid[16]; info.year edid[17] 1990; // 物理尺寸 info.widthCm edid[21]; info.heightCm edid[22]; // 首选时序第一个描述符在偏移 54 int hActive ((edid[56] 0xF0) 4) | edid[58]; int vActive ((edid[59] 0xF0) 4) | edid[61]; info.prefWidth hActive; info.prefHeight vActive; // 像素时钟单位 10kHz除以水平总像素和垂直总行数得刷新率 int pixClock (edid[55] 8) | edid[54]; int hTotal hActive ((edid[57] 0x0F) 8) edid[59]; int vTotal vActive ((edid[61] 0x0F) 8) edid[62]; if (hTotal 0 vTotal 0) { info.prefRefresh (pixClock * 10000.0) / (hTotal * vTotal); } return true; }参数说明edid是前面从注册表读出来的字节数组长度至少 128。厂商 ID 的位运算逻辑是标准规定的mfg 10取最高 5 bitmfg 5取中间 5 bitmfg 0x1F取最低 5 bit每个值加A - 1还原成字母。首选时序的像素时钟单位是 10kHz所以乘 10000 换算成 Hz再除以水平总像素和垂直总行数得到刷新率。注意edid[59]在水平总像素和垂直有效行数里都出现了这是标准里的位复用读的时候要按位掩码区分。3. 在 VS 里把工程跑起来编译、调试与数据验证3.1 工程配置与依赖项设置拿到源码包后用 Visual Studio 打开.sln或.vcxproj文件。这类 VC 项目通常依赖advapi32.lib来调用注册表 API如果编译时报RegOpenKeyExW未解析的外部符号就在项目属性里检查链接器输入是否包含advapi32.lib。字符集方面代码里用了W后缀的宽字符 API项目属性里字符集要设成Unicode否则RegOpenKeyExW和RegQueryValueExW的字符串参数类型对不上。如果源码里用了std::vector和std::string确保包含vector和string头文件。有些老工程会默认用 MFC 的CString那就需要把#include afx.h加上但纯 Win32 API 方案更轻量我一般会建议把 MFC 依赖去掉换成标准库容器编译出来的 exe 体积能小一半。调试时建议在EnumDisplayKeys函数入口下断点观察subKey参数的变化确认遍历路径是否正确。如果断点没命中说明起始路径写错了检查是不是把Enum\DISPLAY写成了Enum\Display注册表路径大小写不敏感但拼写必须一致。3.2 用 PowerShell 交叉验证读取结果代码跑通后怎么确认读出来的 EDID 是对的最直接的办法是用 PowerShell 读同一个注册表值做对比。下面这段命令可以列出所有显示器节点的 EDID 长度和校验和# 遍历 DISPLAY 下所有子键输出 EDID 长度和校验和 Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Enum\DISPLAY -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $edid (Get-ItemProperty -Path $_.PSPath -Name EDID -ErrorAction SilentlyContinue).EDID if ($edid -and $edid.Length -ge 128) { $sum 0 for ($i 0; $i -lt 127; $i) { $sum $edid[$i] } $check (256 - ($sum % 256)) % 256 [PSCustomObject]{ Path $_.PSPath Length $edid.Length Checksum $check StoredCheck $edid[127] Valid ($check -eq $edid[127]) } } } | Format-Table -AutoSize这段脚本的逻辑是递归遍历DISPLAY下所有子键读取EDID属性如果长度不小于 128 就计算前 127 字节之和模 256 的补数和存储的第 128 字节比较。Valid为True说明 EDID 校验通过。如果代码读出来的厂商名和 PowerShell 算出来的校验和都对得上基本可以确认解析逻辑没问题。注意 PowerShell 里$edid是byte[]类型索引访问返回的是byte求和时自动转成int不会溢出。3.3 常见显示器 EDID 字段对照表解析出来的字段怎么判断是否合理下面这张表列出了几个典型厂商的 EDID 特征值可以用来快速验证解析结果字段偏移典型值示例说明固定头0-700 FF FF FF FF FF FF 00必须完全匹配厂商 ID8-90x10AC → DEL5bit 编码位运算还原产品代码10-110xA0B2小端序不同型号不同序列号12-150x12345678小端序可能为 0生产周160x1E (30)1-53 有效生产年份170x1F (31) → 2021加 1990水平尺寸2152 (cm)0 表示未定义垂直尺寸2232 (cm)0 表示未定义校验和1270xXX前 127 字节和模 256 补数如果厂商 ID 解析出来是乱码先检查字节序是不是搞反了。如果生产年份算出来是 1900 或 2155 这种离谱值说明偏移读错了检查是不是把版本号字段当成了年份。校验和不通过但其他字段看起来正常可能是 EDID 被截断或损坏这种显示器在 Windows 里通常表现为通用即插即用监视器。4. 避坑与排查EDID 读取解析中最容易翻车的五个点4.1 现象遍历注册表读不到任何 EDID返回空原因起始路径写错或者当前进程没有读取HKLM的权限。有些系统上DISPLAY节点下还有一层Default_Display之类的中间键直接遍历DISPLAY的第一层子键可能全是空壳。解决把起始路径改成HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY后先用RegEnumKeyExW打印所有子键名确认层级结构。权限问题用管理员身份运行程序即可读取HKLM只需要KEY_READ不需要写权限。4.2 现象厂商 ID 解析出来是 ABC 或乱码原因字节序处理错误。注册表里 EDID 的厂商 ID 两个字节是按大端序存储的但有些代码按小端序读或者位运算的移位方向搞反了。解决确认mfg (edid[8] 8) | edid[9]这个顺序然后按(mfg 10) 0x1F、(mfg 5) 0x1F、mfg 0x1F取三段。如果还是不对把mfg的十六进制值打印出来对照 EDID 标准文档里的编码表手动验算一遍。4.3 现象首选分辨率读出来是 0 或明显错误的值原因第一个描述符不一定总是详细时序描述符。有些厂商会把显示器名称字符串放在第一个描述符位置详细时序挪到第二个。代码里硬编码偏移 54 就会读错。解决遍历四个描述符偏移 54、72、90、108检查每个描述符的前两个字节如果都是 0 且第三个字节是 0xFC显示器名称、0xFF序列号或 0xFE范围限制就跳过直到找到像素时钟不为 0 的描述符再解析时序。4.4 现象程序在 32 位系统上编译通过64 位系统上报错原因注册表 API 的RegQueryValueExW在 64 位系统上读取HKLM\SYSTEM时可能被重定向到Wow6432Node导致读不到真实的显示器节点。解决在打开注册表键时加上KEY_WOW64_64KEY标志强制访问 64 位视图。代码改成RegOpenKeyExW(hRoot, subKey.c_str(), 0, KEY_READ | KEY_WOW64_64KEY, hKey)。如果程序本身是 32 位的这个标志尤其重要。4.5 现象EDID 长度超过 128 字节解析函数只处理了第一个 block原因EDID 1.4 支持扩展 block注册表里存的值可能是 256 字节或更长。代码里只判断了 128就解析忽略了扩展 block 里的额外分辨率信息。解决先读第一个 block 的偏移 126 字节那是扩展 block 计数。如果大于 0说明后面还有数据。解析扩展 block 时每个 block 也是 128 字节第一个字节是 tag0x02 表示 CEA-861 扩展里面包含更多视频时序和音频信息。如果只需要基本信息忽略扩展 block 也能用但做完整显示器能力检测时不能漏。5. 进阶把 EDID 解析结果落成资产清单和兼容性报告前面四章把读取和解析跑通了但实际项目里往往不止读一台显示器。批量部署场景下我需要把几十台机器的显示器信息汇总成一张表用来判断哪些型号存在兼容性风险。下面这个思路是我常用的做法把ParseEdid的输出结构体扩展成包含机器名和读取时间的记录然后序列化成 CSV。// 将 EdidInfo 追加写入 CSV方便后续用 Excel 或脚本分析 void AppendToCsv(const std::wstring filePath, const std::wstring machineName, const EdidInfo info) { std::wofstream ofs(filePath, std::ios::app); if (!ofs.is_open()) return; // 写入表头仅首次实际项目里可以先判断文件是否存在 ofs machineName L, std::wstring(info.manufacturer.begin(), info.manufacturer.end()) L, info.productCode L, info.serialNumber L, info.year L-W info.week L, info.widthCm Lx info.heightCm Lcm, info.prefWidth Lx info.prefHeight L (int)(info.prefRefresh 0.5) LHz\n; ofs.close(); }这段代码的关键点用std::wofstream写宽字符文件避免中文机器名乱码std::ios::app追加模式多台机器跑完自动汇总刷新率四舍五入取整因为 EDID 算出来的值可能有小数误差。实际用的时候我会在每台机器上跑一遍读取程序把 CSV 汇总到共享目录然后用 Python 的 pandas 做透视表按厂商和型号分组统计数量再对照已知的兼容性问题列表打标。验证解析结果是否可信还有一个笨但有效的办法拿一台已知型号的显示器去网上查它的 EDID 数据库记录对比厂商 ID、产品代码和首选分辨率。如果三项都对得上说明解析逻辑没问题。我一般会挑一台 Dell 或 AOC 的常见型号做基准因为这两个品牌的 EDID 数据在网上比较容易找到参考。从那以后我每次拿到新的显示器兼容性排查任务都强制先跑一遍 EDID 读取和校验和验证确认数据完整再往下分析。这个习惯帮我省掉了至少三次因为 EDID 损坏而误判为驱动问题的返工。希望帮到你。本文还有配套的精品资源点击获取