W11/10讨论区

[image: StartAllBack 装上后 Windows 11 任务栏频繁重启：32 位程序的冲突机制与排查顺序（封面）] 先装 StartAllBack（最新版），再运行挂在任务栏上的 32 位程序，任务栏就会不定时重启。排查的目标是让 StartAllBack 正常用下去——把那个 32 位程序换成 64 位版本。 [image: 一页速查：从现象到处置的排查顺序（故障链 · 三步定位 · 证据等级 · 处置建议）] 🧩 先看前提：StartAllBack 改了什么 StartAllBack 改的不是皮肤，是任务栏实现本身。官方从 3.8（2024-07-31）起的更新说明第一句就是「Fully reimplemented taskbar」，它接手了任务栏实现、任务按钮、位置与布局、系统托盘、自动隐藏、右键菜单与跳转列表、拖放与组合行为——从 Explorer 到任务栏呈现，中间多了一层由它自己实现的任务栏。 故障路径因此变成：explorer.exe / Shell → StartAllBack 扩展 → 它自己实现的任务栏 → 第三方程序与 Shell 交互。这条路径在纯净 Windows 11 上不存在。改动面越宽，和 32 位程序行为叠加后出现兼容性问题的机会越多：同一个程序在原版系统上或许只是接入不成，装上 StartAllBack 之后就可能撞在它实现的那层任务栏上。 它还得跟着系统走：3.9.26（2026-09-21）才正式支持 26H2，3.9.27（2026-09-24）又修了 26H2 的暗色模式问题；当前官网版本 3.9.27。 [image: 32 位程序把任务栏拖崩的四条路径：托盘集成 / Shell 扩展 / 钩子注入 / 跨进程窗口操作] 🧭 结论先说 在装好 StartAllBack 的机器上，一旦运行带托盘图标、会最小化到任务栏的 32 位程序，任务栏就开始不定时崩，触发源就是这个程序。它把自己的功能挂在任务栏的生命周期上——托盘图标、最小化到托盘、AppBar 注册、Shell 扩展、全局钩子、跨进程窗口操作，其中任何一环出错，异常终止的都是 explorer.exe，用户看到的就是任务栏重启。 64 位 explorer 不能加载 32 位 DLL，这类程序只能走间接路径。这些路径恰好是任务栏故障最集中的地方。 第一步：先找本机还在跑的 32 位程序 遇到任务栏不定时重启，先把还在运行的 32 位程序找出来。这类故障的现场特征：程序本身一切正常、功能都能用，任务栏却时不时崩一次。这种情形最隐蔽，靠感觉对不上号。 怎么找：任务管理器 → 详细信息 → 右键列标题 → 勾选「平台」列。这一列直接标出每个进程是 32 位还是 64 位。老习惯里进程名后带 *32 的也是 32 位进程。 接着筛选：哪些 32 位程序是常驻的。重点看这几类： 有托盘图标、关掉窗口还在后台运行 会最小化到任务栏 / 系统托盘 装了右键菜单、图标覆盖、缩略图这类 Shell 扩展 带桌面挂件、任务栏小工具 只有这些常驻程序把功能挂在任务栏的生命周期上，才有能力把任务栏拖崩；用完就退的 32 位程序不在此列。 典型例子：旧版 QQ。老版本 QQ 是 32 位程序，装上去一切正常，但它常驻托盘、右键菜单与图标覆盖都挂在 Shell 上，任务栏就会不定时崩。这类“装上去没毛病”的机器，先查旧版 QQ 这类常驻 32 位程序。 [image: 旧版 QQ 是最典型的例子：托盘图标、Shell 扩展、最小化到任务栏的常驻窗口，三条钩子都挂在任务栏（explorer.exe）上，代价由宿主承担] QQ 的版本现状（2026-09-29 实拍核对）：QQ 官网 PC 下载页的主按钮写明「Windows 64位 版下载」，标注版本 v 9.9.36（64 位）2026-09-24；同一行次要链接里仍并列提供「32位 版本下载」「ARM 版本下载」「往期怀旧版下载」，其中怀旧经典版 9.7.25 是 32 位。正确做法：在 64 位系统上装主按钮那个 64 位版，不要点次要链接里的 32 位版或怀旧经典版。 [image: QQ 官网 PC 下载页：主按钮是 Windows 64位 版下载，32 位版本下载留在下方次要链接里] [image: 先找还在跑的 32 位程序：平台列筛选 → 挑出常驻项 → 换 64 位版本 → 不可替代的才保留] 🪟 先确认“任务栏重启”重启了什么 “任务栏重启”在用户眼里是同一个现象，对应三种不同机制： 整体重建 — 桌面图标、任务栏、开始菜单一起消失 1–3 秒后回来，实际是 explorer.exe 进程终止后重启 只有任务栏重建 — 任务栏自身闪烁重绘，桌面图标不动，属于任务栏 UI 宿主组件在 explorer 内重建窗口 第三方定制组件重建 — 自定义样式短暂丢失，恢复后回到定制外观 三种容易混在一起，是因为任务栏定制工具与 explorer.exe 在同一进程里改任务栏、开始菜单的绘制与交互：explorer 被第三方模块搞崩，它跟着重建；它自己的模块出错，崩的也是 explorer。先装 StartAllBack、后运行 32 位常驻程序的机器，才会出现这种频繁重启。 定制工具通常是同一场崩溃里的冲突一方或受害者，第一嫌疑应该给那个常驻托盘的 32 位程序。 🧩 四条接入路径 下面四条是实际故障中最常见的接入方式，按排查优先级排列。除此之外，COM LocalServer、IPC / RPC、UI Automation、辅助服务、第三方注入框架等也可能成为入口。 路径 1：托盘图标、最小化到任务栏与 AppBar 这是“最小化到任务栏以后任务栏开始不定时崩”最典型的一类。程序通过 Shell 的通知接口注册托盘图标，用 AppBar 把自己的窗口注册成任务栏侧的停靠栏，用任务栏按钮与进度接口改自己的任务栏按钮，或者把主窗口最小化进托盘长期驻留。 这些接口要么是跨进程消息，要么依赖 Shell 维护的一份窗口注册状态。程序在任务栏上留下一个常驻窗口和消息处理循环，任务栏每次重绘、重建、切换虚拟桌面、插拔显示器，都会走到它的消息处理。它的消息处理阻塞、抛异常、销毁了窗口却没注销注册，或者注册与注销的时机和 Shell 的重建撞在一起，explorer 侧就会卡住或异常终止。 判断起来有特征：现象与“程序是否在运行”强相关，退出该程序后任务栏稳定；事件日志里往往看不到它的名字，因为异常爆发点在 Shell 侧。 路径 2：Shell 扩展 右键菜单、图标覆盖、缩略图、属性页这类 Shell 扩展是 COM 组件，运行在 explorer.exe 进程内部。 32 位进程不能向 64 位 explorer 注册 in-process 扩展。所以只提供 32 位版本的软件想挂右键菜单，通常只有三条路：改成 out-of-process 的独立辅助进程；走 32 位 shell 宿主（旧做法，新系统已基本不适用）；用全局钩子、注入的方式强行进入，这条风险最高。 扩展在 explorer 进程内抛出未捕获异常、访问越界或空指针解引用，会直接终止宿主进程。用户看到的就是桌面与任务栏一起黑掉再回来。故障模块名会记录在事件日志里。 路径 3：全局钩子与 DLL 注入 为拿系统级输入（热键、鼠标、窗口消息），部分程序会安装全局钩子或把 DLL 注入其他进程。注入模块的运行时机、线程上下文、消息循环都不受它自己掌控，一旦在 explorer 的消息循环里阻塞或崩溃，连锁反应就是整个 shell。 典型症状是间歇性，只在特定交互（在任务栏上右键、悬停、拖拽）时触发，因为只有那些消息会进入注入模块的代码。 路径 4：跨进程窗口操作与 Shell 状态竞争 这类程序用 FindWindow、SetWindowPos、SetParent、SendMessage、PostMessage 之类的接口去查找或操作任务栏窗口，常见于“任务栏透明”“置顶”“改高度”这类小工具。 单独一次针对无效 HWND 的调用通常只返回失败，并不足以直接让 explorer.exe 崩溃。真正会出事的是跨进程窗口操作与 Shell 状态变化之间的时序竞争：程序持续假设任务栏窗口、窗口层级或状态始终有效，而 explorer 或定制组件此时正在重建相关窗口，两者形成重入或生命周期错配。 它的表现比较特别：异常终止的是任务栏宿主，发起操作的一方通常不受影响。 🧷 StartAllBack 在这条链里的角色 开头已经交代：它改的是任务栏实现本身，系统与它的状态在一条链上。在一条具体故障里，它可能是下面三种角色之一，需要靠证据区分： 直接故障模块 — 异常发生在它自己的加载模块里，故障模块名直接指向它的 DLL 冲突的一方 — 它和某个 Shell 扩展或注入模块在同一进程内互相影响，单看任一方都不足以解释崩溃 同步受害者 / 重建参与者 — explorer 被杀，它随之重建；重建时它正在处理状态，就可能出现“重建失败 → explorer 再崩”的循环 这类工具依赖系统内部的未公开结构，累积更新可能改变这些结构；“升级系统后 explorer 反复崩溃、换到匹配版本才恢复”的情况出现过。 排查先做一次归因分离：把 StartAllBack 临时禁用，观察任务栏是否仍出现重启。禁用后不再出现，触发路径在它与其它 Shell 组件的共同作用点上；禁用后仍然出现，它可以从直接触发源里排除。这一步只是诊断动作，不是处置：StartAllBack 要保留，临时禁用的作用是把故障链的方向看清——方向确认之后，要动的是那个 32 位常驻程序。 要做成对照，两轮用同一个 32 位程序、同一套操作：禁用 StartAllBack 跑一轮，启用之后再跑一轮。原生那一轮不崩、装了那一轮崩，方向就从「这个 32 位程序本身有什么毛病」移到「32 位程序的行为 × StartAllBack 的任务栏实现 × 当前系统构建」这个组合上——兼容性问题落在这段组合里，不在其中任何单独一项上。 用证据把范围收紧 [image: 证据等级 A–E：证据强度决定归因能否成立] 优先用高等级证据完成归因，低等级证据只用于缩小调查范围。 第 1 步 · 事件查看器取故障模块名（约 2 分钟） Win + R 输入 eventvwr.msc，进入 Windows 日志 → 应用程序，找来源为 Application Error、事件 ID 1000 的条目。正文里会写明（示例）： 出错应用程序名称: explorer.exe 出错模块名称: [具体某个 DLL] 模块路径: C:\...\[某个软件的安装目录] 异常代码: 0xc0000005（示例） 故障模块是最重要的第一条线索，但不一定等于真正的根因模块。它直接指向某个第三方 DLL、并且故障可以稳定复现时，归因价值较高；只显示 ntdll.dll、KERNELBASE.dll、ucrtbase.dll 这类系统组件时，异常只是最终爆发在通用运行库上，真正破坏内存或状态的第三方模块可能更早已经执行完成，这种情况要结合 Dump、调用栈、模块加载情况或行为复现继续判断。路径 1 和路径 4 常常属于后一种——日志里甚至没有第三方模块名。 异常代码常见的三种： 0xc0000005 — 访问冲突，读写已释放内存、空指针解引用、缓冲区越界 0xc000001d — 非法指令，通常是 DLL 与 CPU 指令集或系统版本不匹配 0x80000003 — 断点异常，调试残留或代码里显式的调试中断 第 2 步 · 退出常驻程序 + 二分排除扩展（约 10 分钟） 先做路径 1 的验证：把可疑的 32 位程序从托盘退出，或者关掉它的开机自启，重启 explorer，观察是否还崩。这一步能直接确认“就是这个程序”，成本最低。 再用 ShellExView 以管理员身份运行，隐藏微软自带的全部扩展，剩下的就是第三方扩展。然后对半禁用、重启 explorer：问题消失，元凶在被禁的那一半里；问题照旧，在仍启用的那一半里，折半收敛。40 个扩展最多 6 轮就能定位到单个扩展（属于 C 级证据）。 第 3 步 · 行为证据（路径 4 专用） 前两步都干净时重点怀疑路径 4。记录程序动作与任务栏重启的时间对应关系。因为操作方不崩，事件日志里不会留下它的名字，这类证据只到 D 级。把该程序退出后重启 explorer，观察是否还发生，才可能把相关性提升为可确定的归因。 ️ 处置手段与各自的边界 换成 64 位版本 — 首选手段，直接掐掉触发源。代价只是重新下载安装一次，配置和账号都能迁过来 退出问题程序、取消其开机自启 — 换版本之前的临时处置，稳定性立刻恢复，代价是失去该程序的功能 禁用问题 Shell 扩展 — 路径 2 已定位到具体 DLL 时使用。损失一个右键项或图标覆盖，代价较小，也容易恢复 退出引发操作的程序 — 路径 4 的唯一有效手段，它的行为方式无法通过配置修正 升级 StartAllBack 到匹配系统版本的版本 — 只解决版本错配，解决不了第三方扩展或托盘程序的缺陷 临时禁用 StartAllBack 做归因分离 — 定位阶段的第一步，这是诊断手段而不是修复手段，定制外观会丢 卸载 StartAllBack — 定制功能一并放弃，冲突的 32 位程序仍然留在系统里，故障前提没有解除 重装系统 — 在没有模块名、没有排除结果的情况下重装，等于放弃归因，问题会随软件一起装回来 🧪 一次实测：换掉两个 32 位常驻程序之后 测试机器上就是这种配置：StartAllBack 已装好（最新版本），随后运行的两个 32 位常驻程序把功能挂在任务栏 / 托盘上，任务栏开始不定时重启；把这两个程序换成 64 位版本后，问题未再复现。 这次涉及两个常驻程序： KeyNote.exe — CapsLock Indicator 的组件，管大小写切换的提示浮窗，常驻托盘、随系统启动 TIM 精简绿色版 v3.5.0.22143 — 第三方精简版，同样常驻托盘 两个程序功能都正常，任务管理器「平台」列显示它们都是 32 位。 替换动作只有两步： KeyNote.exe → keyboard-lock-osd.exe，也就是 本站此前介绍过的 Keyboard Lock OSD——MIT 协议、常驻托盘，官方发布包只有 x64。功能对得上：都是锁定键状态的屏幕提示。 TIM 精简绿色版 → QQ 64 位版（官网主下载按钮那个） 这次结果属于 C 级证据：稳定复现 + 换掉组件后问题消失。它比「时间上相关」的 D 级硬，但没到 A、B 级——这次没有抓 Crash Dump，事件日志里也没拿到故障模块名。 [image: 一次实测：KeyNote.exe 与 TIM 精简绿色版两个 32 位常驻程序换成 keyboard-lock-osd.exe 与 QQ 64 位版后，任务栏不定时重启未再复现（C 级证据）] 结论与最终建议 让 StartAllBack 正常使用，靠的是换掉和它冲突的 32 位常驻程序，不是卸掉它自己。除非程序不可替代，否则所有程序都使用 64 位版本。确实只有 32 位版本的，至少别让它常驻托盘或最小化到任务栏。QQ 用官网主下载的 64 位版。 执行顺序：任务管理器「平台」列找出常驻 32 位程序 → 换 64 位版本 → 换不掉的退出常驻 → 仍异常再用事件记录与 Dump 收尾。

[image: WLite Windows 11 26H2 精简版] 占用低不低，空载看不出来——得在同时干几件事的时候看。 一台机器到底抗不抗得住，空载时那两行数字说明不了什么。真正有参考价值的是这种状态：虚拟机在跑系统初始化，宿主机上还开着浏览器和音乐播放器，一边占 CPU、一边占内存、一边占网络。 下面记录的是这个状态下的实际读数。 测试环境 宿主机 ｜ Intel Core i9-13900H（14 核 20 线程）｜ 63.7 GB 内存 ｜ SSD 显卡 — Intel Iris Xe 核显 + NVIDIA GeForce RTX 4090 Laptop GPU（16 GB 专用显存） 测试系统 — Windows 11 26H2 精简版，Build 26300.9445 运行方式 — VMware Workstation 虚拟机内运行 系统体积 — 1.79 GB 负载状态下的读数 截图时的状态：虚拟机在做系统初始化，宿主机同时开着浏览器和音乐播放器。 [image: 任务栏实时监控] CPU 占用 — 10% 内存占用 — 46% CPU 温度 — 66.0 °C GPU 温度 — 70.0 °C 这两个温度不是空载温度——是虚拟机系统初始化过程中，整机在持续工作时的读数。CPU 与 GPU 分别在 66 °C 和 70 °C 附近，风扇没有拉满。 任务管理器实测 [image: 任务管理器 CPU] CPU 负载 34%，当前频率 4.21 GHz（基准 2.60 GHz）。内存 30.3 GB / 63.7 GB（48%）。进程数 266，线程 4247。 正常运行时间 1:20:48:41 —— 约 3 天 20 小时持续开机，没有重启。长时间挂机之后系统没有变卡、没有积压出异常占用。 [image: 任务管理器 核显] 核显 Intel Iris Xe，利用率 3%，共享显存占用 0.4 / 31.8 GB。 [image: 任务管理器 独显] 独显 RTX 4090 Laptop，利用率 23%，温度 62 °C，专用显存占用 1.2 / 16.0 GB，共享显存 0.3 / 31.8 GB，GPU 内存合计占用 1.5 / 47.8 GB。 🧭 这组数字说明什么 内存余量 64 GB 里用掉约 30 GB，还有 33 GB 可用。这里面包含了虚拟机、浏览器和音乐播放器的开销。也就是说，在同时跑一个完整虚拟机的情况下，还留着一半以上的内存没动。 CPU 余量 虚拟机系统初始化本身是吃 CPU 的活，加上浏览器和音乐播放器，负载也在 10%–34% 的区间。20 个线程里还有空闲核心随时接手突发任务。 温度 CPU 66 °C、GPU 62–70 °C，风扇没有满转。这个温度是在虚拟机初始化 + 浏览器 + 音乐播放器同时在跑的时候测的，不是空载读数。 长时间运行的稳定性 3 天 20 小时不重启，进程数与句柄数没有异常膨胀。后台没有反复拉起又杀掉的循环——这是精简掉自动更新、遥测、推广组件之后的表现。 适合什么场景 虚拟机与多任务 一台机器同时干几件事 — 上面这组读数就是这个场景 体积 — 1.79 GB，快照、克隆、批量部署都轻 低配与老机器 内存 — 后台服务少，可用内存回升 机械硬盘 — 不再被后台服务反复读写 硬件门槛 — 已放宽，无 TPM 校验 游戏 帧数稳定性 — 无更新与遥测服务争抢资源 叠加层 — 已移除 Game Bar 组件，不弹叠加层 🧼 纯净无广告 基于原版母盘制作，系统里没有夹带任何广告与第三方推广，也没有任何首页绑定。装完是什么样，你用到的就是什么样。 无任何广告 — 系统内不含广告位、推广弹窗与推荐内容 不含任何推广 — 不捆绑、不预装第三方软件，不推全家桶 无首页绑定 — 浏览器主页、默认搜索保持系统状态，不改你的设置 无开机弹窗 — 不弹推广、不推活动 装什么都在明处 — 集成的工具逐项列清，看得见、可卸载 更新记录 2026.09.22 更新 补充 26H2 精简版在虚拟机与多任务并行负载下的实测记录； 2026.09.13 更新 修复首次进入桌面无法修改壁纸的 BUG； 2026.09.11 首次发布 Windows 11 26H2 26300.9445 精简版首次发布； 移除 497 个组件、87 个语言包、215 个键盘布局； 集成嵌入式锁定管理器（统一写过滤 UWF）、NVIDIA 控制面板、dig 等工具； 系统默认已激活，装完即用。 ️ 下载地址 Windows 11 26H2 精简版 ｜ 1.79 GB 下载与校验信息：见《Windows 11 26H2 26300.9445 精简版》主题帖 主题帖：https://wlite.cn/topic/476 ️ 安装说明 ESD 格式，用 PE 下的安装工具（WinNTSetup、Dism++ 之类）释放到目标分区，然后引导安装。建议全新安装，装之前把重要数据备份好。 ️ 注意事项 以上读数为单次实机记录，场景为虚拟机系统初始化 + 浏览器 + 音乐播放器并行；不同硬件与使用习惯下结果会有差异。 精简后不再包含更新与修复相关组件，系统版本固定，装前请确认符合你的使用场景。 装完第一次进桌面时，系统可能自动完成组件安装并重启一次，属正常流程，别打断它。

[image: WLite 安卓客户端界面] WLite 安卓客户端 论坛有安卓客户端，装完就能用手机看帖、回帖、收消息。 ️ 下载 地址 — https://wlite.cn/app 版本 — v0.3.3 系统要求 — Android 8.0 及以上 能做什么 看帖 — 帖子列表和正文按手机屏幕排版，滑动流畅 收藏 — 看到有用的内容一键收藏，回头随时翻 分享 — 好资源随手发出去 消息 — 评论、回复、私信都会提醒，不用一直刷网页 v0.3.3 更新 徽章在帖子、评论、私信里统一显示，尺寸和网页端一致 搜索结果恢复显示真实作者与分类 消息页拆成通知与私信两个分页 私信会话自动刷新，支持发送图片 编辑器增加 Markdown 快捷输入栏 说明 装完登录，和网页端同一个账号 有更新会在这个帖子与 APP 页面里写明

[image: 下载链接清理] 站内系统帖的下载链接已整理 这两天把站内系统帖的下载链接过了一遍，统一整理成一份。 整理内容 重复链接 — 同一个文件在帖子里出现多次的，只保留一份 历史版本 — 同一个系统发布过多个版本的，每个帖子只保留最新版本 老版本 — 链接已撤下 ️ 现在的样子 打开任意一个系统帖，下载地址一栏就是当前版本： 一个链接 一个校验值 一个提取码 说明 帖子里提供的就是当前版本，直接下就行 老版本链接不再提供