第二次“新下载”或“在线更改”后General Protection Error问题排查

我在TwinCAT 3.1中实现组合模式，激活配置及首次新下载/在线更改时一切正常，但第二次新下载无论增减对象数量，都会触发General Protection Error或BSOD。

• Object是实现I_SYS_COMP_Object接口的FB
• 项目通过FB_init和FB_exit在全局对象列表中增删对象，此前使用call_after_init属性时也出现相同问题

11月26日更新：

• 核心转储和异常模式均无法定位问题
• 已锁定部分问题代码段：

IF object <> 0 THEN 
    RETURN; 
END_IF 
_this_object = THIS^; 
IF object.parent <> THIS^ THEN 
    RETURN;
END_IF 

• 蓝屏发生在后续的赋值操作行：

_last_child := object; 

即使在赋值后直接添加RETURN;，仍会触发蓝屏，且_last_child仅在当前方法中使用。

排查建议 #

1. 验证指针/引用的有效性
   • 二次下载时TwinCAT可能重新分配FB实例内存，旧指针可能指向已释放/覆盖的区域。不要仅靠object <> 0判断，改用__ISVALIDREF()函数验证object和object.parent的合法性。
2. 全局对象列表的生命周期管理
   • 检查二次下载时FB_exit与FB_init的执行顺序，确保全局列表在实例销毁时彻底移除旧引用，避免残留无效指针。同时要保证列表操作的原子性，防止多任务访问冲突。
3. 内存访问权限排查
   • BSOD多涉及内核态非法内存访问，检查是否违规操作了非用户态内存区域。确认I_SYS_COMP_Object接口的调用完全符合Beckhoff规范，避免越界访问。
   • 尝试修改_last_child的类型（比如从指针改为引用），或检查其声明的内存区域在二次下载后是否被标记为只读/已释放。
4. TwinCAT版本与配置检查
   • 升级TwinCAT 3.1到最新兼容版本，部分旧版本存在在线更改时的内存泄漏或指针失效BUG。同时关闭激进内存回收等优化选项，观察问题是否复现。
5. 简化测试用例
   • 剥离项目其他逻辑，仅保留组合模式核心代码（对象增删、父子关联），逐步添加功能定位干扰模块。也可以用静态数组替代动态全局列表，规避动态内存分配的失效风险。

内容的提问来源于stack exchange，提问作者Krystian