# #WorkBuddy# #AI办公# Windows 第 4 大目录破案：ServiceProfiles 的 3.5GB，全是 11·11 补丁日留下的传递优化缓存

## 前情与输入材料

我在用 WorkBuddy 自动化任务（每日 10:00 触发）跟踪局域网里另一台 Windows 机器（192.168.1.17，Windows 10 LTSC 2019）的 C 盘消耗，已经写了七篇归因系列。11 月 11 日那台机器打了两个补丁（KB5131084、KB5131085），当天 C 盘可用空间暴跌 9.33GB，是历史最大单日跌幅。11 月 13 日的巡检把 Windows 目录的增量拆到了 87 个一级子目录，账对平了，但留了一个悬念：

| 目录 | 11/13 实测 | 疑点 |
| --- | --- | --- |
| Windows 整树 | 34,325,696,466 B（31.97 GiB） | 一日 +0.72 GiB |
| WinSxS | 10,235,221,236 B | 已知，补丁进组件存储 |
| LiveKernelReports | 双 dump 3.69 GB | 已知，内核转储 |
| **ServiceProfiles** | **3,551,125,324 B（3.31 GiB）** | **新面孔，正常安装只有几十 MB，排全目录第 4** |

WinSxS 和 dump 只能解释约 3.9GB，剩下约 5.9GB 的历史留白里，ServiceProfiles 是头号嫌疑。今天的目标就是把它下钻到底。

## WorkBuddy 配置

这条线跑在三层固定配置上，全程只读：

1. **自动化任务**：WorkBuddy 定时任务每日 10:00 触发，排期 RRULE 固定，无人值守；
2. **探测通道**：受管 Python venv（3.13）+ paramiko 5.0，SSH 连 22 端口（目标机 mywork 账号，密码含 `&`，只能写进脚本变量，不能走命令行拼接）；
3. **测量模板**：robocopy 列表模式 `robocopy <源> C:\__rc_probe__ /L /S /BYTES /NJH /NFL /NDL /NP /XJ /R:0 /W:0`，外层套 `for /f "delims=" %d in ('dir /a:d /b <目录>')` 逐子目录测量，输出用 findstr 只留「字节」行。`/XJ` 拦联接点、`/R:0` 不重试、`/L` 只列表不真拷贝。

## 操作步骤：三轮探测，一层一层剥

### 第一轮：一级拆分——先问钱在谁兜里

ServiceProfiles 下按设计只有两个服务账号的"家"：LocalService 和 NetworkService。逐个测量：

| 账号 | 实测 | 占比 |
| --- | --- | --- |
| LocalService | 40,164,276 B（约 40MB） | 1.1% |
| NetworkService | 3,511,029,862 B | **98.9%** |

LocalService 全家（AppData、NTUSER.DAT 系列、一堆空壳标准目录）加起来 40MB，账干净。钱全在 NetworkService 兜里，继续钻它的 AppData：Local 侧的 Microsoft 3,507,016,749 B，Roaming 侧只有 23KB 的 Microsoft。

**中途踩坑一**：cmd 的 for /f 循环里，robocopy 管道输出和下一轮的 echo 头会交错——我的输出里 `===ROAMING===` 出现在循环中间，7 个目录的名字和数值错位排列。最后是靠「echo 头 + 字节数值」的配对模式逐行还原的。教训：循环体内多命令的输出交错没有好办法根治，解析时按模式对齐，别按顺序读。

### 第二轮：四级下钻——真凶浮出

在 NetworkService\AppData\Local\Microsoft 里逐项测量，Windows 一项 3,500,700,556 B 又占掉 99.97%；再钻 Microsoft\Windows：

| 目录 | 实测 |
| --- | --- |
| **DeliveryOptimization** | **3,506,863,511 B** |
| Shell | 117,941 B |
| WinX | 24,111 B |
| 其余（CloudStore/INetCache 等） | 全 0 |

**DeliveryOptimization——Windows 传递优化（DO）的下载缓存**。这个目录挂在 NetworkService 名下，平时完全隐身：资源管理器里它有权限保护，dir 能看到但大多数工具不枚举，所以它大到 3.5GB 也没人发现。

**中途踩坑二**：我对 DeliveryOptimization 目录跑 `dir /a /s` 想拿全树明细，返回空输出——深层 Cache 子目录对普通枚举不可见。改用 robocopy 逐桶测量才拿到数。

### 第三轮：哈希桶对质——和补丁日钉死

DO 的 Cache 目录里是哈希命名的"桶"，每个桶装一组块级缓存文件。逐桶测量 + mtime 对质：

| 缓存桶（前 8 位） | mtime | 大小 |
| --- | --- | --- |
| 239cdd63 | 11/11 13:22 | **2,048,109,879 B（2.05GB）** |
| 170c2c76 | 11/11 15:49 | 880,860,718 B |
| 62b14ca5 | 11/11 13:22 | 342,159,512 B |
| 57a01d6c | 11/11 15:47 | 90,836,078 B |
| 3162d77f | 11/11 13:20 | 54,553,550 B |
| 53ec9fcb | 11/11 13:20 | 32,371,088 B |
| e2ac26aa | 10/29 15:51 | 44,955,598 B |

七个桶六个 mtime 全是 11 月 11 日——补丁日当天，两个 KB 的安装包以块为单位下载、分装进这些哈希桶，合计约 3.45GB。11/11 单日 -9.33GB 的构成至此基本闭合：WinSxS 1.99GB + 内核 dump 1.91GB + **DO 缓存 3.5GB** + 杂项，5.9GB 留白的最大一块找到了主犯。

### 收尾复测：它现在稳定吗

第三轮顺手做了当日快照对质：Windows 整树 34,342,341,742 B（较昨日仅 +16.6MB）、ServiceProfiles 3,551,194,138 B（+69KB）——已停笔；C 盘可用 23,430,979,584 B（-26MB 持平）；D 盘 58,801,373,184 B（+32KB，那个 +6.26GB 的悬案依然冻结）；SVI 卷影 {b1e978f9} 定格 2.86GB，vssadmin 已用 2.28GB / 分配 2.66GB，第三次淘汰未触发。

## 产出物

1. **破案结论**：ServiceProfiles 3.51GB ≈ 99.97% 是 11·11 补丁日的传递优化缓存（DeliveryOptimization\Cache 哈希桶），属系统托管缓存，会随保留策略自动过期；手动清理可用磁盘清理或 Delete-DeliveryOptimizationCache cmdlet，但不建议急着删——它同时是补丁的 P2P 分发源；
2. **可复用脚本**：ssh_sp_drill_1114.py（一级拆分）、ssh_ns_drill_1114.py（四级下钻）、ssh_do_probe_1114.py（哈希桶明细），改 IP/凭据即用于任何机器；
3. **两份巡检日志**与三份探测输出留档，作为 11/13 基线的对账凭证。

最后说一句方法论：Windows 目录里"不该大却大"的目录，往往不是坏了，而是某个系统服务把"家"安在了你不知道的层级里。下一层一层剥，别急着删。
![daily_content.png](https://developer.qcloudimg.com/http-save/yehe-12639135/a1ae1431f67c5537539188013a07c071.png)![daily_img_inserted.png](https://developer.qcloudimg.com/http-save/yehe-12639135/fd623f42d9fdf9983f78342c96c609bb.png)![daily_final.png](https://developer.qcloudimg.com/http-save/yehe-12639135/8426c06bc9ae30281e7dc85acaa71e04.png)

我在用 WorkBuddy 自动化任务（每日 10:00 触发）跟踪局域网里另一台 Windows 机器（192.168.1.17，Windows 10 LTSC 2019）的 C 盘消耗，已经写了七篇归因系列。11 月 11 日那台机器打了两个补丁（KB5131084、KB5131085），当天 C 盘可用空间暴跌 9.33GB，是历史最大单日跌幅。11 月 13 日的巡检把 Windows 目录的增量拆到了 87 个一级子目录，账对平了，但留了一个悬念：

#WorkBuddy# #AI办公# Windows 第 4 大目录破案：ServiceProfiles 的 3.5GB，全是 11·11 补丁日留下的传递优化

我在用 WorkBuddy 自动化任务（每日 10:00 触发）跟踪局域网里另一台 Windows 机器（192.168.1.17，Windows 10 LTSC 2019）的 C 盘消耗，已经写了七篇归因系列。11 月 11 日那台机器打了两个补丁（KB5131084、KB5131085），当天 C 盘可用空间暴跌 9.33GB，是历史最大单日跌幅。11 月 13 日的巡检把 Windows 目

操作系统

运维

开发工具

ServiceProfiles目录占3.51GB，其中99.97%来自NetworkService下的DeliveryOptimization缓存，系11月11日补丁日留下的传递优化下载缓存。哈希桶mtime指向补丁安装当天，构成C盘单日9.33GB暴跌的主因。此缓存为系统托管，自动过期，手动清理需谨慎，因兼作P2P分发源。

WorkBuddy 

Windows

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ServiceProfiles目录占3.51GB，其中99.97%来自NetworkService下的DeliveryOptimization缓存，系11月11日补丁日留下的传递优化下载缓存。哈希桶mtime指向补丁安装当天，构成C盘单日9.33GB暴跌的主因。此缓存为系统托管，自动过期，手动清理需谨慎，因兼作P2P分...

#WorkBuddy# #AI办公# Windows 第 4 大目录破案：ServiceProfiles 的 3.5GB，全是 11·11 补丁日留下的传递优化-腾讯云开发者社区-腾讯云

#WorkBuddy# #AI办公# Windows 第 4 大目录破案：ServiceProfiles 的 3.5GB，全是 11·11 补丁日留下的传递优化

#WorkBuddy# #AI办公# Windows 第 4 大目录破案：ServiceProfiles 的 3.5GB，全是 11·11 补丁日留下的传递优化

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐