Windows 11 与 Windows 10 会为每一套系统安装实例分配一个持久化标识符GDID（Global Device Identifier，全局设备标识符）。即便用户更换 IP 地址，或是通过代理、 VPN 接入网络，微软依旧可以依靠该标识识别同一台物理设备。

曝光 GDID 的这起司法案件，也揭示了一个常被人们忽视的事实：保护网络流量，并不代表就能阻止操作系统向外发送可唯一识别本机的信息。

这里要明确一点：GDID 并非只有登录微软账户后才会生成。现有证据表明，即便使用本地账户，只要设备首次连接微软相关服务，同样会产生 GDID。

什么是 GDID，Windows 如何获取该标识

GDID 是微软分配给某一次 Windows 安装实例的持久化 ID，这套系统可以运行在物理真机，也可以是虚拟机环境。 它不等同于公网 IP、MAC 地址，也不是主板序列号。GDID 用于在微软各类服务中区分设备；系统版本更新不会改变 GDID，只有完整重装 Windows，才会生成全新的 GDID。

Windows GDID 全局设备标识符

该标识符并不是本机单纯依靠硬件信息本地计算得出。在设备首次和微软服务器通信时，Windows 身份服务会访问 login.live.com 这类接口，获取由服务端下发的一串数字编号，该编号属于Device PUID体系。

Windows会把这个值保存在用户注册表路径： HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties，对应项名称为 LID，注册表内存储为十六进制格式。 将十六进制数值转为十进制，再加上前缀 g:，就是微软日志中记录的 GDID 格式。

使用本地账户登录 Windows，并不代表一定不会生成 GDID。 全新离线安装、仅配置本地账户的系统，注册表内不存在 LID 条目。可一旦设备接入互联网，即便用户没有登录任何微软在线账号，Windows 也会在数秒内连接微软服务，拿到 GDID。 微软账户会把设备 ID 和个人身份直接绑定；但仅使用本地账户，无法阻止 GDID 创建。想要从源头阻止它被分配，就必须在设备第一次联网之前，切断和相关微软接口的通信。

GDID 并非 Win11 独有

GDID 并不是 Windows 11 才出现的产物。Windows 10 时代，微软就已经在遥测、设备注册体系中使用这类持久设备标识符。 Windows 11 延续并很可能扩展了这套机制，但微软没有公开完整技术文档，说明究竟是从哪一个预览版本开始正式启用命名为 GDID 的这套标识格式。

GDID 这个名词被大众熟知，主要源自对黑客组织 Scattered Spider 的司法调查卷宗。 Scattered Spider 是一个国际网络犯罪团伙，以攻击大型企业闻名。团伙大量运用社会工程学、钓鱼攻击、冒充客服致电企业，诱导内部人员重置密码、绕过多因素认证机制。

在此案之前，微软面向普通用户、系统管理员的公开文档中，没有清晰通俗地介绍过 GDID。这起案件曝光的，并不是一项新开发的技术，而是 Windows 遥测、设备注册体系中早已存在的标识符，被司法调查用来追踪嫌疑人设备。

检测本机是否存在 GDID

无需手动浏览注册表，按下 Windows+X，选择终端或者 Windows PowerShell（不需要管理员权限），粘贴下面命令即可提取 GDID：

1
2
$lid = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties' -ErrorAction Stop).LID

"g:$([Convert]::ToUInt64($lid,16))"

如果注册表项或者键值不存在，PowerShell 会抛出报错。没有该数据一般代表：当前用户配置文件尚未完成设备注册、设备处于离线状态，或是网络规则阻断了和微软服务器的通信。

注意：该项位于 HKCU（当前用户分支），检测结果只针对当前登录的用户。

下面是容错性更好的检测脚本：

1
2
3
4
5
6
7
8
9
10
11
$p = 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties'

if (Test-Path $p) {

    $v = Get-ItemProperty $p -Name LID -ErrorAction SilentlyContinue

    if ($v.LID) {

        "GDID: g:$([Convert]::ToUInt64($v.LID,16))"

    } else {

        '未发现LID值'

    }

} else {

    'IdentityCRL注册表项不存在'

}

仅仅删除注册表 LID 值，治标不治本

直接在注册表删掉 LID，只能删除本机本地副本。 微软服务端已经留存了设备与 GDID 的对应关系。只要条件允许，Windows 会重新向服务器请求该标识符。重启电脑、重新联网、相关系统组件启动之后，注册表内的条目就会再次生成。

你可以导出注册表项、删除 LID，再使用 Process Monitor 工具监控注册表读写，就能观察到哪个进程重新写入该键。该操作仅用于诊断测试。

还有一种看似可行的方案：给该注册表项设置严格的访问权限，阻止系统再次写入。但这只能阻止本地保存，无法清除微软服务器侧绑定关系，还会造成 Windows 身份认证组件异常报错。

两种阻断 GDID 的思路，代价截然不同

方案一：彻底拦截 login.live.com（激进方案）

在全新 Windows 系统第一次联网之前，拦截域名 login.live.com。该域名负责微软账号身份注册。公开测试显示，无法访问该域名，就能阻止 GDID 生成。

代价巨大：login.live.com 承担微软账号全套认证，OneDrive、微软商店、Microsoft 365、Xbox，以及所有依赖微软身份体系的应用全部会受影响。会出现登录窗口空白、认证报错、商店应用无法安装、反复弹窗索要账号凭证等故障。

方案二：保留身份服务，阻断设备上报链路（折中方案）

保留微软账号登录能力，只阻断设备注册、后续部分上报链路。需要屏蔽的域名包括： dds.microsoft.com、cdpcs.access.microsoft.com、activity.windows.com，以及do.dsp.mp.microsoft.com 系列域名。

这种模式下，GDID 可能依旧保存在本地与微软服务器。现实目标不是彻底抹除 ID，而是减少调用 GDID 的服务场景，降低 Windows 向外上报该标识符的机会。

注意：没有绝对可靠的匿名化手段。微软拥有大量服务、接口与标识符；Windows 更新还可能改动域名和通信链路。域名拦截属于可验证的缓解手段，不能保证完全杜绝设备标识泄露。

使用 AdGuard Home、Pi‑hole、Technitium DNS 做域名拦截

自建可控 DNS 服务器，是批量拦截域名家族最实用的方式。Pi‑hole、AdGuard Home、Technitium DNS Server 可以对局域网全部设备统一下发过滤规则，还能记录 DNS 请求日志，方便排查W indows 尝试访问的服务器。

AdGuard Home 过滤规则示例：

1
2
3
4
5
||login.live.com^$dnsrewrite=0.0.0.0

||dds.microsoft.com^$dnsrewrite=0.0.0.0

||cdpcs.access.microsoft.com^$dnsrewrite=0.0.0.0

||do.dsp.mp.microsoft.com^$dnsrewrite=0.0.0.0

||activity.windows.com^$dnsrewrite=0.0.0.0

如果你还需要正常使用微软账号服务，就去掉第一行，只拦截设备注册、活动上报、传递优化相关域名。do.dsp.mp.microsoft.com 规则可以覆盖 geo.prod.do.dsp.mp.microsoft.com 等一系列子域名。

配置规则之后，执行 ipconfig /flushdns 清空本机 DNS 缓存，重启电脑，查看 DNS 解析日志。 可以使用下面 PowerShell 命令验证解析结果：

1
2
Resolve‑DnsName login.live.com

Get‑DnsClientServerAddress

⚠️重要提醒：注意 DNS‑over‑HTTPS（DoH）。如果 Windows、浏览器、VPN 软件、安全软件直接使用外部加密 DNS，会绕过本地 DNS 过滤。在企业/家庭网络中，建议禁止设备直连外网 DNS，仅允许 53 端口访问内网 DNS 服务器，管控客户端 DoH 配置。

Hosts文件仅适合临时测试

Windows Hosts 文件路径：C:\Windows\System32\drivers\etc\hosts，可以将域名解析重定向到 0.0.0.0 或者 127.0.0.1，示例：

1
2
3
4
0.0.0.0 login.live.com

0.0.0.0 dds.microsoft.com

0.0.0.0 cdpcs.access.microsoft.com

0.0.0.0 activity.windows.com

Hosts 的硬伤：不支持通配符。写一条 do.dsp.mp.microsoft.com，不会自动拦截 geo.prod.do.dsp.mp.microsoft.com 这类子域名，所有子域名必须逐条手动添加。 同时 Hosts 没有集中日志，管理员权限就可以随意被修改；部分软件自带内置 DNS 解析，完全无视 Hosts。 因此 Hosts 适合单机快速测试；多设备环境，优先选择中心化 DNS 过滤。

关闭 Connected Devices Platform（连接设备平台）

Connected Devices Platform 包含系统服务 CDPSvc，以及一系列用户态服务 CDPUserSvc_xxxx，后缀会随用户会话变化。

以管理员身份打开 PowerShell，查看相关服务状态：

1
2
Get‑Service CDPSvc,DoSvc -ErrorAction SilentlyContinue

Get‑Service | Where‑Object Name ‑Like 'CDPUserSvc*' | Select‑Object Name,Status,StartType

停止并禁用 CDPSvc 服务：

1
2
Stop‑Service CDPSvc ‑Force ‑ErrorAction SilentlyContinue

Set‑Service CDPSvc ‑StartupType Disabled

修改用户态服务模板（不要直接修改带随机后缀的实例）：

1
reg add "HKLM\SYSTEM\CurrentControlSet\Services\CDPUserSvc" /v Start /t REG_DWORD /d 4 /f

修改完成后必须重启电脑，已经运行的用户服务实例会在用户注销之后终止。

副作用：关闭这套服务，不只是影响 GDID。「手机连接」、跨设备体验、就近共享、设备选择器、活动时间线同步等系统功能会失效或者异常。微软文档明确标注 CDPUserSvc 负责设备发现与跨设备联动。

普通家用电脑的均衡配置方案

如果你要使用微软商店、OneDrive、Microsoft 365，直接屏蔽 login.live.com 完全不现实。

推荐低侵入方案：

1. 保留微软身份认证服务可用；
2. 通过 DNS 过滤拦截 DDS、CDP 相关上报域名；
3. 评估是否关闭 Connected Devices Platform，权衡跨设备功能与隐私诉求。

如果你希望从源头阻止 GDID 生成：全新系统离线安装，使用本地账户，第一次联网之前就拦截 login.live.com，代价就是放弃该设备上绝大多数微软生态功能。

重点：微软没有提供官方总开关可以一键关闭 GDID。

微软是否应当提高透明度？

GDID 这类在线标识符，只要可以直接或间接定位到自然人，就属于 GDPR 定义下的个人数据。设备持久编码一旦可以关联微软账号、历史 IP、服务行为记录，就落入个人数据的监管范畴。

假名化不等于匿名化：把用户名替换一串数字 ID，只是增加识别难度；只要服务商仍然保有还原关联的能力，数据就不属于匿名数据。

微软隐私说明中，会提及收集设备配置、网络信息、各类设备标识符；但是面向普通用户的公开文档，没有详细解释 GDID 的产生条件、调用组件、保存周期、删除与异议处理方式。

GDPR 并不强制要求必须有一个“关闭 GDID”的按钮，但要求数据处理方遵守合法、公正、透明、数据最小化、目的限定原则。隐私声明应当清晰告知收集的数据类别、用途、法律依据、保存周期、数据接收方。仅仅笼统写“设备标识符”，在 GDID 可以把多次网络行为稳定绑定同一套 Windows 安装实例的场景下，是不够充分的。标识符用途不同，合规责任也不同：仅用于系统更新，和用于行为分析、风控、跨服务关联，要求完全不一样。

能否关闭，取决于数据处理的法律依据：

• 如果处理基于用户同意，用户有权同等便捷地撤回许可；
• 如果基于合法利益，用户可依据 GDPR 第 21 条行使反对权，企业必须证明存在压倒用户权益的强制性合法理由，或是出于司法办案需要，才可以继续处理。

真正必要（安全保障、履行法定义务）的数据处理，厂商不必提供无损全部功能的关闭选项。但必须区分「必要用途」和「附加用途」；不能逼迫用户放弃微软账号、商店、系统更新，只为阻止标识符被挪作其他用途。

以上种种问题，都值得欧盟数据保护机构、意大利数据保护局进一步审查：确认 GDID 在实际处理中是否属于个人数据、关联了哪些信息、服务器存储时长，以及用户能否切实行使查阅、删除、限制处理、提出异议的权利。

目前想要限制 GDID，只能依靠 DNS 过滤、修改系统服务，还要牺牲部分系统功能。这不直接等同于违反 GDPR，但也反映现实：缺少简单细粒度的官方开关，公开文档对该持久标识符的说明不够充分。

更多 GDID 技术资料可参考开源项目：https://github.com/Korben00/no‑gdid