乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > 和 WPS 的＂自启动＂斗智斗勇了一晚上,最后一招才管用

和 WPS 的＂自启动＂斗智斗勇了一晚上,最后一招才管用

当前时间： 2026-06-29 14:04:10 更新时间： 2026-06-29 分类：软件教程 评论(0)

和 WPS 的＂自启动＂斗智斗勇了一晚上,最后一招才管用

 一个国产办公软件,怎么这么”流氓”无底线.

从计划任务、注册表、文件重命名一路封到 NTFS 权限——一个国产办公软件的自愈能力，比我想象中顽强得多。

事情是这样的：前段时间我重装系统，把 WPS Office 装回去之后，每次开机先安静二十分钟左右，wpscloudsvr.exe、wps.exe、promecefpluginhost.exe 就一个接一个冒出来。任务管理器里杀一遍，过会儿又自己复活。我那台机器本来就只剩 16G 内存，WPS 这一通”云同步”下来，开个浏览器都卡。

于是我决定和它正面硬刚——从最常规的计划任务开始，一路试到了 NTFS 文件权限，才发现这个看着挺大众的办公软件，自愈能力堪比一只打不死的小强。

症状先说清楚

我的机器是 Windows 11，WPS Office 个人版最新安装包。表现非常稳定，几乎可以复现：

  • 开机登录后，桌面和任务管理器干干净净；
  • 大约 25 分钟后，wpscloudsvr.exe 突然出现，紧接着 wps.exe、promecefpluginhost.exe 跟着起来；
  • 强行结束进程后，短时间内会被另一个父进程再次拉起；
  • WPS 设置里”开机自启动”明明是关着的，结论是设置项被无视。

为了不被”是不是我电脑有问题”误导，我一边自己排查，一边把整条排查线丢给 AI 帮我交叉验证，AI 给出的总结和我现场看到的现象基本一致。下面这 10 条是 AI 总结出来的已尝试路径，以及每条实际跑下来的结果。

AI 帮我汇总的 10 条失败路径

1. schtasks /Delete 删除计划任务 失效 WPS 自身会重新注册同名的 WpsUpdateLogonTask_用户名 任务。2. Disable-ScheduledTask 禁用计划任务 失效 同上一条：禁用后又被自动启用。3. 删除 C:\Windows\System32\Tasks\WpsUpdateLogonTask_用户名 任务文件 失效 WPS 会立刻把这个任务文件重新写出来。4. 在任务文件位置放占位空文件 + 拒绝写入权限 部分有效 任务文件被锁成 3 字节，WPS 恢复不出完整的任务逻辑；但 WPS 仍然能从别处启动。5. 把 wpscloudsvr 服务设为 Disabled 部分有效 服务确实禁用了，但 wpscloudsvr.exe 仍会作为独立进程被拉起。6. 清空 / 锁定 wtoolex 文件夹（拒绝写入） 部分有效 WPS 无法恢复更新文件，但主程序仍能从其他路径启动。7. 改注册表 HKCU\Software\Kingsoft\Office\6.0\office：isDeskTopAutoStart=0 / EnableCloudSvr=0 / bAutoStart=0 / AutoUpdate=0 失效 WPS 直接忽略这些键值，下次启动又把值改回去。8. 把核心 exe 改名：wpscloudsvr.exe、wps.exe → .bak 失效 WPS 通过 wpsoffice.exe 等进程自动恢复被改名的文件。9. 用 Process Monitor / 任务管理器追踪进程启动链 线索 发现 wpscloudsvr.exe（PID 2244）由 PID 6500 拉起，6500 已退出无法追踪；ksomisc.exe 也参与了进程恢复；WPS 注册了多个 COM Shell 扩展（kwpsshellext、WpsDrive BHO 等）。10. 用防火墙阻止 WPS 更新程序联网 失效 执行时提示权限不足，没能落地。

从这 10 条里读出来的两个事实

第一，WPS 的自启动是 多通路冗余 的：计划任务、服务、Shell 扩展、主程序自我修复——任何一条被掐断，它都会从另外几条补回来。这意味着你不能用”单点封堵”思维，得找到一条 所有通路都必须经过的咽喉点。

第二，AI 帮我捋清了一条完整的进程关系链，用纯文本画出来是这样（用箭头表示启动关系）：

看图就明白了：ksolaunch.exe 几乎是所有自启动通路的 必经咽喉。只要让这个文件 永远无法被加载，上面这棵子树自然就断电了。

【重要前置】接下来要做的不是”删”也不是”改名”，而是 利用 NTFS 权限让它在原地、却再也跑不起来。这样既不会被”自我修复”覆盖，也不会破坏你正常点开 WPS 文档时主动启动的主进程链。

最终解法：给 ksolaunch.exe 上 NTFS 权限锁

思路很朴素——既然文件删了会被恢复、改名也会被恢复，那就 让它在原位、但任何进程都没有权限”写入和执行”它。Windows 的 NTFS ACL 优先级高于”自恢复”逻辑：哪怕 WPS 想把文件写回来，写不进去就写不进去；想把它加载成进程，没有执行权限就跑不起来。

风险提示（动手前先看）

  • 此操作需要 管理员权限；
  • 会影响 WPS 的”开机自启 / 静默云同步”等行为，注意也会影响你双击 .doc / .xlsx 等无法使用 WPS打开，相当于wps软件以及不能启动使用,但不会卸载 WPS；
  • 如果你以后想恢复自启动，反向操作 即可：把那个 Everyone 拒绝条目删掉，重新启用继承；
  • 若系统重装或 WPS 大版本升级，ksolaunch.exe 路径可能变化，需要重新定位。

第一步：定位 ksolaunch.exe

默认在 WPS 安装目录下，例如：

C:\Users\<你的用户名>\AppData\Local\Kingsoft\WPS Office\<版本号>\office6\ksolaunch.exe

如果找不到，可以打开任务管理器，杀掉正在跑的 WPS 进程，右键 → 打开文件所在的位置，直接定位到那个目录。

第二步：打开高级安全设置

  1. 在 ksolaunch.exe 上 右键 → 属性；
  2. 切换到 「安全」 选项卡；
  3. 点击右下角的 「高级」 按钮。

第三步：禁用继承 + 复制现有权限

进入”高级安全设置”窗口后，先做权限继承的清理：

  1. 在窗口底部或顶部找到 「更改权限」 / 「编辑」（不同 Windows 版本措辞略有差异）；
  2. 点击 「禁用继承」(Disable inheritance)，在弹出的对话框中选择 「将继承的权限转换为此对象的显式权限」（”Convert inherited permissions into explicit permissions on this object”）；
  3. 这一步之后，继承自父目录的权限条目会全部变成显式条目，我们接下来就可以安全地往里面加拒绝规则，而不会被父目录的允许规则”反向覆盖”。

【原理】NTFS 权限里，「拒绝(Deny)」优先级高于「允许(Allow)」。只要我们在 Everyone 上加一条”拒绝 写入和执行”，哪怕 WPS 进程本身是 Administrators 组成员、哪怕它拥有这个文件，也仍然加载不了它——这是和”加黑名单”完全相反的 白名单兜底 思路。

第四步：给 Everyone 加拒绝规则

  1. 仍在”高级安全设置”窗口中，点击 「添加」(Add)；
  2. 主体选择 「Everyone」（部分系统显示为 Everyone 或 全部）；
  3. 类型保持 「拒绝」(Deny)；
  4. 在「应用到」里选择 「仅此对象」(This object only)，避免误伤到同目录其他文件；
  5. 在「基本权限」里勾选 「读取和执行」 与 「写入」（也可以同时把”读取”也勾上，最稳），最终效果是 拒绝 写入和执行。

第五步：保存并验证

一路点 应用 / 确定 退出。如果 Windows 弹”您正在设置拒绝权限条目”的二次确认，直接选 「是」。

【成功标志（按顺序自检）】

  1. 在 ksolaunch.exe 上再次右键 → 属性 → 安全，能看到一条 Everyone 的拒绝条目，且包含 读取和执行 / 写入；
  2. 以 普通用户身份 双击 ksolaunch.exe，系统弹出「Windows 无法访问指定设备、路径或文件」错误；
  3. 重启电脑
    ，登录后不再出现 25 分钟倒计时：wpscloudsvr.exe、wps.exe、promecefpluginhost.exe 都不再自启；
  4. 任务管理器 → 详细信息 → 添加列 “命令行”，里面不再有 ksolaunch.exe 相关条目；

为什么这一招前面 9 招都没解决

回头看，前面那些方法的共同问题是 在和”自恢复”赛跑：

  • 删任务 / 禁任务 → WPS 重新注册；
  • 改注册表 → WPS 下次启动把值改回去；
  • 改文件名 → WPS 用另一个进程把文件写回来；
  • 禁服务 → 主程序绕开服务直接拉进程。

而 NTFS 权限是 操作系统内核层面的强制访问控制，不属于”用户态配置”——WPS 即便拿到了管理员权限，在 ACL 没有改回去之前，它的每一次”写入”和”加载执行”都会在内核被拒绝。这是它最薄弱的一环：它能改自己的配置、改自己的文件，但 改不动文件系统的权限位。

给你的一句话总结

封 WPS 自启动的最短路径：找到 WPS 安装目录下的 ksolaunch.exe，禁用继承 + 给 Everyone 拒绝 读取 / 写入 / 执行，保存退出，重启验证。

这一招对”自我修复”免疫，对 Shell 扩展免疫，对计划任务免疫，对联网更新也免疫——因为它的根因不在配置层，而在 文件能否被加载。

这篇文章不是要声讨谁，只是觉得：一个文档办公软件居然需要用户动到 NTFS ACL 才能关掉自启动，这件事本身就挺值得记一笔。AI 帮我把分散的失败路径汇总成了”通路图”，让我一眼看到 ksolaunch.exe 才是咽喉点；剩下最后是凭这点思路自己动手验证出来的。

写在最后,只想说一句: 金山WPS,请你好好做个人吧,请把心思放在怎么更好优化软件和服务用户上.

声明： 本文操作涉及对系统目录文件权限的修改，请在使用前确认你了解每一步的含义。作者不为因照搬本文操作导致的系统问题负责——但只要按”成功标志”自检，出问题的影响范围也只限于 WPS 自身，可以随时反悔。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧～

谢谢你看我的文章，我们，下次再见。

/ 作者：赛博兔AI工坊 / 交流爆料联系邮箱：332302158@qq.com