在成功加载到内存后,创建对象突然开始失败

Question

行为:
应用程序已加载并按预期使用.突然,无法再加载特定的DLL.错误消息是:
ActiveX组件无法创建对象.
在每种情况下,对象在失败之前已成功创建多次.所有对象都标记为"保留在内存中".

回收应用程序池时,将清除此错误.可能需要数小时或数月才能再次看到它.

问题发生在刷新后的两个小时内,并且在几个月的正常运行时间内从未发生过.
数百个同时用户(大量使用)以及1-3个用户也发生了问题.

问题发生时,运行该应用程序池的进程无法创建失败的对象.但是它可以创建任何其他对象.内存,CPU和其他资源都保持正常使用状态.此外,其他进程(例如独立的exe)可以成功创建对象.

该问题的第一个实例出现在2008年中期.自那时以来,已经有不到50个实例,尽管有数百台服务器可供使用.除一个实例之外的所有实例都在同一DLL上失败.

DLL失败信息:
最常见的 - 实现b树的通用数据结构,除了接口之外没有其他引用.代码由数组和vb6事件功能的一个用途组成.自2005年以来,该对象没有任何改变.
一次性 - 与.NET模块互操作.尝试创建互操作对象而不是.NET对象时发生失败.该对象每年更新几次.

应用程序环境:
IIS托管应用程序
VB6,经典ASP,一些与小型.NET组件互操作
Windows Server 2003/Windows Server 2008(两者都独立出现问题)

尝试重现:
使用脚本(和现实生活中的人类)运行我们的日志在问题发生前几天报告的相同最终用户工作流程.
使用脚本从多个同时会话中尽可能快地创建/销毁可疑对象.
狂野的猜测.没有故意的成功,但它确实在服务器上随机出现.

故障排除:
代码审查
测试线束以调查对象创建/销毁的上限在
验证问题的过程之外创建对象的能力的验证
在负载的服务器上监视资源随着时间的推移
检查IIS,错误和事件日志以确定事件导致发布

问题:
有关如何重现问题的任何想法？
什么可能导致这种行为？
绕过前两个问题的想法有利于快速解决方案？

Answer 1

我在访问 ADO/OLEDB 堆栈时使用Process Monitor来调试类似的问题。结果环境在某个时候被损坏，ADO 类在 InprocServer32 中注册为 REG_EXPAND_SZ，指向 %CommonProgramFiles%\System\ado\msado15.dll 或类似的 ot x64 操作系统。

另外，当您使用重新启动管理器注册应用程序时，如果失败，该进程将由 winlogon 进程重新启动，该进程的环境与资源管理器的环境不同，并且不幸的是缺少％CommonProgramFiles％ - 哎呀！