Windows 10中文件删除本身不记日志，但相关异常会记录在“系统”日志中；需通过事件查看器筛选来源（ShellExperienceHost、RacTask等）、ID（20001/20002/1002/153）及关键词（recycle、delete）定位线索。
Windows 10系统中，文件被删除的操作本身不会直接记录为“删除文件”事件，但若该操作触发了系统级行为（如回收站服务异常、卷影副本失败、OneDrive同步冲突、或第三方备份软件报错），相关错误会写入系统日志。要定位这类线索，必须在事件查看器中按来源、ID和关键词精准筛选。
定位与打开系统日志
按下 Win + R，输入 eventvwr.msc，回车启动事件查看器——这是唯一能访问完整日志树的入口，其他方式（如设置里搜索）仅提供简化视图，无法执行高级筛选。
在左侧导航栏依次展开：Windows 日志 → 系统，右侧列表即为原始系统事件流。注意：不要点“应用程序”或“安全”日志，文件删除关联线索90%集中在“系统”日志中，尤其是与ShellExperienceHost、svchost（RacTask）、winlogon、volmgr等进程相关的条目。
按事件来源筛选关键记录
右键点击“系统”日志 → 选择“筛选当前日志”。在弹出窗口中：
在“事件来源”栏输入：Microsoft-Windows-ShellExperienceHost,RacTask,winlogon,volmgr（多个来源用英文逗号分隔，不加空格）；
勾选“错误”和“警告”级别；
点击“确定”。此时列表将收缩为与用户交互、回收站管理、磁盘卷状态强相关的事件集合——【RacTask是回收站清理任务的服务名，其报错往往出现在清空回收站后立即发生的权限失败或路径不可达】。
按事件ID锁定典型删除关联错误
方法一：聚焦已知高概率ID
在“筛选当前日志”窗口的“包括事件ID”栏中，输入：1001,1002,7045,20001,20002；
其中20001和20002是Windows资源管理器在执行删除/还原时向RacTask提交任务的日志ID，虽不标记“成功”，但连续出现20001→20002序列，且后续紧接ID 1002（RacTask执行失败），就极可能对应一次异常删除流程。
方法二：反向排查卷管理异常
若怀疑文件因磁盘脱机、BitLocker解密失败或存储池异常而“消失”，则筛选ID：36,37,50,153；
ID 153特别关键——它表示卷影副本创建失败，常发生在用户刚删除大量文件后系统尝试生成快照时崩溃，间接佐证删除动作已影响底层存储状态。
用关键词快速定位上下文
第一步：在筛选后的事件列表空白处右键 → 选择“查找”；
第二步：在“查找内容”框中输入：recycle 或 delete（小写，不加引号）；
第三步：勾选“仅搜索当前视图”，点击“查找下一个”；
这一步不会搜到“用户删除了xxx.txt”，但可能命中类似“Failed to commit recycle bin change for volume C:”的描述字段——【只要事件描述中出现recycle、bin、RacTask、shadow copy、volume C: delete，就必须双击打开查看详细信息里的“任务类别”和“用户”字段，它们可能暴露操作时间点与账户】。
导出可疑事件用于交叉比对
选中你标记为“可能相关”的3～5条事件（按住Ctrl多选），右键 → “将选定事件另存为…”；
保存类型选“事件文件（.evtx）”，文件名建议含日期与关键词，例如：sys_delete_clues_20261012.evtx；
保存后，可双击该文件在事件查看器中单独打开，避免原始日志被新事件冲刷；也可将此文件发给IT支持人员，他们能用PowerShell命令进一步提取关联进程PID或调用堆栈。
