Azure虚拟机中Delphi编写的COM DLL调试断点无法触发问题求助

COM+配置排查项 #

• 确保COM+应用运行身份与调试器启动身份完全一致：若COM+配置为指定用户身份运行，调试器必须以同账号的管理员权限启动，权限不足会导致符号加载被系统拦截，即使进程附加成功也无法命中断点
• 临时关闭COM+应用的进程回收规则：默认配置的闲置回收策略会在调试过程中静默重启COM+宿主进程，调试器附加的是已失效的旧进程，自然无法触发断点
• 确认32位应用开关已开启：64位Windows Server环境下COM+默认优先使用64位宿主，32位DLL加载到WOW64环境时，若调试器未明确选择32位调试模式，会出现进程附加成功但符号不匹配的问题

Azure虚拟机专属配置调整 #

• 关闭Azure默认的内存优化配置：部分Azure Windows虚拟机默认开启的内存页压缩、内存裁剪机制会修改Delphi 2010生成的32位PE文件的内存基址加载逻辑，导致调试符号的地址偏移和实际运行地址不匹配，可执行命令bcdedit /set removememory 0关闭系统级内存裁剪配置
• 为目标进程添加DEP例外：Azure默认开启的全局DEP（数据执行保护）会拦截Delphi 2010生成的旧版本32位程序的动态代码执行逻辑，单独为COM+宿主进程添加DEP例外即可，无需全局关闭DEP
• 禁用进程注入类监控插件：Azure Monitor、安全中心的部分性能监控、安全扫描插件会注入自定义模块到运行中的进程，篡改进程地址空间，导致调试器符号匹配失败，调试期间可临时关闭这类功能

Delphi调试符号校验 #

• 确保部署的DLL和调试符号完全同源：同一代码不同时间编译生成的文件也会存在符号偏移差异，建议直接将本地编译生成的DLL、.dcu、.pdb文件全部同步到Azure虚拟机的对应目录
• 调试器附加进程时手动选择原生32位调试模式：不要使用自动检测模式，WOW64环境下自动检测经常会误判为64位进程，导致符号加载失败

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