Iis 在成功地将对象加载到内存中后，创建对象突然开始失败

行为：
应用程序已加载并按预期使用。 突然，某个特定的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、错误和事件日志，以确定导致问题的事件

问题：
关于如何重现这个问题有什么想法吗？
什么会导致这种行为？
关于绕过前两个问题而采用快速解决方案的想法？

我在访问ADO/OLEDB堆栈时曾调试过类似的问题。结果表明，环境在某个时候损坏，ADO类在InprocServer32注册为REG\U EXPAND\U SZ，指向%CommonProgramFiles%\System\ADO\msado15.dll或类似的ot x64操作系统

---

另外，当您向Restart Manager注册应用程序时，如果出现故障，该进程将由winlogon进程重新启动，该进程的环境与资源管理器的环境不同，并且很遗憾缺少%CommonProgramFiles%--哎哟

DLL不在网络驱动器上，是吗？当驱动器暂时不可用时，您可能会出现“故障”，这意味着COM无法执行其需要的操作，并且可能无法注意到驱动器再次可用。

这似乎是一个随机故障；某些竞赛条件。
尝试记录运行此dll的计算机的状态。当错误发生时，您可以重播记录并检查内存内容。这就是为什么您不必播放

尝试捕捉错误的原因。至少你会有一个可靠的记录

虽然我无法提供解决方案，但请尝试捕获错误，并在刷新环境后重新加载dll。
我无能为力-您已经完成了我建议的所有操作-但是您会对一个非常有趣的问题进行投票，并对问题进行了很好的说明。希望这里有人能解释你的问题。你实际上没有说错误是发生在VB6代码内部还是ASP代码中。失败的CreateObject调用在VB6代码内部。我更改了DLL基址，似乎已经解决了问题，但现在说还为时过早。其概念是，这将简单地避免在该位置损坏内存。如果对象本身正在破坏内存，这将失败，但我没有理由认为它会失败。Procmon在导致失败的操作中没有显示意外条目。不幸的是，由于不可预测性，在第一次出现故障之前不可能捕获所有事件。对已经发生故障的服务器使用procmon不会显示后续故障的有趣条目。该进程没有注册对对象或相关注册表项的任何请求，它在尝试从内存中加载的对象实例化时似乎失败。在您的案例中，您能够看到发生了什么损坏，但这是否告诉了您损坏是如何发生的或如何处理？（字符限制）这种类型的故障似乎会导致所有（或至少整个对象类）停止工作，而不仅仅是单个对象。不，所有文件都是在本地安装的。