企业官网建设流程全解析

WSL 数据收集与隐私：WSL 遥测机制全解析与关闭指南

【免费下载链接】WSLWindows Subsystem for Linux项目地址: https://gitcode.com/GitHub_Trending/ws/WSL

WSL（Windows Subsystem for Linux）与 Windows 其他组件一样，通过 Windows 遥测体系收集诊断数据，用于改进功能、稳定性和性能。本文以微软开源仓库 WSL 中的官方说明 DATA_AND_PRIVACY.md 为核心骨架，结合仓库源码深入剖析 WSL 究竟收集什么、如何收集、如何查看与关闭，帮助你在知情的前提下自主管理隐私与遥测开关。

一、总体概览：WSL 的遥测策略

原文出处：DATA_AND_PRIVACY.md

WSL 使用Windows 遥测（Windows telemetry）收集诊断数据，这与 Windows 上的其他组件（如 Edge、Office 等）保持一致。这意味着：

• 遥测的开关、强度、查看入口完全由 Windows 系统设置统一管控，无需（也无法）在 WSL 内部单独配置；
• 关闭诊断数据后，WSL 的遥测随之停用；
• 所有诊断数据均与微软隐私声明（Microsoft privacy statement）所述的数据处理政策一致。

关闭与查看诊断数据的入口

按官方文档说明，操作路径为：

1. 打开 Windows设置（Settings）；
2. 进入隐私和安全性（Privacy and Security）→ 诊断和反馈（Diagnostics & Feedback）；
3. 关闭诊断数据（Diagnostic data）选项即可禁用遥测；
4. 同一页面中的查看诊断数据（View diagnostic data）选项可查看你正在向微软发送的所有诊断数据。

需要明确：该开关是全局 Windows 级别的设置，作用于所有 Windows 组件，WSL 不提供独立的遥测开关。同时，这只能控制诊断数据的收集与上传；若你同时希望减少其他数据使用，可在同一设置区域继续检查“个性化体验”等选项，但本文仅聚焦 WSL 官方声明的遥测范畴。

二、WSL 收集什么：三大类诊断数据

官方文档明确列出 WSL 收集三类诊断数据，目的如下：

三类数据共同服务于产品迭代，而非用于追踪用户个人身份。接下来我们结合源码，看看这些“意图”在实现层面究竟映射为哪些具体的遥测事件。

三、源码级解析：WSL 遥测的真实实现

官方文档给出了一个非常实用的检索线索：

“You can search for WSL telemetry events by looking for calls toWSL_LOG_TELEMETRYin the source code of this repository.”

3.1 WSL_LOG_TELEMETRY 宏的定义

在 src/windows/common/WslTelemetry.h 中，宏定义如下：

#define WSL_LOG_TELEMETRY(Name, Tag, ...) \ TraceLoggingWrite( \ g_hTraceLoggingProvider, \ Name, \ TraceLoggingValue(WSL_PACKAGE_VERSION, "wslVersion"), \ TraceLoggingKeyword(MICROSOFT_KEYWORD_MEASURES), \ TelemetryPrivacyDataTag(Tag), \ __VA_ARGS__);

关键点解读：

• 每个遥测事件自动携带wslVersion（WSL 包版本号），便于按版本聚合分析；
• Tag参数通过TelemetryPrivacyDataTag(Tag)映射为PartA_PrivTags（见 src/windows/inc/traceloggingconfig.h），用于标记事件的隐私数据分类；
• 底层使用 WindowsTraceLogging机制（TraceLoggingWrite）写入事件。

同文件中还定义了三个遥测提供者（Provider，见 src/windows/common/WslTelemetry.cpp）：

从命名可推断，遥测按职责划分为：LXSS 子系统（发行版管理）、WSL 服务管理器（VM/会话管理）、WSLc（新版容器化 WSL 运行时）三大域。

3.2 遥测开关的实现：客户端计数与默认关闭

src/windows/common/WslTelemetry.cpp 展示了开关逻辑的实现：

static bool g_disableTelemetryByDefault = true; static std::atomic<long> g_ClientsWithTelemetryEnabled = 0; static std::atomic<long> g_ClientsWithTelemetryDisabled = 0;

WslTraceLoggingInitialize的文档注释明确说明两个重要设计（见 src/windows/common/WslTelemetry.h）：

• DisableTelemetryByDefault：在没有活跃用户会话的场景下，默认认为遥测不被允许，配合WslTraceLoggingClient表示活跃客户端；
• ForceDropPII：强制所有事件标记MICROSOFT_EVENTTAG_DROP_PII（丢弃个人可识别信息），并警告这将导致 devicedrill 等后端工具不可用，仅作临时设置。

WslTraceLoggingClient是一个 RAII 类（构造/析构时增减计数），代表某个客户端会话对遥测的“启用/禁用”意向，配合WslTraceLoggingShouldDisableTelemetry()判断是否真正上报。这套机制从代码层面印证了：遥测受用户会话与系统设置双重约束，默认不激进。

3.3 真实的遥测事件示例

在仓库中检索WSL_LOG_TELEMETRY，可在 12 个文件中找到 30 余处调用，覆盖“创建 VM、崩溃、网络连通性、会话管理、插件管理、安装过程”等场景。以下列举几个典型事件：

示例一：VM 生命周期（性能类）

src/windows/service/exe/WslCoreVm.cpp 中，创建 VM 的前后各记录一条事件：

// 创建 VM 前 WSL_LOG_TELEMETRY( "CreateVmBegin", PDT_ProductAndServicePerformance, TraceLoggingValue(VmId, "vmId"), CONFIG_TELEMETRY(newInstance->m_vmConfig)); // 创建 VM 完成后，记录耗时与内核版本 WSL_LOG_TELEMETRY( "CreateVmEnd", PDT_ProductAndServicePerformance, TraceLoggingValue(privateKernel, "privateKernel"), TraceLoggingValue(newInstance->m_kernelVersionString.c_str(), "kernelVersion"), TraceLoggingValue(newInstance->m_runtimeId, "vmId"), TraceLoggingValue(timeToCreateVmMs, "timeToCreateVmMs"), CONFIG_TELEMETRY(newInstance->m_vmConfig));

而 src/windows/service/exe/WslCoreVm.cpp 会在VM 启动失败时记录错误码：

WSL_LOG_TELEMETRY( "FailedToStartVm", PDT_ProductAndServicePerformance, TraceLoggingValue(VmId, "vmId"), TraceLoggingValue(hr, "error"), CONFIG_TELEMETRY(newInstance->m_vmConfig));

这三个事件直接对应官方文档中“稳定性（崩溃/失败监控）”与“性能（启动耗时评估）”两大目的。

示例二：网络连通性检查（性能/功能类）

src/windows/common/NatNetworking.cpp 中，NAT 网络模式下的连通性回调用例记录了大量结构化字段：

WSL_LOG_TELEMETRY( "TelemetryConnectionCallback", PDT_ProductAndServicePerformance, TraceLoggingValue("NAT", "networkingMode"), TraceLoggingValue(telemetryCounter, "telemetryCounter"), TraceLoggingValue(...count(), "timeFromObjectCreationMs"), TraceLoggingValue(...hostConnectivity..., "HostConnectivityLevel"), TraceLoggingValue(WindowsIPv4NlmConnectivityLevel, "WindowsIPv4ConnectivityLevel"), TraceLoggingValue(LinuxIPv4ConnCheckStatus, "LinuxIPv4ConnCheckStatus"), ... TraceLoggingValue(m_config.EnableDnsTunneling, "DnsTunnelingEnabled"), TraceLoggingValue(m_config.FirewallConfig.Enabled(), "HyperVFirewallEnabled"));

可见遥测记录的是网络模式、连通性级别、DNS 隧道开关、防火墙开关等功能与性能指标，而非用户网络流量内容。

示例三：安装与用户会话

src/windows/service/exe/LxssUserSession.cpp、WslClient.cpp 等文件分别记录了发行版安装、用户会话启动等使用类事件（事件名与用途可在对应源文件中直接检索确认）。

3.4 Linux 侧的遥测代理：进程执行计数

除了 Windows 侧的 TraceLogging，Linux 侧还有一个专门的遥测代理 src/linux/init/telemetry.cpp，其职责是：

1. 通过netlink connector（NETLINK_CONNECTOR/CN_IDX_PROC）订阅内核进程执行（PROC_EVENT_EXEC）事件；
2. 读取/proc/<pid>/cmdline获取执行的程序名（见GetProcessInformation，src/linux/init/telemetry.cpp）；
3. 在内存中按程序名累加计数，每 30 分钟（flushPeriod，见 src/linux/init/telemetry.cpp）或检测到 DrvFs 性能提示时，通过LX_MINI_INIT_TELEMETRY_MESSAGE批量回传给 Windows 服务端。

这里收集的是“哪个可执行程序被运行了多少次”的聚合统计（计数而非命令内容），例如git/5/表示 git 被执行了 5 次，对应官方文档“使用情况（Usage）”一类。值得注意，该代理还会识别在 DrvFs（Windows 盘符挂载点）中执行git clone、npm install、cargo build等高 I/O 场景并触发性能提示（映射表见 src/linux/init/telemetry.cpp），与“性能”目的呼应。

四、如何自主管理与核对

1. 关闭遥测：Windows 设置 → 隐私和安全性 → 诊断和反馈 → 关闭“诊断数据”。关闭后 WSL 的遥测事件将不再上报。
2. 查看已发送数据：同一页面点击“查看诊断数据”，可浏览当前设备发送的诊断数据内容。
3. 核对收集逻辑：任何对代码敏感的用户，都可以在仓库中搜索WSL_LOG_TELEMETRY逐个核对每个事件名、字段与触发位置——这正是官方文档为透明度提供的“自查入口”。
4. 注意边界：关闭诊断数据会影响微软对 WSL 问题的定位能力；遇到问题时，可在临时开启后复现并反馈，帮助改进稳定性（对应“稳定性”目的）。

五、总结

WSL 的遥测体系与 Windows 全局遥测深度集成：

• 收集范围聚焦三类：使用情况、稳定性、性能；
• 实现机制：Windows 侧通过 TraceLogging（WSL_LOG_TELEMETRY宏，见 src/windows/common/WslTelemetry.h）按事件记录，Linux 侧通过 netlink 统计进程执行次数（见 src/linux/init/telemetry.cpp）；
• 隐私控制：遵循 Windows 全局“诊断数据”开关，默认在无活跃用户场景下不启用（见 src/windows/common/WslTelemetry.cpp）；
• 透明度：官方文档明确指引用户通过检索WSL_LOG_TELEMETRY自查所有遥测点，配合“查看诊断数据”功能，用户可以完整知晓 WSL 发送了什么。

无论你是企业管理员、隐私敏感用户，还是对 WSL 内部机制感兴趣的开发者，都可以依据本文的路径关闭、查看或审计 WSL 的遥测行为。

【免费下载链接】WSLWindows Subsystem for Linux项目地址: https://gitcode.com/GitHub_Trending/ws/WSL