正确解法 注册表清理必须“小步快跑”， 这样任何非SYSTEM权限的进程包括Win工具箱的安装程序尝试向这些路径写入都会收到“拒绝访问”错误安装直接失败，它们大多只查HKEY_CURRENT_USER和常见Services键对HKLM\SYSTEM\CurrentControlSet\Control\Class这类设备驱动关联注册表、WMI中的__EventFilter实例、以及通过PowerShell Remoting注入的持久化脚本几乎无能为力。
若不确定先用 schtasks /query /fo LIST /v 列出所有任务再筛选， 注意删除注册表前务必先导出整个键值备份， 区域一Services键 路径 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 操作按CtrlF搜索“WinToolBox”“Wtb”“ToolKit”找到对应键名如WtbHelper右键→导出备份命名为WtbServicesBackup.reg然后右键→删除，这些细节文档里永远不会写，若为wtb_updater.exe之类说明有残余网络模块。
Uninstall键是系统软件清单的索引删它等于撕掉系统软件地图，这里存放着所有设备类别的配置信息， 2.1 注册表不只是Software键还有System和Classes两大雷区 绝大多数人只查HKEY_LOCAL_MACHINE\SOFTWARE和HKEY_CURRENT_USER\Software下的厂商名这只能挖掉冰山一角， 删除计划任务 schtasks /delete /tn Windows Defender Scheduled Scan /fschtasks /delete /tn System Maintenance Optimizer /fschtasks /delete /tn WtbAutoRecover /f /f 参数强制删除无需确认。
验证重启后打开资源管理器右键任意文件夹确认无多余菜单项地址栏无异常按钮，尤其 root\subscription 命名空间其数据存储在 C:\Windows\System32\wbem\Repository 里这个文件夹有写保护重启时才会重新加载，在Autoruns里右键→“Jump to Entry”定位注册表位置记下InProcServer32下的DLL路径再手动去文件系统删那个DLL， 操作指令 # 以管理员身份运行CMD逐个删除注意路径中的空格需加引号rmdir /s /q C:\Program Files\WinToolBoxrmdir /s /q C:\Program Files (x86)\WtbSuitermdir /s /q %LOCALAPPDATA%\WinToolBoxrmdir /s /q %APPDATA%\WtbConfigrmdir /s /q %ALLUSERSPROFILE%\WinToolBox 验证方式 执行后用Everything搜索“WinToolBox”确认无任何文件或文件夹返回， State。
禁用第三方服务 进安全模式后按WinR输入 msconfig 切到“服务”标签页勾选“隐藏所有Microsoft服务”然后点“全部禁用”，特别注意Value数据若为 C:\Windows\System32\rundll32.exe C:\path\to\wtb.dll，结果两小时后服务又自己跑起来了状态显示“正在运行”。
正确解法 清理必须覆盖所有临时路径 %TEMP% 、 %WINDIR%\Temp 、 %ALLUSERSPROFILE%\AppData\Local\Temp ，若仍有结果说明路径名有变体需根据搜索结果手动定位删除，Win工具箱的守护进程会每5分钟检查一次服务状态发现被禁用就调用 sc create 命令重新注册， 检查服务状态 运行 services.msc 滚动查找是否有新出现的、名称可疑的服务状态为“正在运行”，这个命令会从SCM数据库中物理删除服务记录不是简单禁用。
否则说明存在更深层的Rootkit级残留需考虑使用Sysinternals Suite中的GMER或Kaspersky TDSSKiller进行内核级扫描，这不是简单的“删文件删注册表”而是针对四个相互耦合的系统级锚点进行精准打击，这是检验清理效果的黄金窗口期，如果看到C:\ProgramData\WtbSvc\svc.exe或C:\Users\Public\Documents\toolkit\engine.dll100%是第三方，清除它不能靠删注册表必须用 Remove-WmiObject 命令精准删除对应实例否则下次重启它又会从WMI库里自动加载，注意必须选“启用安全模式”不是“启用带网络的安全模式”因为网络会唤醒它的远程心跳模块。
检查网络连接 命令行执行 netstat -ano | findstr :443 看是否有非浏览器进程连接443端口， 经验很多用户卡在这一步反复进不了纯安全模式，但为保险起见建议执行完立即重启再验证。
Entry 必须删整个键值不能只删路径，我曾见过某款工具箱在卸载时故意损坏HKLM\SYSTEM\CurrentControlSet\Control\Nls\Sorting\Ids键导致系统重启后中文排序乱码，我给自己定了一套最终验证清单每天早晚各执行一次 验证项目 检查方法 合格标准 失败应对 服务复活 sc queryex type service state all | findstr Wtb|ToolBox 返回空 重新执行步骤四 注册表复活 reg query HKLM\SOFTWARE /s | findstr Wtb|ToolBox 返回空 用Regshot对比前后快照定位写入点 计划任务复活 schtasks /query /fo LIST | findstr Wtb|ToolBox 返回空 检查C:\Windows\Tasks下是否有.sch文件 WMI复活 Get-WmiObject -Namespace root\subscription -Class __EventFilter | ?{$_.Name -match Wtb} 返回空 检查C:\Windows\System32\wbem\Repository下是否有异常.mof文件 网络心跳 netstat -ano | findstr :80|:443|:3389tasklist /fi pid eq [PID] 所有PID对应进程均为chrome.exe、edge.exe等可信浏览器 立即断网用Wireshark抓包分析 坚持72小时若每天清单全绿则可判定为“彻底卸载”， ， 2. 拆解Win工具箱的四大顽固据点注册表、服务、计划任务、WMI 要真正把它从系统里连根拔起必须先理解它在哪几个关键位置布防，执行后用 sc queryex WtbHelper 验证应返回错误1060。
错误操作 WMI的某些类实例在内存中缓存不重启不会真正释放。
而且重启后第一时间再运行一遍WMI查询命令确认真正清零， 全局数据目录 在 C:\ProgramData\WinToolBox 这是所有用户共享的也是服务进程读取配置的地方， 提示不要轻信任何第三方卸载工具的“强力扫描”结果， 安全选项勾选“即使用户未登录也运行”且“不存储密码” 这意味着任务以SYSTEM身份运行无需用户交互且密码字段为空——这正是它能绕过UAC静默执行的关键，这种任务往往在后台默默重装核心组件， 检查启动项 任务管理器→“启动”标签页确认所有条目Publisher列均为“Microsoft Corporation”或知名软件商无“Unknown”或空白， 这个脚本每天自动扫描所有计划任务只保留白名单里的其余一律禁用， 错误操作 只删注册表引用不删物理文件， 操作路径 gpedit.msc → 计算机配置 → Windows设置 → 安全设置 → 注册表 添加规则 右键→“新建密钥项”路径填 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class 权限设置 双击→“安全”→“高级”→“禁用继承”→“添加”→选择“SYSTEM”和“Administrators”权限勾选“完全控制”再添加“Users”组权限仅勾选“读取”和“查询值” 取消所有写入权限 ， 5.1 坑一用“注册表清理工具”一键清空Software键导致系统崩溃 场景 客户用某国产“超级清理王”勾选“深度清理注册表”一键扫描后它把HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall下所有非微软的键全删了，它的核心目标从来不是帮你清理垃圾而是长期驻留、持续收集行为数据、劫持系统入口、甚至为后续推广其他付费模块预留通道， 3. 手动清理全流程从安全模式启动到最终验证的七步闭环 光知道哪几处有残留还不够必须有一套可复现、可验证、零遗漏的手动操作流程， 3.7 步骤七72小时观察期与最终验证清单 真正的“彻底”不是卸载那一刻而是72小时内系统保持绝对干净， 用户数据目录 在 C:\Users\[用户名]\AppData\Local\WinToolBox 和 Roaming\WtbConfig 这里存着它的配置数据库、日志、以及用于复活的加密密钥。
而Win工具箱服务的Description常是空白、或写着“System Optimization Module”“Background Maintenance Agent”这类泛泛之词，我给自己和客户部署了三层防御体系不是靠杀软而是靠系统机制本身的加固，这说明所谓“卸载成功”只是UI层的一次礼貌性欺骗。
3.4 步骤四服务与计划任务的强制注销 这一步必须用命令行图形界面容易遗漏， 立即检查任务管理器 切换到“详细信息”标签页按CPU、磁盘、网络排序看是否有陌生进程特别是rundll32.exe、svchost.exe的异常实例持续占用资源，原因往往是Fast Startup快速启动功能开启， 注销服务 sc delete WtbHelpersc delete WinToolGuardsc delete WtbUpdateSvc 注意 sc delete 命令会直接从SCM数据库中移除服务定义比在服务管理器里“停止禁用”彻底得多。
4.3 第三道防线WMI事件审计与自动阻断 最后一道防线直击WMI这个最隐蔽的战场，它是一套 跨层级、多进程、自保护、带服务钩子的系统级寄生组件集合 ， 4.2 第二道防线计划任务白名单机制 与其等它创建恶意任务不如提前封死所有非授权任务的创建通道，更彻底的是用Disk Cleanup工具勾选“临时文件”“系统错误内存转储”一并清空， 错误操作 盲目信任第三方清理工具的“智能识别”没做备份就执行。
验证重启进正常模式打开任务管理器→“启动”标签页确认无相关条目，记下PID再用 tasklist /fi pid eq [PID] 查进程名，真正该清理的是Services、Run、Class这些功能键而不是Uninstall这种元数据键，另开一个PowerShell窗口执行 Get-WmiObject -Namespace root\subscription -Class __EventFilter 确认列表中无任何含“Wtb”字样的项， 正确解法 WMI清理后 必须重启 。
2.3 计划任务那些藏在“Task Scheduler Library”深处的定时唤醒者 很多人以为删了服务就万事大吉却忘了计划任务才是最阴险的复活机制，三重保险万无一失， 5.2 坑二在正常模式下删服务结果服务自动重建 场景 客户在任务管理器里右键停掉“WtbHelper”服务再右键“属性”→启动类型改为“禁用”以为万事大吉。
这不是卸载失败这是被设计成“不可彻底清除”。
错误操作 只清理安装目录忽略临时目录。
经验我现在的习惯是打开注册表编辑器后第一件事不是搜索而是右键“我的电脑”→导出存为 PreCleanBackup.reg ，更隐蔽的是它可能把自身注册为某个真实系统服务的“依赖服务”DependOnService字段这样即使你停掉主服务它也会被拉起， 第三处是 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper ObjectsBHO 和 Shell Extensions ，重点不是看DisplayName而是看ImagePath和Start值，真正的彻底清理必须是手动脚本验证的三重闭环，用命令 sc qprivs 服务名 可查返回结果若包含这两项必须重点核查，Win工具箱会在Task Scheduler Library下创建多个任务名称常伪装成“Windows Defender Scheduled Scan”“System Maintenance Optimizer”等， Win工具箱类软件包括但不限于“微PE工具箱”“Dism增强版”“某大师Win优化套件”等变体根本不是传统意义上的单体应用。
4.1 第一道防线组策略锁定注册表关键路径 Windows组策略是免费的最强防火墙， 验证方法打开任务计划程序展开“Task Scheduler Library”按“最近运行时间”排序找那些昨天、今天刚运行过的、名称可疑的任务。
结果第二天开机 __EventFilter 又出现了名称还是原来的， 3.3 步骤三注册表深度清理——分区域、分权限、分备份 注册表清理是风险最高也最关键的一步， 4. 预防复发三道防线构建免疫系统 卸载只是开始防止它卷土重来才是长期战，右键→属性→“历史记录”标签页看执行日志里有没有“操作成功”但“结果代码0x1”表示脚本内部报错但任务本身没失败的记录。
登录身份Log On As为LocalSystem但权限异常高 它可能申请了SeDebugPrivilege调试权限或SeLoadDriverPrivilege加载驱动权限这在普通应用服务中极不寻常，删完再重启确保事件查看器里无相关错误，右键→“打开文件所在位置”确认路径是否为系统目录，用命令 del /f /q /s %TEMP%\*.bat 、 del /f /q /s %WINDIR%\Temp\*.ps1 批量清理，通过禁用特定注册表路径的写入权限可从根本上阻止Win工具箱写入Services、Run、Class等关键键， 启用WMI审计 在组策略中 计算机配置 → Windows设置 → 安全设置 → 高级审核策略配置 → 系统审计策略 → 对象访问 → 审核WMI活动 勾选“成功”和“失败”。
结果重启后控制面板打不开“程序和功能”一片空白连已安装的Office都显示为“未知”， 5. 实战避坑指南那些让我重装三次系统的血泪教训 纸上谈兵永远不如实战踩坑来得深刻，现在我把它们写进客户交付文档的“注意事项”里要求他们必须逐条阅读并签字确认， StartMode。
整个过程在WMI命名空间root\subscription下完成常规杀软和卸载工具根本看不到， 实操中我建议用PowerShell一次性筛出所有可疑服务 Get-WmiObject Win32_Service | Where-Object {$_.PathName -notmatch system32\\svchost\.exe -and$_.PathName -notmatch system32\\wininit\.exe -and$_.StartMode -eq Auto} | Select-Object Name， 创建白名单脚本 Save as TaskWhitelist.ps1 $allowedTasks (Adobe Flash Player Updater， Microsoft Compatibility Appraiser)$allTasks Get-ScheduledTask | Where-Object {$_.TaskName -notin $allowedTasks}$allTasks | ForEach-Object {if ($_.State -ne Disabled) {Disable-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath}} 设置为每日启动 用任务计划程序创建一个新任务触发器设为“每天凌晨2点”操作为“启动程序”→ powershell.exe 参数填 -ExecutionPolicy Bypass -File C:\Scripts\TaskWhitelist.ps1 。
区域二Run启动项 路径 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run 和 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 操作同样搜索关键词导出备份后删除。
Win工具箱常在此处注入自己的.inf驱动签名或修改ClassInstall32键值目的是劫持USB设备插入事件实现“即插即启”，执行后再用 sc query 服务名 应返回“[SC] EnumQueryServicesStatus:OpenService FAILED 1060”这才是真正删除， 区域三Class键与BHO 路径 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class 和 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects 操作此处不建议全文搜索而应打开Autoruns工具需提前下载切换到“Logon”“Explorer”“Winlogon”等标签页取消勾选“Hide Microsoft Entries”然后按Publisher列排序找出所有未签名或签名无效的条目右键→“Jump to Entry”定位注册表位置再手动删除，WMI残留会导致所有前述清理功亏一篑，它不依赖服务或计划任务而是嵌入Windows底层管理框架， 正确解法 删BHO必须“注册表文件”同步操作，ImagePath若指向非系统路径如C:\Program Files\WinToolBox\helper.dll且Start3自动就必须处理。
验证删除后刷新该路径确认键名消失再用 sc query WtbHelper 应返回“[SC] EnumQueryServicesStatus:OpenService FAILED 1060”， 第二处是 HKLM\SYSTEM\CurrentControlSet\Control\Class ，搜索关键词“WinToolBox”“Wtb”“ToolKit”时必须加上“ClassInstall32”“UpperFilters”“LowerFilters”等字段否则90%的残留会漏掉，必须分区操作每次只处理一个逻辑区域并立即备份，我把过去三年帮客户处理Win工具箱残留时最痛的五个坑整理出来每一个都附带真实场景、错误操作和正确解法， 典型手法是创建一个__EventFilter事件过滤器和一个CommandLineEventConsumer命令行消费者两者通过__FilterToConsumerBinding关联，真正的清理战场不在控制面板而在注册表深处、服务控制管理器、WMI命名空间、计划任务库、以及用户配置文件的AppData隐藏目录里， 5.4 坑四用Autoruns删了BHO但没删对应的DLL文件导致Explorer崩溃 场景 客户用Autoruns删了注册表里的BHO项但没删 C:\Program Files\WinToolBox\shellhook.dll ，必须在最小化系统环境里操作否则正在运行的Win工具箱进程会实时拦截你的删除动作甚至篡改注册表API调用， 服务描述Description为空或含糊其辞 系统服务的Description字段非常明确如“提供Windows更新的后台智能传输服务”。
5.3 坑三删了C:\Program Files\下的目录却漏掉C:\Windows\Temp里的复活脚本 场景 客户删完主程序目录重启后发现任务栏图标又回来了，我把它拆解为七个严格递进的步骤每一步都有明确目标、操作指令和验证方式，它通过注册CLSID在资源管理器地址栏或右键菜单中植入功能，任务名需根据你实际查到的名称替换。
跳过任何一步都可能导致“表面干净实际复活”， Status 这条命令过滤掉所有标准svchost宿主服务只留下独立可执行文件的服务， 这套组合拳下来Win工具箱的安装包在写注册表、建服务、设任务、挂WMI四个环节至少有三个会被当场拦截，这是保命底线，三小时后你发现任务栏右下角又悄悄冒出了那个熟悉的图标重启一次它自动复活想删它的安装目录提示“文件正在被另一个程序使用”用注册表编辑器搜索“wintoolbox”结果跳出27个键值分布在HKEY_LOCAL_MACHINE\SOFTWARE、HKEY_CURRENT_USER\Software、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 三个完全不同的根路径下更诡异的是某个服务名看着像系统自带的“Windows Management Instrumentation”但启动类型却是“自动延迟启动”而它的ImagePath指向的却是C:\Program Files\WinToolBox\svc.exe，每次只删一个键删前导出备份删后立即重启验证， 3.2 步骤二定位并删除主程序目录与用户数据目录 Win工具箱的安装路径极不规范绝不能只删“Program Files”下的文件夹， 正确解法 必须用 sc delete 服务名 命令，请先在正常模式下进入“控制面板→电源选项→选择电源按钮的功能→更改当前不可用的设置”取消勾选“启用快速启动”再重启进安全模式，过滤器监听Win32_ServiceStartTrace事件消费者则执行C:\Windows\Temp\wtb_recover.ps1， 错误操作 只改启动类型没删服务定义，因此它的卸载逻辑天然与标准Windows InstallerMSI机制背道而驰它不依赖.msi包的回滚事务不注册完整的卸载脚本不清理自身写入的WMI提供程序更不会主动注销它偷偷注册的Shell Extension资源管理器右键菜单、Task Scheduler计划任务、以及通过SCMService Control Manager注入的伪系统服务。
3.6 步骤六重启并进入正常模式后的首次扫描 重启后不要急着高兴，实测中95%的Win工具箱安装包在此步报错退出， 验证 执行后打开任务计划程序确认对应任务已消失再用 schtasks /query /tn WtbAutoRecover 应返回“ERROR: The system cannot find the file specified”，。
验证方法很简单打开注册表定位到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler看是否有非微软签名的CLSID再用AutorunsSysinternals工具的“Explorer”标签页直接看到所有加载的Shell扩展及其数字签名状态，你以为结束了不， 3.1 步骤一进入安全模式并禁用所有第三方服务 这是整个清理流程的基石， 3.5 步骤五WMI持久化清除——用PowerShell精准手术 这是最易被忽略也最危险的一步，Win工具箱真正的注册表据点有三处 第一处是 HKLM\SYSTEM\CurrentControlSet\Services 。
它们的触发条件极其狡猾 触发器设为“系统空闲时”“计算机解锁时”“登录时”三重叠加 确保只要用户开机、解锁、或离开键盘超过10分钟任务就必跑一次， 1. 为什么“彻底卸载”比“点击卸载”难上十倍Win工具箱的隐蔽性本质 你右键“程序和功能”找到那个叫“Win工具箱”或“Windows工具箱”的软件点卸载——进度条走完弹出“卸载成功”，Win工具箱的安装包常把核心逻辑放在临时脚本里主程序只是个壳，技术可以教但经验真的只能用时间和错误来换，这一步不是为了永久禁用而是让所有非微软服务在本次会话中彻底休眠方便后续清理， PathName。
DisplayName， 2.4 WMI被忽视的终极持久化阵地 这是最高阶的清理盲区，即使Win工具箱侥幸创建了任务第二天也会被自动关掉， 如何进安全模式 Win10/11下按住Shift键点“重启”→疑难解答→高级选项→启动设置→重启→按F4，我把它称为“四锚清除法”每个锚点都对应一套独立验证逻辑缺一不可， 2.2 服务识别“伪系统服务”的三个硬指标 Windows服务管理器里那些名字像“Windows Update Medic Service”“Diagnostic Policy Service”的未必就是系统服务，我们不等它创建订阅而是监控所有WMI变更并自动拦截， 提示WMI操作需管理员权限且执行后无需重启，这类注册表项往往没有明显厂商名而是用一串GUID标识， 我做过一个实测对比用标准控制面板卸载后用Process Monitor实时监控系统调用发现在卸载进程退出后的47秒内仍有3个独立进程一个隐藏在svchost.exe里两个伪装成rundll32.exe持续向注册表HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run写入启动项同时一个名为“WtbUpdateSvc”的服务虽被标记为“已停止”但其Start值仍为0x3自动且ImagePath未被清空， 验证是否生效 打开任务管理器→“服务”标签页看所有服务状态是否为“已停止”且CPU/内存占用归零，结果重启后资源管理器频繁崩溃事件查看器里全是“Application Error”事件模块名正是那个DLL， 这些坑每一个都让我多花了半天时间补救， 操作设置为“启动程序”并指向一个bat脚本 这个bat脚本本身很小但会动态下载并执行远程payload或者检查服务是否存活若不存在则重新注册，我现在的流程是WMI清理→重启→进安全模式→再查一遍→确认无残留→再进正常模式。
用Process Monitor监控发现是 C:\Windows\Temp\wtb_init.bat 在开机时自动执行它会重新下载并安装全套组件，这不是误操作是反制手段， GoogleUpdateTaskMachineCore。
Win工具箱惯用手法是起一个高度模仿系统服务名的进程并满足以下三个特征 ImagePath指向非System32目录 真正的系统服务ImagePath基本都在%windir%\system32\svchost.exe -k xxx 或 %windir%\system32\wininit.exe，Win工具箱会利用WMIWindows Management Instrumentation创建永久性事件订阅监听系统事件如服务启动、进程创建、注册表修改一旦触发就执行预设的恶意脚本。
在我的测试机上它揪出了5个伪装服务其中3个在控制面板卸载后依然存活，若有任一服务仍在运行说明安全模式未正确加载需重试， 5.5 坑五WMI清理后没重启结果WMI库自动恢复残留 场景 客户执行完WMI删除命令立刻用 Get-WmiObject 查确认无残留就以为完成了，它通常采用三段式部署 主程序目录 80%在 C:\Program Files\WinToolBox 或 C:\Program Files (x86)\WtbSuite 但也有20%会伪装成 C:\Windows\SystemApps\Microsoft.Windows.Cortana_8wekyb3d8bbwe 这类系统目录名实际是符号链接， 创建响应脚本 WmiBlocker.ps1 $query SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA __EventFilter$action {param($event)$filter $event.SourceEventArgs.NewEvent.TargetInstanceif ($filter.Name -match Wtb|ToolBox) {Write-EventLog -LogName Application -Source WmiBlocker -EventId 1001 -EntryType Warning -Message Blocked WMI EventFilter: $($filter.Name)$filter.Delete()}}Register-WmiEvent -Query $query -Action $action -SourceIdentifier WmiFilterBlocker 设置为开机启动 将此脚本加入 C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp 确保每次开机自动加载，这里它会创建一个看似合法的服务项比如名为“WtbHelper”或“WinToolGuard”， 查找订阅 $filters Get-WmiObject -Namespace root\subscription -Class __EventFilter | Where-Object {$_.Name -match Wtb|ToolBox}$consumers Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Where-Object {$_.Name -match Wtb|ToolBox}$bindings Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Where-Object {$filters.Name -contains $_.Filter -or $consumers.Name -contains $_.Consumer} 删除绑定与实例 # 先删绑定再删过滤器和消费者$bindings | ForEach-Object { $_.Delete() }$filters | ForEach-Object { $_.Delete() }$consumers | ForEach-Object { $_.Delete() } 验证 再次运行第一步的查询命令确认返回空数组，Windows在加载Explorer时会按注册表路径去加载DLL若DLL还在就必然加载若DLL被删而注册表还在反而会报错但不崩溃， 验证是否存在此类订阅只需一条PowerShell命令 Get-WmiObject -Namespace root\subscription -Class __EventFilter | Where-Object {$_.Name -like *Wtb* -or $_.Name -like *ToolBox*}Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Where-Object {$_.Name -like *Wtb* -or $_.Name -like *ToolBox*} 如果返回结果说明你的系统已被WMI级持久化，剩下的那个也因无法持久化而变成“一次性玩具”重启即失效。