简介EurekaLog是面向Delphi与CBuilder开发者的异常捕获与程序漏洞分析工具这份企业版源码包V7.7.8.64可让应用程序在最终用户电脑上捕获异常与内存泄露并生成本地调用堆栈日志指明出错的file、class、method和line便于开发者快速定位崩溃源头。资源共1494个文件以pas/hpp/dcu源码及编译单元为主配合dproj/dpk工程文件、res/dfm资源、exe/dll/bpl构建产物与chm说明文档整体约124.36MB。目录按库组件和示例工程组织适合在IDE中直接编译对接。目前已有495人学习下载。企业版附带完整源代码可深入剖析EurekaLog的注入与日志机制覆盖10.2、10.3.2等主流Delphi版本编译后仅增约300KB兼顾轻量与实用对追求程序稳定性、需要系统化异常排查方案的中高级Windows开发者很有价值。1. EurekaLog 源码版是什么为什么 Delphi 程序需要它用 Delphi 写业务系统的团队对 EurekaLog 这个名字不会陌生它是被很多人称为“最好用”的程序漏洞分析检测工具尤其适合那些已经上线、天天被用户报“偶发崩溃但本地复现不了”的存量系统。EurekaLog Enterprise 7.7.8.64 源码版的价值在于它不只是给你一个装好的插件而是把异常捕获、内存泄漏检测、性能剖析这套能力的完整源码都交到你手上。适合三类人维护老旧 Delphi 项目的工程师、对崩溃报告精度有执念的客户端开发以及想研究异常钩子机制的源码党。2. 异常捕获与堆栈追踪原理钩子注入到报告生成的链路2.1 异常链接管从 VCL 异常到 EurekaLog 报告Delphi 程序默认有一套异常处理链TApplication.Run 的消息循环里未处理的异常会走到 TApplication.HandleException弹一个默认对话框然后程序继续跑。问题在于这个对话框只告诉你异常类和消息没有堆栈、没有寄存器、没有模块版本线上用户截个图发过来开发这边只能靠猜。EurekaLog 的思路是在这条链上做钩子。源码版能直接看到它接管异常的入口核心逻辑类似下面这段源码版里可以翻到对应实现// 源码版内部异常拦截的示意片段 procedure TExceptionHook.HandleException(AContext: TEurekaLogContext); var LStack: TStackList; begin if EurekaLogOptions.Enabled then begin // 实时抓取当前线程的寄存器上下文 LStack : TStackList.Create(AContext.Registers); try LStack.Build(EurekaLogOptions.StackTraceDepth, EurekaLogOptions.SymbolFile); // 生成报告异常对象 堆栈 模块列表 系统信息 SaveToLog(LStack, AContext.ExceptionObject); finally LStack.Free; end; end; end;逻辑说明HandleException 是 EurekaLog 自家的异常处理入口它做的事情顺序很关键——先保存寄存器上下文再回溯栈帧最后把异常对象连同堆栈写入日志。如果栈回溯放在异常对象处理之后部分寄存器已被污染堆栈精度会下降。参数方面StackTraceDepth 控制回溯深度太大报告体积暴涨但信息冗余太小则关键帧丢失SymbolFile 指向 .map 或 .tds 文件没有它堆栈就只剩十六进制地址。这套钩子对线程异常同样生效Delphi 的 TThread.SyncException 会被 EurekaLog 一并接管。实际经验是那些“看起来像内存被写坏”的偶发崩溃崩溃点往往不在主线程消息循环里而是后台线程的访问违例。默认配置下EurekaLog 也会把后台线程异常一起记录下来省去你自己包一层 try..except 的力气。2.2 堆栈还原的关键参数符号文件与栈帧深度异常被捕获只是第一步真正决定报告有没有用的是堆栈能不能还原成函数名。EurekaLog 在生成报告时会把异常时刻的指令地址和已加载模块的基址做差值再查符号文件里的地址区间映射到函数和源码行。这里有两个常见配置项容易让人忽视配置项常见取值作用StackTraceDepth25 层左右栈回溯深度x64 工程建议加深SymbolFile / MapFile编译时生成的详细 .map提供函数名与行号IncludeSystemModulesFalse是否展开系统 DLL 的栈帧StackWalkMethodFramePointer / SEH栈回溯方式优化模式下要切换我在做某设备上位机时踩过一次默认的栈回溯方式是基于 EBP 帧指针但编译器开了优化后很多函数不维护 EBP回溯到第 5 层就断了。EurekaLog 的 StackWalkMethod 里有基于 SEH 链的回溯方式对优化代码更友好代价是回溯速度略慢。你在源码版里能找到这段调度逻辑看它如何根据模块特征选择回溯策略这是普通安装版看不到的东西。另一个被忽略的点是模块列表。报告里会列出所有已加载 DLL 的版本号和基址这在排查“用户机器上某个第三方 DLL 版本不对”时非常有用。你不需要让用户去查文件属性报告里已经写清楚。3. 内存泄漏检测与性能剖析FullDebugMode 的配置边界3.1 开启泄漏检测哪些配置项决定报告质量EurekaLog 的泄漏检测底层是替换 Delphi 默认内存管理器进入 FullDebugMode。这个模式下每次分配和释放都会记录调用来源程序退出时扫描未释放块生成泄漏报告。源码版的价值在于你能看到它如何接管 GetMem/FreeMem 的分配入口并且能按需裁剪检测范围。实际开启时重点不是“打开开关”而是正确设置以下参数配置项推荐值说明EnableLeakDetectionTrue总开关Release 版建议关闭LeakReportMinSize0小于该大小的泄漏块不报告过滤噪声IgnoreLeakModules第三方控件 DLL已知泄漏但无法修改的模块SnapshotOnExceptionFalse异常时是否做一次内存快照经验是第一次开启泄漏检测时先别急着清理跑一遍完整主流程拿到的报告可能几百条。先按尺寸排序把那些“单次分配、尺寸固定、来自系统 DLL”的记录忽略掉再聚焦业务代码。这套操作我一般按四步走全量开启跑冒烟测试 → 导出报告 → 把第三方 DLL 加入 IgnoreLeakModules → 对剩余记录人工复核。判断一条泄漏是不是误报关键是看它的调用栈来源如果栈里只有系统分配函数而没有业务函数那它大概率是运行时库常驻内存而不是真正的泄漏。注意一个边界EurekaLog 的 FullDebugMode 会让程序内存占用明显增加分配速度下降。有个做报表工具的同事被“泄漏报告全是异常时的残留内存”误导过实际上那是因为他们在异常处理流程里创建了大对象异常发生后没有走释放分支。这种不算泄漏是流程设计问题但报告里会被当成泄漏记录报出来。3.2 性能剖析与调用统计把报告当性能入口EurekaLog 还有一个被低估的功能性能剖析。它能统计每个函数在检测周期内的调用次数、平均耗时、最大耗时并生成调用次数热区。源码版里可以看到它的插桩方式常见做法是在函数入口和出口分别记录时间戳和调用计数归并到符号名下。我在调一个启动慢的问题时用过一次这个功能界面初始化 3 秒看起来是数据库连接慢但剖析报告显示时间主要花在某个 JSON 解析函数的重复调用上——它在一个循环里被调了 2 万多次。把解析挪到循环外启动时间降到 0.6 秒。这类问题用传统打点方式很难定位因为均值被稀释了EurekaLog 的调用计数能直接暴露热区。性能剖析的开启方式和泄漏检测类似都在 EurekaLog Options 的 Profiler 页里。一般建议只针对特定模块开启全模块开启会产生大量日志文件而且写日志本身会影响耗时统计。我一般用“先全量跑一次定位热点模块再对热点模块单独深挖”的方式。4. 源码版编译与工程集成从源码包到出报告的完整路径4.1 编译顺序与 IDE 集成先 Runtime 后 Design Time拿到 EurekaLog Enterprise 7.7.8.64 源码版第一步不是立刻打开 Delphi 编译工程而是理解源码包的目录结构。源码包里通常包含 Runtime 包、Design Time 包和示例工程三部分。编译顺序必须是先 Runtime 后 Design Time因为设计期包依赖运行期包提供功能函数反了会报“找不到单元 XXX”。常见做法是用命令行编译比在 IDE 里手工操作更可控# 编译 32 位 Runtime 包先跑核心库 msbuild Source\EurekaLogCore.dproj /t:Build /p:ConfigRelease /p:PlatformWin32 # 编译设计期包注意平台必须与 IDE 一致多数 IDE 是 32 位 msbuild Source\EurekaLogDesignTime.dproj /t:Build /p:ConfigRelease /p:PlatformWin32逻辑说明EurekaLogCore.dproj 是核心运行库不依赖 IDE 环境EurekaLogDesignTime.dproj 负责向 IDE 注入菜单和配置界面它必须在核心库之后编译。参数方面PlatformWin32 很关键——如果你的 IDE 是 32 位的设计期包编成 Win64 会直接加载失败IDE 菜单里看不到 EurekaLog。源码版与安装版不同的地方在于你可以自行修改源码后重新编译比如改掉默认报告文件名格式或者增加自定义字段。我改过一次报告文件的命名规则把崩溃时间放进文件名方便用户直接按时间找文件。4.2 工程接入配置文件与异常对话框定制编译完成后接入你自己的工程有两种方式一种是 IDE 菜单自动注入它会在 .dpr 的 uses 列表最前面插入 EurekaLog 单元并生成一个 .eul 配置文件另一种是手动引用单元加手工配置。手动方式更可控适合团队统一配置program Project1; uses EurekaLog, // 必须放在 uses 第一位 EurekaLogOptions, // 配置项访问 Vcl.Forms, Unit_Main in Unit_Main.pas;这段代码的重点是 EurekaLog 必须出现在 uses 第一位。Delphi 单元初始化顺序按 uses 顺序执行EurekaLog 需要最早安装自己的异常钩子否则后续单元的初始化异常它接不到。配置项集中在 .eul 文件里格式类似下面这样EurekaLogOptions LogFile EnableTrue Path%APPDATA%\MyApp\Logs\ / Email EnableFalse / ExceptionDialog StyleEurekaLog / StackTrace Depth25 ShowSystemModulesFalse / MemoryLeak EnableTrue IgnoreSize64 / /EurekaLogOptions参数说明LogFile 的 Path 建议写到 %APPDATA% 下某个子目录不要写程序目录避免用户装了 UAC 保护后没有写权限导致日志落不下来ExceptionDialog 的 Style 可以选 EurekaLog 自带的对话框样式也可以选系统默认前者能多展示一个“发送报告”按钮方便用户手动反馈。工程接入后的验证路径是在某个按钮事件里写一行 div by zero 触发生成异常运行后到日志目录看是否产生 .elf 报告再用 EurekaLog 自带的报告浏览器打开确认堆栈里有你的函数名而不是一串地址。如果堆栈显示地址说明符号文件没配置对回到编译选项里把 Detailed map file 勾上。5. 集成避坑与常见问题排查五个高频翻车点5.1 报告堆栈只有地址没有函数名现象程序确实生成了 .elf 报告但打开后堆栈区全是十六进制数字一个函数名都看不到。原因基本是符号文件缺失或路径没对上——EurekaLog 要还原堆栈必须在报告生成时能访问到 .map 文件或者报告里记录了符号文件路径让浏览器二次解析。解决在 Delphi 编译选项里勾选 Detailed map file并把 .map 文件路径加入 EurekaLog Options 的 Symbols 页。我习惯把 .map 放在跟 exe 同目录这样即使报告在用户机器生成也能带着符号路径。5.2 设计期包加载失败IDE 菜单找不到 EurekaLog现象装完源码包后打开 DelphiEurekaLog 菜单完全没有出现。原因九成是设计期包平台和 IDE 不一致或者编译后的 .bpl 文件没放入 IDE 搜索路径。我见过某开发者把 DesignTime 包编成 Win64结果 32 位的 IDE 根本不加载它。解决确认 IDE 位数后重新编译对应平台的设计期包检查 IDE 的 Library Path 是否包含输出目录。另外源码版安装到中文用户名路径下时IDE 偶尔会解析不了带空格的路径把源码包释放到纯英文路径再编一次就能解决。5.3 内存泄漏报告大量误报现象开启 FullDebugMode 后跑一次完整流程出来几百条泄漏记录其中大量来自第三方界面库。原因第三方 DLL 用自己的内存管理器分配内存EurekaLog 的 FastMM 接管不了这些块在进程退出时自然不会被释放被当成泄漏记录。解决在 IgnoreLeakModules 里把第三方模块名加进去。注意区分“真泄漏”和“常驻块”常驻块的调用栈里没有业务函数而是停在某个初始化函数真泄漏的栈里通常能追溯到某个业务函数里没有配对释放的 GetMem。5.4 发布版本弹出“找不到 EurekaLog 运行库”现象开发机上跑得好好的拷到用户机器上运行启动即报缺 DLL。原因工程设置里勾选了 Build with runtime packages设计期混入了 EurekaLog 的运行时包依赖而 EurekaLog 的 bpl 没有随发布包拷贝。解决确认最终发布时关闭 runtime packages选择静态链接方式编译EurekaLog 会把自己的逻辑编进 exe不依赖外部 bpl。这个方法有一个代价exe 体积会增加几 MB但换来的是不用维护一堆 bpl值得。5.5 x64 工程堆栈只能回溯前几帧现象同一个工程x86 版报告完整编译成 64 位后堆栈只有前 5 帧。原因x64 的调用约定不是基于 EBP 的栈回溯方式要改成针对 x64 的规则。解决在 EurekaLog Options 里把 StackWalkMethod 调整为 SEH 或 x64 专用模式同时确认符号文件是 64 位编译产生的——用 32 位的 .map 去还原 64 位堆栈行号会错乱。这个坑在源码版里尤其容易踩因为源码版可以自定义构建选项改动了编译器优化级别后符号信息不配套。6. 发布前的最后一步符号路径与报告去噪技巧项目要发版了EurekaLog 也接入完成但直接打包往往会在收到第一批用户报告时翻车。我的习惯是把以下检查清单强制走完再放行发布。第一验证符号可达性。模拟用户环境把 exe、.map、.tds 放到一个无开发工具的全新目录运行后故意触发一次异常看报告能否还原出函数名。这一步能挡掉大部分“开发机能解析、用户机不能解析”的问题。如果结果不理想把符号路径改成绝对路径或者关闭“报告内嵌符号”选项改为引用外部文件。第二报告去噪。在 EurekaLog Options 里把已知的无害异常加入忽略列表例如用户关闭窗口瞬间的控件访问冲突、第三方输入法引起的布局异常。这样做不是掩盖问题而是让真正有价值的高频崩溃浮到报告列表顶部。忽略列表的正确姿势是先收集 100 份报告统计异常类分布再决定忽略哪些不要提前猜。第三自定义上报入口。EurekaLog 的报告可以配置成 HTTP 提交把 .elf 文件 POST 到内部服务器。常用做法是让报告先落到本地再通过一个自定义事件把它转发出去# 解析 .elf 报告过滤已知异常后转发到内部接口 import re report_path report.elf with open(report_path, r, encodingutf-8, errorsreplace) as f: content f.read() known_exceptions [EAbort, EControlC] if any(ex in content for ex in known_exceptions): print(ignored: known exception) else: # 这里写实际的上报逻辑例如压缩后 POST print(forward report: %s % report_path)这段脚本的意义在于线上报告量大时EurekaLog 浏览器一个个点开看效率太低用脚本先做一次粗过滤把已知异常剔除剩下的才是真正需要人工分析的崩溃。参数方面known_exceptions 列表按你自己的业务异常维护过滤逻辑可以再加一层“同一时间窗口内出现多次”的判断。第四发布包自检。确认发布目录里没有设计期文件EurekaLog 生成的配置文件路径写的是相对路径而不是开发机绝对路径日志目录在用户机器上有写权限。我是从一次线上事故之后养成这个习惯的某项目发布了一个版本用户反馈程序闪退但所有报告打开后堆栈全是一堆地址因为打包时把 .map 漏了。那次排查花了整整两天最后靠远程给用户补发符号文件才解开。从那以后每次发布前我都强制走一遍“全新目录触发异常 → 检查堆栈可读性”的流程顺手把发版检查清单存成模板跟源码放一起。这套方法不是银弹但至少能让线上崩溃变成可读的堆栈而不是一堆十六进制地址。希望帮到你。本文还有配套的精品资源点击获取
