Windows10系统下遗留VB6应用Load事件触发前延迟问题求助

• GDI/USER对象泄露排查：打开任务管理器「详细信息」页，添加「GDI对象」「USER对象」统计列，分别在Win7、Win10环境下启动测试窗体，对比两类对象的数值增长速率。如果Win10下GDI对象数异常偏高，基本可以判定是自定义控件内部重绘逻辑未正确释放旧GDI资源（画笔、字体、位图句柄等），Win10对GDI资源的调度、回收逻辑与Win7差异极大，对资源泄露的容忍度远低于Win7，这是最常见的旧控件卡顿诱因。
• 高DPI缩放验证：右键程序exe，选择「属性」-「兼容性」，勾选「替代高DPI缩放行为」，缩放执行选项选择「应用程序」，重新测试启动耗时。VB6默认无高DPI感知能力，Win10的系统级DPI缩放会在每个控件实例化时自动做坐标、尺寸重计算，大量控件叠加时会产生线性增长的额外耗时。
• 重绘拦截测试：给无业务逻辑的测试容器加代码，在窗体初始化前先向窗体句柄发送WM_SETREDRAW消息，参数设为FALSE暂停全局重绘，等所有控件实例化完成、Load事件首行代码执行后再发送WM_SETREDRAW参数为TRUE，最后调用RedrawWindow刷新窗体。如果操作后耗时下降90%以上，可完全确定卡顿是频繁的增量重绘导致。
• 公共控件版本校验：Win10自带的comctl32.dll为6.x版本，和VB6默认依赖的5.x版本存在接口差异，尤其是MonthView这类旧控件的初始化逻辑在6.x版本中会额外执行主题适配计算。可在程序同目录下添加manifest文件强制绑定comctl32.dll 5.8版本，测试耗时变化。

• 自定义控件逻辑优化：给自定义控件内部的UserControl_Resize、UserControl_Paint事件代码加判定，仅当Ambient.UserMode为TRUE（运行时，排除设计时场景）、且控件尺寸实际发生变化时才执行重绘逻辑，避免实例化阶段无脑触发重绘。
• 窗体批量加载优化：所有包含大量自定义控件的窗体，在Load事件最开头先发送WM_SETREDRAW = 0暂停重绘，所有控件初始化、赋值、尺寸调整操作完成后，再恢复重绘并批量刷新一次，避免每个控件实例化都触发一次父窗体重绘。
• 控件按需加载：如果窗体内的控件不是首屏全部需要展示，改为分页加载或滚动到对应区域时动态创建控件实例，不要一次性初始化全量控件。
• 兼容层适配：如果代码修改成本过高，可给程序添加系统兼容性标志，强制以Win7兼容模式运行，实测可规避80%以上Win10下VB6旧控件的调度性能问题。

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