Delphi游戏计时器运行1-2小时后冻结，触发‘Canvas does not allow’异常

程序情况 #

• 用Delphi 10.4社区版开发的单线程程序，运行于Windows 11系统
• 主窗体包含多类控件，另有一个带位图的fOverlay窗体，位图上方通过多个TLabel显示分数、时钟时间、罚时、队伍及回合信息
• 主窗体设置了一个间隔500ms的TTimer，触发时计算倒计时主时钟与罚时，直接更新fOverlay窗体的标签内容

计时器核心代码 #

// decrement main clock
if ClockEndTime > Now then
  begin
    MainClockTime := ClockEndTime - Now;
...
  else
    // clock time is expired
    begin
      MainClockTime := ZeroTime;
      tmrMainClock.Enabled := False;
      ClockRunning := False;
...
    end;
    // update the timer values and overlay
    lblClock.Caption := FormatDateTime('n:ss',MainClockTime);
    fOverlay.lblClock.Caption := lblClock.Caption;
...

故障现象 #

• 程序运行1-2小时后，主窗体停止响应，触发**"Canvas does not allow"**异常
• fOverlay窗体上的时钟标签变为空白，主窗体所有控件无响应，但某功能热键仍能正常工作，疑似TTimer仍在触发但绘图功能彻底崩溃
• 给更新标签的代码添加异常处理后，虽未弹出错误框，但执行关闭并重启fOverlay窗体的逻辑后，窗体仅显示背景，无法绘制任何控件内容

疑问与特殊现象 #

• 怀疑问题源于主窗体直接跨窗体更新fOverlay的标签控件
• 故障重现需等待1-2小时，测试难度极大
• 特殊现象：测试时该程序更新标签，导致一个完全无关的Delphi 7程序中的GIF图片位置偏移，二者仅共同使用TTimer控件

排查方向与解决思路 #

1. 避免直接跨窗体操作控件
   Delphi的TTimer事件虽运行在主线程，但直接修改其他窗体的控件属性风险极高——长期运行中，若目标窗体控件处于重绘、句柄失效或不可用状态（比如系统资源不足导致Canvas异常），就会触发故障。
   优化方案：

   • 在fOverlay中暴露专门的更新方法，主窗体调用前先检查窗体及控件有效性（比如Assigned(fOverlay)、fOverlay.HandleAllocated）
   • 改用自定义消息机制，主窗体发送时间更新消息，由fOverlay自身处理控件更新逻辑，避免直接跨窗体操作

2. 排查GDI资源泄漏
   "Canvas does not allow"异常本质是控件Canvas句柄失效，大概率是长期频繁更新标签（500ms一次）导致GDI资源耗尽。
   操作建议：

   • 打开Windows任务管理器，监控程序的GDI句柄数，看是否持续增长
   • 减少不必要的重绘：仅当时间值真正变化时才更新标签Caption，而非每次计时器触发都执行更新
   • 更新前添加有效性判断：

     if Assigned(fOverlay) and fOverlay.Showing and Assigned(fOverlay.lblClock) then
       fOverlay.lblClock.Caption := lblClock.Caption;
     

3. 减轻TTimer事件的负载
   TTimer依赖主线程消息循环，若某次事件执行耗时过长，会导致消息队列积压最终引发无响应。长期运行中资源不足可能让单次更新操作变慢，加剧问题。
   优化点：

   • 若精度允许，将计时器间隔调整为1000ms，降低GUI更新频率
   • 计时器事件中仅做时间计算，尽量减少GUI操作，把更新逻辑剥离到独立方法中

4. 特殊现象的关联分析
   无关程序的GIF图片移位，说明你的程序存在GDI资源操作不规范（泄漏或句柄误用），影响了系统全局GDI资源的使用，这进一步验证了资源泄漏是核心问题之一。

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