第一部分照例是回忆或吐槽，正文从第二部分开始，可以跳阅。
1
前些日子看了个二战题材电影《诺曼底72小时》，一部被高考和历史门槛耽误票房的电影。简单地说，就是一部英伦的《借东风》。
显然为了加强戏剧冲突，历史上一直声称对第二战场没准备好的英国人，竟然在剧中说如果6月5日不进攻，大家就开始学德语吧，这当然是夸张，不马上进攻，最多是无法继续保密，还到不了学德语的地步(最多是学俄语，不然英国人也不会真急)，而且英吉利海峡这边在等东风，法国海岸那边未必不是在唱空城计。
即便如此，还是部好片，高考中考完的学生，如果还有时间，对历史感兴趣的，可以去补看此片，如果还有排片的话，流媒体也好。
2
今天我要用三个AI产品检测一个蓝屏。
有一台老旧电脑，重装了Windows老系统，重装完，用U盘安装补丁包，就是一些常用的补丁合集，不打上，连驱动都安装不了。
安装完重启过程中突然出现一次蓝屏，然后就自己重启了，显示有补丁安装失败、进行还原，最终进了桌面，从表面上看也没有什么问题，就是随后有一些补丁，不论是离线包还是线上下载的，都是安装失败，甚至有的应用软件也是安装失败。最后我又重装了一遍才解决掉，不过在再次重装前，我把前面蓝屏生成的dmp文件拷出来了，一共有两个，一个Minidump，还有一个是MEMORY.DMP，一小一大，一个是小内存存储，一个按设置是完整或核心内存存储。
先上chat类的AI，用WinDbg打开dmp文件，提取出内容扔AI里，让它分析（参考做法：使用AI分析Windows蓝屏dump，现在这么简单了吗）。AI指出蓝屏类型是：
ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (0xFC)
这个我还真没注意，当时蓝屏一闪而过就自动重启，我没记得下蓝屏代码与提示。然后指出出事模块：WudfPf.sys，解释说和USB设备或外设有关。
不过这次，仅凭 !analyze -v，还无法精确到具体硬件设备名，WinDbg里执行没反应，有反应的是：
!devnode 0 1
把这命令执行后的结果喂给AI，AI查出是我用的雷克沙U盘，并明确说不是U盘坏了，是它的驱动和在Windows的UMDF(WUDFRd)在初始化时触发内存破坏。不理解不要紧，虽然AI也对此做了很多解释，但我不都需要知道了，只要知道是U盘问题就行，我确实在那次蓝屏的重启前拔除了U盘，也许U盘上面的安装包在重启后还有工作要继续。
3
在大致了解本次蓝屏问题的情况下，我再选用其它的AI产品来试试。
上次我在无线网卡频繁断连，来源Netwtw10的错误里说可以用WorkBuddy，这次也用它。不过因为我说过的原因，仍然不方便在原机上试，就把拷出来的两个蓝屏dump文件，放到安装有WorkBuddy的电脑桌面上，让它自己读取分析，这次我不用WinDbg协助分析提取了，让WorkBuddy自己来。
总感觉是，真慢。
首先，WorkBuddy识别出这两个文件中同一次蓝屏事件，蓝屏代码：
0x000000FC，ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
也找到了WUDFRd.sys（USB驱动），和前面chat AI说的一样。
继续。
触发场景：插入 USB 存储设备（U盘/移动硬盘）时崩溃。这个判断有误，蓝屏是在启动时发生的，我并没有插入U盘，不过反正是涉及U盘的事，可以理解。
然后还读取了蓝屏电脑的硬件配置，应该是dmp文件中的，但电脑型号说错了，联想扬天4900c说成联想扬天M2200r，这不要紧，又不影响什么。
第一轮分析到这就结束了，给了几个普通的修复建议，不是我想要的。既然前面chat AI都剧透了，就直接来吧。我直接问WorkBuddy能不能查出是什么U盘导致蓝屏崩溃，什么品牌型号。我就想看看WorkBuddy能做到什么程度。
然后，WorkBuddy又开始工作，使用python执行脚本分析，也找到了雷克沙U盘，同时也指出我也使用了另一个U盘：闪迪，但闪迪没有触发WUDFRd的UMDF代码路径，所以大概率不是“元凶”。
我要的就是验证，看看这些AI产品，特别是后面这些有执行能力的AI，看看它们能做到什么程度，能不能再一次降低我们处理电脑故障的难度。从WorkBuddy来看，应该是可以的，就是要追问。
4
最后是最近出的马维斯（Marvis）。也是腾讯家的，不是给他家做广告，主要是能和微信连结。
据说马维斯更深入系统底层权限，就是说要的更多，能力更大，风险更大，用的时候注意安全，参考怎样安全地养龙虾（OpenClaw）。
它有两个模式，效率模式和本地模式，本地模式就是说AI模型下载到本地执行，不联网不上传，但对机器配置要求太高，显存16G以上，我12G显存的显卡都不能接受，所以配置不够的话，这个模式就是废了，不能用。
效率模式也吃配置，配置不够连安装都不让（当然就更不指望能安装在老电脑上），所以它的工作速度也是够慢的，。
同样让它分析放到桌面上的两个dmp文件，因为我改过桌面的位置，它竟然一开始找不到我的桌面在哪（刚出来不久，可以理解），给了明确路径后开始工作。
首先找出蓝屏代码和崩溃模块与前面相同，毕竟和WorkBuddy出自同一家，所以给的不痛不痒的修复建议也差不多，不理会。继续追问：能不能从dmp文件中找到出问题的U盘信息，比如型号品牌。
小马找到闪迪和雷克沙，但是说闪迪出问题的可能性大，这是根据闪迪的历史问题报告更多得出的，可见它有通过联网搜索相关的问题，但我不要它的搜索报告，我要从dmp中分析，看看它的分析能力，如果本地文件分析能力不如WorkBuddy，腾讯何必多分出一个产品来。
再追问，能不能分析出系统崩溃时是哪个U盘引起。这回给了我一堆英文，我发现了什么秘密！
中断英文的回复，让它用中文说，到底是闪迪还是雷克沙。这回明确了，说是雷克沙。
5
对于执行类的AI，我基本只抄了结论，其实具体过程有兴趣的可以看看，知道这类AI是怎么分析的，就是太慢了，但至少证明它们还是有主动读取和分析文件的能力，比聊天类的AI自动化多了，可以一玩。
>> 除非说明均为原创，如转载请注明来源于http://www.stormcn.cn/post/2396.html
