问题描述：
最近使用了ai编辑器后，就发现在打开word文档或者PDF文档时，总是在同级目录下生成debug.log文件，这个文件很诡异，大小为0字节，里面是空的，没有内容。
通过搜索类似问题，发现并没有有效的线索，没有跟我一样的案例。有类似的问题，但是别人的debug.log文件里面有内容、有提示，别人的问题是chrome浏览器导致的，我依葫芦画瓢，重置了浏览器的设置，关闭了报告发送，调整了隐私保护等功能，还是没用，只要一打开任意一个文档，幽灵文件debug.log便会立即生成。
很好，今天让我们来盘他！！！
问题解决：
进一步分析发现，只有在使用WINWORD.EXE或Acrobat.exe才会引发这个现象，比如用其他pdf阅览器（我这里使用的是360PDF阅览器）打开pdf格式的文件是不会生成debug.log的，这也排除了不是针对文件类型的。
进一步分析发现，只有在打开文件（word或pdf）时，才会创建debug.log。
我们来找找从打开文件到生成debug.log，哪些进程参与了。首先要下载Process Monitor，这是微软官方开发的系统监控工具，主要用于实时追踪Windows系统中的进程、文件、注册表操作及网络活动，帮助用户诊断系统故障或排查恶意软件。在菜单筛选器中配置路径path->包含contains->debug.log，然后打开工具栏的捕获按钮。这时候需要去演示打开word文件，观察生成debug.log文件，然后看看我们捕获到了哪些进程：
除了WINWORD.EXE外，还有大量的Explorer.EXE，操作为 IRP_MJ_CREATE等，这表示进程正在“创建”或“打开”这个文件。
优化Process Monitor的过滤，精准定位：在过滤器中添加以下条件：路径Path 包含Contains debug.log；栏目：Operation 关系：Is 值：IRP_MJ_CREATE，看看捕获的情况：
由于没有明显的第三方进程（最后一项360截图，是我截图的时候才产生的），因此还是先排查WINWORD.EXE和explorer.exe。
首先，排查word的问题，做了3件事：
（1）禁用Word的加载项，没用。
（2）重置Word的注册表策略。按下 Win + R，输入 regedit并回车，打开注册表编辑器。导航到以下两个路径，查找是否存在名为 DebugLog或类似名称的键值：
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Options（16.0 对应 Office 2016/2019/2021/365，请根据你的Office版本调整，15.0=2013, 14.0=2010）
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Word\Options
如果找到名为 DebugLog或值数据指向日志路径的键值，右键点击它并选择“修改”，将其值清空，或者直接右键删除该键值。
关闭注册表编辑器，重启Word测试。
没用！
（3）修复或重新安装Office
没用！
其次，绝大多数对 debug.log文件进行操作的都是 Explorer.EXE（Windows文件资源管理器），可能由集成在Windows文件资源管理器（Explorer）中的一个外壳扩展（Shell Extension）或处理程序触发。
使用ShellExView工具，检查到所有外壳扩展：
需要找出是哪个扩展的问题，原则上需要一一禁用，然后重启 Explorer 进程，检查 debug.log是否还生成，进而锁定某个扩展。但是这样工作量太大，因此我直接全部都禁用了，验证后发现，还是继续生成debug.log。
问题不是由任何第三方外壳扩展（Shell Extension）引起的。既然不是外壳扩展，那么罪魁祸首很可能是一个直接挂钩（Hook）到应用程序（如WINWORD.EXE）上的动态链接库（DLL），或者是某个系统级别的监控/安全软件在起作用。需要更底层的排查方法！！
最后，需要使用 Process Monitor 的堆栈跟踪功能，这个功能可以告诉我们，究竟是WINWORD.EXE里的哪一行代码试图去创建debug.log文件。这是定位问题的“大杀器”。
设置过滤器：进程名包含 WINWORD.EXE并且 路径包含 debug.log。
点击 “选项（Options）” -> “启用堆栈跟踪（Enable Stack Traces）”。
确保工具栏捕获是开启的。
双击打开一个Word文档，触发生成debug.log的事件。
在Process Monitor中，找到那条WINWORD.EXE创建debug.log的记录（通常是第一条），在这条记录上右键单击，选择 “属性（Properties）”。在弹出的窗口中，切换到 “堆栈（Stack）” 标签页：
下面是打开pdf，跟踪Acrobat.exe堆栈（Stack）标签页里的完整内容：
结合两份堆栈跟踪信息（WINWORD.EXE 和 Acrobat.exe），清晰可见一个模块：360Hvm64.sys。这是一个360安全卫士的虚拟化驱动文件，位于系统内核层。它的存在表明360正在深度监控Acrobat和word的文件操作。果断卸载360安全卫士，问题依旧！！！
那接下来就是截图中出现的比较多的：sogou，截图中第25-34项，全是搜狗拼音相关的。
问题确实不是由360安全卫士单独引起的。根据事件查看器的堆栈跟踪，这是一个多模块协作的问题，其中最关键的角色已经变成了搜狗输入法。
操作由系统文件过滤驱动 FLTMGR.SYS开始，经过系统内核 ntoskrnl.exe，这是正常的文件创建流程。在调用链中出现了 360Hvm64.sys（360的虚拟化驱动），这说明360曾深度介入系统操作。
在调用链的末尾，出现了决定性的模块：
game_center.dll： 它很可能与搜狗输入法的游戏或娱乐组件相关。
SogouPY.ime： 这是搜狗拼音输入法的核心文件（IME文件）。它的出现，意味着搜狗输入法是最终发起创建文件请求的“最后一环”。
整个过程可以理解为：系统接收到创建文件的指令，这个指令经过各种驱动和系统组件传递，最终由搜狗输入法的某个组件（可能是game_center.dll，并由SogouPY.ime执行）发出。这个组件可能被设计为记录用户输入行为，但由于配置错误，它在所有文档处理程序中错误地试图创建调试日志。
果断卸载搜狗输入法，卸载后问题果然解决了！！！
狗日的搜狗输入法，你是真的狗！！！
总结与最终建议
根本原因：搜狗输入法的组件（SogouPY.ime和 game_center.dll）包含有缺陷的调试代码，它在Word、Acrobat等程序启动时，错误地试图在同目录下创建日志文件。
360的角色：360安全卫士的驱动（360Hvm64.sys）曾存在于调用链中，说明它可能以某种方式影响或触发了这个行为，但并非问题的最终根源。
最终方案：直接卸载或重装搜狗输入法。这是解决此问题的最简单、最有效的方法。
