# WorkBuddy #AI办公# D 盘突释 6.26GB 冻结四天：75 目录底账全平，遗迹只剩空 found.004

在一台被远程盯了两周的 Windows 机器上，C 盘的每 1GB 去向几乎都查清了，结果 D 盘先出了悬案：11 月 11 日到 12 日之间，D 盘可用空间从 52.54GB 突然跳到 58.80GB，单日释放 6.26GB——没有任何人在这台机器上删过东西。更蹊跷的是，此后四天这个数字一字不差地冻结在 58,801,340,416 字节上。今天我用 WorkBuddy 的每日发文自动化驱动一轮只读取证：75 个目录的底账逐一对账，把嫌疑范围从"不知道哪来的 6 个 GB"收敛到了一个高置信推断——**这 6.26GB 很可能不是被删除的文件，而是一次磁盘自检修复丢失簇后归还的空间**。

## 一、输入材料：一桩有完整时间线的悬案

这台机器是局域网内另一台 Windows 10 LTSC（下称目标机），从 10 月下旬起就是我 C 盘归因系列文章的观测对象。D 盘悬案的时间线如下（全部来自每日自动化任务的精确快照）：

| 日期 | D 盘可用空间 | 备注 |
|---|---|---|
| 10/25 | 53.4GB | 首次 SSH 体检记录 |
| 11/11 | 52.54GB | 补丁日：15:52 建还原点、17:27 WFP 转储、17:29 重启 |
| 11/12 | 58.80GB | **单日 +6.26GB，来源不明，悬案立案** |
| 11/13 | 58,801,340,416B | 一字不差；当天建了 D 盘一级底账（75 目录+16 散文件） |
| 11/14 | +32KB 量级 | 仍冻结 |
| 11/15 | 58,801,340,416B | 与 11/12、11/13 精确值一字不差，四日冻结 |

11/13 底账的关键构成：75 个一级目录合计约 466.7GB，Top3 为百度网盘下载目录 239.94GB、新版微信数据 37.87GB、旧版微信数据 31.72GB；根目录散文件 16 个共 8.98GB（大头是一个 5.25GB 的无人机视频）。这份底账就是今天对账的基准。

## 二、WorkBuddy 配置：三件套分工

- **调度层**：每日发文自动化任务（每天 10:00 触发），负责驱动选题、探测、写稿、发布全流程；
- **探测层**：paramiko 只读脚本（本文产出 `ssh_ddrill_1115.py`），对目标机走 SSH 执行 9 组 cmd 命令。核心复用已验证的模板：`for /f` 枚举 + `robocopy /L /S /BYTES /NJH /NFL /NDL /NP /XJ /R:0` 只列表测量——不落盘、不改动、75 个目录约 1 分钟跑完；
- **对账层**：本地 Python 脚本 `ddrill_diff_1115.py`，用正则分别解析 11/13 与 11/15 两份日志里的"### 目录名 + 字节行"，做集合差与字节级比对，避免人眼逐行核对出错。

## 三、操作步骤：五步收敛

**第 1 步，容量快照。** `wmic logicaldisk` 精确读数：C 盘 24,364,236,800B（两天回升 0.87GB，后面单独说），D 盘 58,801,340,416B——与 11/13 完全一致，冻结铁实。

**第 2 步，75 目录逐一对账。** 这是本次的主菜。对账结果：**74 个目录字节级完全一致**，包括 239.94GB 的百度网盘下载目录、37.87GB 的微信数据目录在内的全部大目录，两日纹丝不动。唯一差异是 System Volume Information 少了 31,864 字节——robocopy 普通遍历进不了卷影存储深处，这是系列文章里记过的已知盲区，量级也完全解释不了 6.26GB。

**第 3 步，found.004 体检。** 11/13 的根目录清单里有个刺眼的东西：`found.004` 目录，mtime 2026/11/11 17:27——与当天的 WFP 内核转储（17:27）同一分钟，距系统重启（17:29:38）只有两分钟。今天进去看：里面只有一个空的 `dir0000.chk` 子目录，0 个文件 0 字节。这是 chkdsk 的标准遗迹结构。

**第 4 步，五代 found 目录考古。** 顺着这个线索把 D 盘根目录 5 个 found 目录的 mtime 全部翻出来，模式立刻浮现：

| 目录 | mtime | 对应事件 |
|---|---|---|
| found.001 / found.002 | 10/29 15:47 / 15:54 | 10/29 重启窗口（pagefile mtime 15:55） |
| found.003 | 10/30 17:56 | 10/30 重启窗口 |
| found.004 | 11/11 17:27 | 11/11 补丁重启窗口 |

也就是说，**这台机器最近三次重启，每次都伴随一次 D 卷的磁盘自检**，而且历代 chkdsk 都不是空手：found.000 捞过 84KB、found.001 捞过 9.4MB、found.003 捞过 192MB。

**第 5 步，排除法收敛。** 把其他候选逐一排除：D 卷卷影存储从 11/08 的 182MB 变为 11/11 还原点事件后的 0 字节，只能解释 0.18GB；D 盘回收站复扫只有 31KB 的 $R 文件，"清空回收站"假说无痕迹支撑（且若有大文件经回收站删除，直清同样无痕，但找不到任何目录 mtime 变化佐证）；75 目录两日全平 + 11/11 之后无任何用户目录 mtime 变动，说明释放的 6.26GB **不属于任何现存目录里的文件**。

三项证据拼起来——释放突然、无文件对应、时间点正好落在带 chkdsk 遗迹的重启窗口——最强解释指向：**11/11 补丁重启过程中，D 卷经历了一次自动修复，被孤儿簇/丢失簇占着的约 6.26GB 空间被归还**。丢失簇是文件系统里"已标记占用但没有任何文件指向"的空间，chkdsk 修复时若无法挂回文件链就整段释放，且不留下任何文件级痕迹——与本案所有特征吻合。这是高置信推断而非实锤，复验方法也现成：下次重启后看 found.005 是否再现、D 盘是否再次异动。

**一个如实记录的不确定点**：11/13 的枚举输出里曾出现一个 found.005 条目，今天不存在。鉴于 11/14 已确认过 `for /f` 循环存在输出交错的坑（echo 行与测量行错位），且同一轮的 dir 列表里并没有 found.005，我倾向认为是解析伪影而非"两日内被删"，这一点不下定论。

**顺带的两个观察**：C 盘这两天回升 0.87GB，其中卷影差异文件 {b1e978f9} 长到 2.88GB（今晨 05:25 仍在写，vssadmin 服务侧已用 2.46GB、距 3.29GB 上限还有余量），但 SVI 只解释了 0.23GB，其余 0.6GB+ 暂未归因，留作观察项；两个内核转储（3.69GB，A 级清理候选）原封未动，是否删除仍等机主确认。

## 四、产出物

| 产出 | 说明 |
|---|---|
| `ssh_ddrill_1115.py` | 9 组只读命令的 paramiko 探测脚本，改 IP/凭据即可复用 |
| `ddrill_diff_1115.py` + 对账结果 | 75 目录两日底账严格对账：74 全平、SVI -31KB、总差 -31,864B |
| `ddrill_1115.log` | 完整探测留档（容量/底账/found.004/回收站/卷影） |
| 悬案状态更新 | 从「来源不明」收敛为「chkdsk 丢失簇修复释放」高置信推断 |

这轮取证最大的收获不是那 6.26GB 本身，而是又一次验证了"底账对账"的威力：正因为 11/13 留了一份 75 目录的字节级底账，今天才能用一次 1 分钟的复扫把"所有用户数据都没动过"从感觉变成事实，然后把嫌疑集中到文件系统自身。悬案从立案到收敛用了四天，剩余的验证动作只有一个——等下一次重启。

（本文基于对局域网内自有设备的真实只读排查写成，所有数据当日抓取，无任何虚构。）
![daily_content.png](https://developer.qcloudimg.com/http-save/yehe-12639135/d28afedb92742e1bdf076ee8e1546607.png)![daily_img_inserted.png](https://developer.qcloudimg.com/http-save/yehe-12639135/4208ec61a24a652476b846fc301118ff.png)![daily_final.png](https://developer.qcloudimg.com/http-save/yehe-12639135/a5604d3a09a9283e6879c584b1cb12cd.png)

在一台被远程盯了两周的 Windows 机器上，C 盘的每 1GB 去向几乎都查清了，结果 D 盘先出了悬案：11 月 11 日到 12 日之间，D 盘可用空间从 52.54GB 突然跳到 58.80GB，单日释放 6.26GB——没有任何人在这台机器上删过东西。更蹊跷的是，此后四天这个数字一字不差地冻结在 58,801,340,416 字节上。今天我用 WorkBuddy 的每日发文自动化驱动一轮只读取证：75 个目录的底账逐一对账，把嫌疑范围从"不知道哪来的 6 个 GB"收敛到了一个高置信推断——这 6.26GB 很可能不是被删除的文件，而是一次磁盘自检修复丢失簇后归还的空间。

#WorkBuddy# #AI办公# D 盘突释 6.26GB 冻结四天：75 目录底账全平，遗迹只剩空 found.004

在一台被远程盯了两周的 Windows 机器上，C 盘的每 1GB 去向几乎都查清了，结果 D 盘先出了悬案：11 月 11 日到 12 日之间，D 盘可用空间从 52.54GB 突然跳到 58.80GB，单日释放 6.26GB——没有任何人在这台机器上删过东西。更蹊跷的是，此后四天这个数字一字不差地冻结在 58,801,340,416 字节上。今天我用 WorkBuddy 的每日发文自动化驱动一

运维

开发工具

D盘可用空间突增6.26GB且四日冻结，经WorkBuddy自动化对账75目录字节级比对，确认非用户文件变动。排查锁定chkdsk遗迹found.004，推断为11月11日补丁重启时磁盘自检释放丢失簇所致，已从悬案收敛为高置信技术结论。

文件系统

WorkBuddy 

Windows

Python

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

#WorkBuddy# #AI办公# D 盘突释 6.26GB 冻结四天：75 目录底账全平，遗迹只剩空 found.004-腾讯云开发者社区-腾讯云

#WorkBuddy# #AI办公# D 盘突释 6.26GB 冻结四天：75 目录底账全平，遗迹只剩空 found.004

#WorkBuddy# #AI办公# D 盘突释 6.26GB 冻结四天：75 目录底账全平，遗迹只剩空 found.004

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐