微软发布 Windows 11 24H2/25H2 KB5094126 号更新，修复系统重启、虚拟化操作和运行某些游戏时出现的黑屏死机问题。 该更新也在继续扩大 UEFI CA 2023 安全启动证书的覆盖范围，对于受支持的设备系统将自动接收和部署新安全启动证书。 离线文件下载地址： https://www.landian.news/download/113430.html 1 个帖子 - 1 位参与者 阅读完整话题
日常是 Claude Codex 和 Antigravity 一起上，搞不同项目。这两天不知道啥原因，让 AntiGravity 去查某个问题的时候，它似乎是触发了项目构建，然后就直接 CPU 和内存飙涨，直到把跑死机！！只能强制重启设备，搞得我现在只能强制提醒它，只查问题，不要构建/ 9 个帖子 - 4 位参与者 阅读完整话题
去年换了台 Lenovo 笔记本，结果经常性死机，鉴于上述状况以及要用 codex 等工具，打算入手 MacBook air 。人在魔都，魔都的国补要摇号（很恶心），线上概率很低而线下概率高。所以问一下：线下的门店有搞 618 优惠，同时可以使用国补、教育补贴的么？ 要求： 产品要正品、可靠 可以用国补、教育优惠 有活动优惠，目前 JD 是优惠 500 元。
去年换了台 Lenovo 笔记本，结果经常性死机，鉴于上述状况以及要用 codex 等工具，打算入手 MacBook air 。人在魔都，魔都的国补要摇号（很恶心），线上概率很低而线下概率高。所以问一下：线下的门店有搞 618 优惠，同时可以使用国补、教育补贴的么？ 要求： 产品要正品、可靠 可以用国补、教育优惠 有活动优惠，目前 JD 是优惠 500 元。
去年换了台 Lenovo 笔记本，结果经常性死机，鉴于上述状况以及要用 codex 等工具，打算入手 MacBook air 。人在魔都，魔都的国补要摇号（很恶心），线上概率很低而线下概率高。所以问一下：线下的门店有搞 618 优惠，同时可以使用国补、教育补贴的么？ 要求： 产品要正品、可靠 可以用国补、教育优惠 有活动优惠，目前 JD 是优惠 500 元。
昨天搓炉石搓一半死机了，电脑直接断电重启，结果卡在开机页面，然后打算用U盘进PE，结果一直黑屏进不去，上网查了下切换低分辨率也不行，然后把两块机械硬盘拔了能正常进PE能正常开机了无语，插回机械硬盘也正常开机，浪费了2小时排查。 话说在浏览帖子的时候，除了返回最上面新建话题还有别的方法能新建话题吗？ 2 个帖子 - 2 位参与者 阅读完整话题
零刻的 amd 迷你主机，最近就升级了一下 windows 的官方系统升级，打开机壳清了一下子灰，现在就出现了以下情况： 1）每次冷机情况下开机，在还没见到 windows 登录界面之前就黑屏死机了，强制重启之后就好了； 2）进入 windows 之后，有时候几秒钟，有时候几分钟，有时候十几分钟后就死机，鼠标、键盘都无法操作，死机之前先出现鼠标卡滞的情况； 3）打游戏的时候很少出现死机，但是昨天在游戏情况下出现了，是我从游戏中切换出来之后，再回到游戏界面就死机了。 请教给位佬，有没有遇到同样的情况的。感谢了。 5 个帖子 - 5 位参与者 阅读完整话题
在过去一段时间里已经有不少惠普高端笔记本电脑用户抱怨安装 BIOS 固件更新后设备出现问题，用户可能遇到的问题包括设备无法正常启动、风扇不受控制的高速运转以及 Windows 11 出现黑屏死机等严重影响用户使用的问题。 例如有网友使用的惠普移动工作站 ZBook G1A 就因为更新 BIOS 固件导致设备在启动过程中完全卡住，在 REDDIT 论坛里也有其他网友反馈类似的事情，而问题根源则是惠普通过微软发布的 BIOS 固件更新，该更新被标记为关键更新自动推送给 Windows 10/11 用户。 惠普向不同设备推送的固件更新版本略有不同，例如 ZBook G1A 收到的问题固件版本为 01.04.03 和 01.04.05，而 EliteBook X G1A 收到的问题固件更新为 01.03.11 和 01.05.00，值得注意的是 BIOS 固件更新完成后想要回滚并不容器，有用户称使用网络 BIOS 降级功能可以成功回滚，但这仅限于使用 HP USB-C 转以太网适配器。 惠普在设备固件更新领域可谓是臭名昭著，在 2024 年惠普发布的 BIOS 固件更新就导致部分设备彻底损坏，用户不得不将设备送到惠普支持中心进行维修，部分早期用户甚至还是自己支付费用更换主板等造成严重的经济损失。 目前惠普公司已经注意到用户提交的反馈并正在调查，惠普称任何遇到问题的用户都可以联系惠普支持团队寻求帮助，不过现阶段惠普并未提供任何潜在解决方案或承认最新发布的 BIOS 固件存在问题。 查看评论
最近闲鱼买二手手机（红米的lcd屏幕），手机4g信号断联，长时间待机会死机，更长时间会彻底开不了机而且充不了电，第二天充电重启了。 问ai这种情况是： 4G 射频 PA 芯片（功率放大器）短路漏电 ，或者它周边的 供电电容击穿 了。 这里的教训： 闲鱼设置了3天自动收货（之前一直都是7天） 规则内尽量延长收货（之前看卖东西的帖子嫌弃收货时间长，产生同理心，这次失算了） 有问题马上找卖家（刚开始第二天就出现4g信号断联，开始还以为是系统优化不行，5g好的，结果第四天各种故障） 目前投诉处理结果 下架卖家所有商品并禁止至少7天内发布直至还款或者配合买家解决投诉纠纷。 这个我不指望卖家能够退货还款。过几天到手机维修点看看修理需要多少钱。 1 个帖子 - 1 位参与者 阅读完整话题
我的电脑是 MacBook pro M1 MAX,系统版本是 macos 26 最新版本，当使用系统自带的 finder 访问局域网，Windows 系统共享的文件夹时候发生卡死黑屏重启现象，不是偶然，是必然发生。用的是 smb://192.168.X.X 等 IP 地址直接访问的方式。 能够进入访问页面的第一层看到文件夹，但当点击进入某个文件夹时，就发生死机现象，鼠标无法移动，黑屏死机然后自动重启。 请问这是普遍现象吗，应该如何解决这个问题，似乎是 finder 本身的问题。
先说结论：Cursor 的某些操作例如自动更新过程在高内存压力场景下触发了极端 I/O 风暴，并高度疑似诱发 Apple Silicon watchdog reset。直接导致 Apple Silicon Watchdog 硬件强制复位------屏幕一黑，秒重启，什么提示都没有，只在 DiagnosticReports 里留下一个 ResetCounter。 疑似Cursor 的 updater workload 触发了 Apple Silicon 某个 VM/APFS/IOKit 路径里的 starvation bug。 一晚上三次，19:15、20:35、22:07，每次都是同一个原因。我是用系统诊断报告一步步追到的根因，证据全在下面。 现象 电脑正常使用中，突然黑屏 没有任何 beach ball、没有卡顿、也没有"你的电脑因为出现问题而重新启动"的提示 就是一瞬间黑掉，然后 Apple logo 亮起，重启完成 打开的所有东西没了，"重新打开窗口"救不回来 Console.app 里这个时间段的日志是空的------统一日志缓冲区在硬件复位时直接蒸发 追凶 DiagnosticReports 目录里躺着三条 ResetCounter： Date: 2026-05-17 20:36:39 Reset count: 1 Boot faults: wdog, reset_in_1 timeout, dblclick_timeout wdog = Apple Silicon 的硬件看门狗。 reset_in_1 timeout = 内核超过 1 秒没响应看门狗，硬件直接拉闸。这不是软件崩溃，是系统已经无响应到连 panic 流程都走不动了，纯靠硬件保底。 同目录下还有几条 disk writes 诊断------macOS 对单日写入超过 2.15 GB 的进程会自动采样微栈： 19:04-19:15 — ditto Command: ditto PID: 55081 Event: disk writes 写入: 2.15 GB / 11 分钟 Stack: BOMCopierCopyWithOptions → _BOMCopierCopyFromPKZip → _copyDir → _copyFromPKZip → _copyDir → …（35层递归） Resource Coalition: 12598（自身）, 137 samples 1439 ditto 在解压一个 zip，目录嵌套深到递归了 35 层才触到实际文件。问题是------谁调用了 ditto？ 20:36-20:39 — Cursor Command: Cursor PID: 979 Event: disk writes 写入: 2.15 GB / 150 秒（14.3 MB/s） Stack: 177 个线程全部卡在 uv__fs_post → write() 1 个线程在 Squirrel → removeItem → __removefile_tree_walker → __unlink Resource Coalition: 751, 34 samples 1439 177 个 libuv 线程池线程，全部在内核 write() 里。同时 Squirrel 在递归删除一个目录。注意 Cursor 和 ditto 都出现了 Coalition 1439 。 对 Coalition 1439 做反向索引------在全量磁盘写入报告里搜所有带有这个 Coalition 的进程------结果只有一组： com.todesktop.230313mzl4w4u92 （Cursor）及其子进程。 ditto 是 Cursor 启动的。 再查 Squirrel 的状态文件： ShipItState.plist: targetBundleURL: "/Applications/Cursor.app/" updateBundleURL: "…ShipIt/update.z1tErYz/Cursor.app/" ← 从未完成安装 ShipIt 日志： 5月16日 19:24 Detected this as an install request 5月16日 23:01 Detected this as an install request ← 又来了 然后 Cursor 主日志，第三次死机前两分钟： 5月17日 22:04:36 update#setState checking for updates 5月17日 22:04:37 UpdateService onUpdateAvailable() 5月17日 22:04:37 update#setState downloading 5月17日 22:07------ResetCounter。 从 5月16日晚到 5月17日晚，Squirrel 一直在尝试安装同一个更新，每次都触发 I/O 风暴->死机->重启->Cursor 自启->Squirrel 发现更新没装完->再来一次。 为什么能打穿整台机器 三个 I/O 密集型操作同时发生： 操作 并发 I/O 类型 ditto 递归解压 35+ 层目录树创建 APFS inode 分配 + 目录写入 Cursor libuv 线程池 177 线程同时 write() 数据块写入 Squirrel 递归删除 旧版本目录树删除 APFS inode 回收 + 目录更新 APFS 的元数据操作是串行化的。一边疯狂建目录，一边疯狂删目录，一边 177 个线程抢文件写入------元数据锁争抢到内核 I/O 工作队列被填满，关键的 watchdog 喂狗线程分不到 CPU。 我的日常负载（Chrome 十几个标签 + VS Code 多窗口 + OrbStack + postgres + mongod）当时内存压力已经把页面缓存挤出不少，这意味着文件写入还要跟 swap 抢 I/O 带宽。 结果就是内核整体无响应 >1 秒 → 硬件 watchdog 超时 → 黑屏重启。 Cursor 团队在这里省了什么 说三件事： 全量 zip 替换。 2026 年了，VS Code 都能做增量热更新，Cursor 的 Squirrel 框架还在下载全量包->解压->替换整个 app bundle。2.15 GB 的更新包，不是 delta patch，是整个 app 重新灌一遍。 零 I/O 限流。 ditto 解压没有 QoS（诊断报告显示 QoS 是 User Interactive，最高优先级）。libuv 线程池没有限制并发写入数。Squirrel 的 removeItem 是递归 __unlink ，没有 batch，没有 throttle。 没有崩溃恢复。 更新安装失败后 Squirrel 的状态文件原样保留，下次启动直接重试，没有任何指数退避、没有失败次数上限、没有对"这台机器已经因为这个更新死过两次"的感知。硬着头皮再来一次，然后理所当然地再死一次。 Cursor Pro 订阅费不便宜。用户付了钱，换来的更新体验是机器被搞到硬件强制复位------这不是 bug，这是连最基本的系统资源管理都没做。 解决 如果你在用 Cursor，检查一下你是不是也在崩溃循环里： # 看有没有卡住的更新状态 ls ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt/ # 有的话直接清掉 rm -rf ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt/update.* rm -f ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt/ShipItState.plist # 禁用自动更新 defaults write com.todesktop.230313mzl4w4u92 SUEnableAutomaticChecks -bool false 更新手动去官网下，至少你能盯着 Activity Monitor 的 Disk IO 曲线，见势不对直接 kill。 硬件：MacBook Pro M3 Max / 36 GB / macOS 26.3 Cursor：2.6.20 更新框架：Squirrel（Electron 标配的 ShipIt） 死机类型：Apple Silicon Watchdog Reset（不是 kernel panic，比那个更严重------内核跑不到 panic 流程就硬死了） 1 个帖子 - 1 位参与者 阅读完整话题
IT之家 5 月 14 日消息，据外媒 BleepingComputer 今晚报道，戴尔证实预装在多数新款 Windows 戴尔电脑上的 SupportAssist 软件， 会导致部分 Windows 系统黑屏崩溃（BSOD） 。自上周五以来，不少用户报告称，戴尔设备出现随机重启问题。 IT之家注：SupportAssist 是戴尔开发的一套软件，通常预装在运行 Windows 10 或 Windows 11 的新款戴尔电脑上。 戴尔一名代表周三在官方论坛上告诉客户，最新的 SupportAssist Remediation 服务更新会触发 0xEF_DellSupportAss_BUGCHECK_CRITICAL_PROCESS 错误。 戴尔建议用户移除该服务，以解决蓝屏崩溃问题。“工程团队已经知晓 BSOD 问题，并正在努力解决。已经有许多用户提到，戴尔 SupportAssist Remediation 服务或 Alienware SupportAssist Remediation 服务的 5.5.16.0 版本 可能导致 BSOD。” 戴尔代表在另一个帖子中补充说：“作为临时解决办法，许多用户反馈， 禁用 戴尔 SupportAssist Remediation 服务，或者 直接彻底卸载 SA 应用后，问题得到解决。” 要卸载存在问题的戴尔 SupportAssist Remediation 版本，用户可以打开 Windows 设置，进入“应用 > 已安装的应用”，在列表中选择“Alienware SupportAssist Remediation”，然后点击“卸载”。 不过，用户需要注意，从受影响 PC 中卸载故障服务后，戴尔 SupportAssist OS Recovery 此前创建的 系统修复点可能无法继续使用 。 戴尔还建议，如果卸载该服务后 Windows 系统仍然崩溃，用户应联系支持部门获取进一步帮助。
运行 Windows 11 系统的戴尔设备近期频繁出现黑屏死机问题 (BSOD)，发生这种情况并非在安装微软发布的系统更新后，而是用户近期收到戴尔发布的软件更新，安装该更新后系统大约会每隔 30 分钟黑屏死机 1 次。 检查事件查看器则可以看到内核出现严重性错误的记录，这些记录大约 30~60 分钟出现 1 次，记录的描述则显示原因可能是内核出现预料之外的失去电源，这个问题目前正在影响大量使用 Windows 11 系统的戴尔用户。 网友 MartinHBS2026 则使用微软官方的错误检查工具 WinDbg 对系统日志转储内容进行分析，分析后发现源头指向戴尔自家的支持助手软件 (Support Assist)，所以比较简单的办法就是直接卸载戴尔支持助手。 在实际操作中网友发现哪怕是卸载这个戴尔支持助手都可能出现崩溃，不过网友最终还是决定卸载戴尔支持助手相关的所有组件，如果你使用其他高级清理工具，也可以尝试使用此类高级清理工具将戴尔支持助手彻底卸载，将其相关组件和注册表等清理干净。 从目前网友反馈来看，彻底卸载戴尔支持助手后可以解决问题，有网友称卸载干净后从微软商店重新安装戴尔支持助手也没再出现类似问题，所以目前具体问题原因还不清楚，可能还需要戴尔官方发布支持公告进行说明。 另外在这里也提醒各位网友，大多数 OEM 预装的品牌软件都容易出现类似问题，这些 OEM 软件可能是因为质量差或其他问题总会导致系统出现某些异常，如果在日常使用中遇到类似情况，不妨先卸载这些 OEM 软件再进行测试。 查看评论
IT之家 5 月 11 日消息，Windows 11 更新时常出故障并引发各类问题，其中最让用户恼火的两种情况，莫过于开机直接弹出 BitLocker 恢复界面，或是系统反复重启、频繁蓝屏死机。 人们很容易下意识把责任归咎于微软，毕竟微软过往的更新翻车记录由来已久（不过据悉这种情况很快将会好转），但这类系统故障，往往并不总是这家科技巨头的锅。 IT之家注意到，戴尔电脑近期就曝出了这样一个故障：受影响用户的电脑出现蓝屏死机后，会陷入无限自动重启的循环。已有多名用户遭遇该问题，科技社区 Neowin 的资深论坛用户 polo69 便是其中之一。他反馈，在戴尔推送新版软件更新后，自己的电脑大约每隔 30 分钟就会蓝屏一次。 下方图片为系统事件日志截图。可以看到日志中出现多项严重错误，引发内核电源中断，随后系统蓝屏崩溃。 论坛用户 MartinHBS2026 使用 Windows 调试工具 WinDbg 深入排查故障，最终查明问题根源来自戴尔自家的 SupportAssist（智能助手）软件。WinDbg 是 Windows 专用调试工具，可用于分析系统蓝屏崩溃转储文件。 该用户留言表示：“我用 WinDbg 分析了小型转储文件，确认是 SupportAssist 引发的故障！我先是卸载了这款软件，结果电脑依旧崩溃；随后我把所有和 SupportAssist 相关的组件全部卸载，包括系统修复插件和操作系统恢复插件。” 因此，如果你也遇到此故障，最简单的解决办法就是卸载电脑中的 SupportAssist 软件。 颇具讽刺意味的是，戴尔 SupportAssist 更新引发同类故障早已不是首次，早在 2024 年 12 月就曾发生过几乎一模一样的问题。所幸当时用户自行找到了可行解决方案：运行软件内的 SupportAssist 硬件扫描，扫描完成后，电脑就不再出现闪退或蓝屏问题，这个方法如今也值得大家一试。 目前戴尔官方尚未针对相关故障反馈作出回应，大概率是恰逢周末，售后技术团队暂未在岗处理。
某次关闭tabby后 后面再次打开卡住 可以移动tabby窗口 无法点击关闭，必须通过任务管理器关闭 借助claude大人的力量无法获胜 已尝试的方法 重装 删除appdata里面关于tabby的数据 关闭gpu加速 安全模式启动 管理员启动 更新windows 重启电脑 解决方法: 换用windterm了 使用tabby过程中遇到的一些我解决不了的槽点 tun模式下不设置绕过进程无法连接 端口转发设置后要重新启动tabby 2 个帖子 - 2 位参与者 阅读完整话题
Any蹬一半死机了，想起还有个老Lite换成5.1继续蹬，一个模块还没写完，50%没了,就这点额度逗小孩呢。 2 个帖子 - 2 位参与者 阅读完整话题
一直在用 TrafficMonitor，但是公司电脑经常死机，之后 TrafficMonitor 的设置就会清空，还得重新设置一遍。想看看有没有替代品。 1 个帖子 - 1 位参与者 阅读完整话题
IT之家 4 月 29 日消息，针对近期关于 Windows 11 四月累积更新 KB5083769 导致大规模黑屏死机（BSOD）和“死亡循环”（death loops）的报道， 微软经调查证实这些均为缺乏证据的“AI 生成劣质内容”。 近期网络上涌现大量关于 Windows 11 四月累积更新 KB5083769 导致严重系统故障的报道，声称该更新会引发黑屏死机和无限重启。 微软通过科技媒体 Windows Latest 发布声明，通过调查追溯发现，所谓的“大规模故障”仅源于微软问答论坛上的一条帖子， 且仅有 4 名用户反馈存在该问题。 IT之家附上原帖如下，原帖作者 Vagabond Superstar 声称安装 4 月更新后，电脑无法正常启动。他在 3 天后更新帖子，表示通过重置 CMOS 自动回滚，已经恢复正常。 Windows Latest 调查指出，本次事件是一家媒体夸大极少数论坛投诉为灾难性事件，随后被其他媒体和社交平台作为证据进行二次传播。 经检测，部分涉事文章被识别为 100% 由 AI 生成，存在严重的“幻觉”现象。 微软官方已明确表示，并未收到关于此更新的重大问题报告。此外该媒体指出，每月都会在数十台物理设备和数百台虚拟机测试微软累积更新，从观察的数据来看，Windows 11 的月度更新稳定性已显著提升。 根据微软官方支持文档，KB5083769 目前仅确认存在两个已知问题。其一是特定企业环境下可能触发 BitLocker 恢复界面，这仅影响使用了非推荐组策略配置的设备，普通消费者设备不受影响。其二是多显示器且缩放比例不同时， 远程桌面警告对话框可能无法正常显示 。
今天开会需要 安装了腾讯会议 打开用手机扫码 登不上去 直接卡死这个界面 只能强制重启 卸载了重装一遍还是到登录界面卡死了 有佬友遇到同样的问题吗 系统用的是win11 x lite 1 个帖子 - 1 位参与者 阅读完整话题
IT之家 4 月 22 日消息，甲骨文（Oracle）旗下虚拟化软件 VirtualBox 发布 7.2.8 版本维护更新， 重点修复 Windows 11 虚拟机黑屏死机（BSOD）及安全启动证书更新失败问题。 针对 Windows 11 平台用户，本次 7.2.8 更新修复因 DRIVER_OVERRAN_STACK_BUFFER 错误导致的虚拟机黑屏死机问题，并修复安全启动证书更新失败缺陷，确保虚拟机能够正确处理微软更新的 DBX 证书。 针对 Linux 平台，本次更新初步支持 Linux 6.19 和 7.0 内核，并兼容性适配 RHEL 10.1、10.2 及 Oracle Linux 9 的 UEK9 内核。 在交互方面，IT之家援引博文介绍，开发团队修复了 Wayland 环境下剪贴板无法共享、末尾字符丢失以及 Ubuntu 25.10 中鼠标光标形状不随场景变化等体验问题。 在 BUG 修复方面，本次更新修复了 NAT 网络内部 DNS 服务器无法访问的连接故障，并解决了 FreeBSD 16.0 关机时 LSI Logic SAS 控制器导致的崩溃问题。