新版AiCube工具 (V1.01M)配置Ai8051项目出错
新版AiCube工具 (V1.01M)配置Ai8051项目出错，在点击图形化I/O口配置选项时会停止工作，试了STC8H8K64U和STC32G128K可以配置，
C:\Users\Administrator\Desktop\图片1.PNG 图片 一样这边是直接闪退啊，就8051U会 win10系统也是直接闪退 我的WIN10闪退都看不到，点了AiCube直接没反应 多谢反馈！
周一上班立即查问题 zhp 发表于 2026-4-12 10:05
多谢反馈！
周一上班立即查问题
我把崩溃记录dump出来了。AI分析出了原因：
这次真正的崩溃根因不是 0xC000041D，而是 0xC0000005。
0xC000041D 更像外层表现，表示“用户回调期间有未处理异常冒泡出来”；而 0xC0000005 才是底层异常，属于访问冲突。微软文档里对这两类含义的说明与这里的现象是一致的。
关键点是：
崩溃线程：TID 23436
真实异常：0xC0000005
异常地址：AiCube.exe + 0x1CB89F
基址是 0x00C60000，故障地址是 0x00E2B89F
访问类型：读空指针
异常参数：{0, 0}，这对应 read from NULL
寄存器现场里：ECX = 0
崩溃指令解出来是：
mov eax,
call dword ptr
也就是说，程序先想从 ECX 指向的对象里取 vtable/首字段，但当时 ECX 就是 0，所以第一条 mov eax, 当场触发访问冲突。
这说明它不是那种“很像系统底层炸了”的崩法，而是非常典型的 AiCube 自己代码里的空对象/空接口指针解引用。更具体一点看，这很像 C++ 成员函数 / 虚函数调用时 this 指针为空 的场景。
调用栈也支持这个判断。栈回溯前半段几乎都在 AiCube.exe 内部，然后才回到 user32.dll、ntdll.dll。这和事件查看器里看到的 0xC000041D 能对上：异常是在 UI / 用户回调链路里冒出来的，但真正出错点仍然在 AiCube 自己内部。
我从栈里提取到的一段关键返回地址是：
AiCube.exe+0x1CEFFD
AiCube.exe+0x1CC88C
AiCube.exe+0x1E29FC
AiCube.exe+0x1DDCED
AiCube.exe+0x1F3045
AiCube.exe+0x1F2E91
AiCube.exe+0x1E8E52
AiCube.exe+0x1EE028
AiCube.exe+0x1E68B0
AiCube.exe+0x1EEC1F
AiCube.exe+0x1F0379
AiCube.exe+0x1EBAAA
AiCube.exe+0x1EC25F
user32.dll+0x393B3
user32.dll+0x2817D
user32.dll+0x27C20
user32.dll+0x32EE9
ntdll.dll+0x7B786
还有两个对排查很有价值的信息：
第一，AiCube 是个 32 位进程。
dump 里出现了 WOW64 相关模块，而且线程上下文是标准 x86 CONTEXT 大小 716 字节，不是原生 x64 线程现场。所以这是 32 位 AiCube 跑在 64 位 Windows 上。
第二，dump 里带出了它的 PDB 路径。
嵌入的 CodeView 记录是：
D:\work\isp\ap\utility\stccube\Release\stccube.pdb
这个信息很关键。它说明开发方内部工程名大概率叫 stccube，不是随便猜的，而是程序自己在 dump 里带出来的调试信息。你把这个路径、偏移和 dump 一起给开发方，对方基本就能秒定位到函数。
zhp 发表于 2026-4-12 10:05
多谢反馈！
周一上班立即查问题
唉，你们软件测试工程师得背锅了{:touxiao:} 御坂晓岚 发表于 2026-4-12 21:41
我把崩溃记录dump出来了。AI分析出了原因：
这次真正的崩溃根因不是 0xC000041D，而是 0xC0000005。
多谢高手帮忙分析，问题已定位到
由于问题比较严重，今天会立即更新软件
{:4_196:}
页:
[1]
2