我们一直在解决以下问题，并寻求一些新的想法或攻击角度。
第一种情况：
我们有一个ASP.NET Web应用程序，.NET 3.5，C#，针对x86构建，运行在IIS7 / Windows Server 2008 R2（64位）上。ASP.NET Web应用程序在启用32位应用程序的默认应用程序池下运行。
此Web应用程序利用一些使用VB6编写并构建为ActiveX DLL的旧组件。这些DLL使用regsvr32注册。对这些组件的引用被添加到Web应用程序项目（Visual Studio 2008）中，我们正在使用生成的Interop类。
当以发布模式构建Web应用程序时，每次调用这些旧的VB6组件时，都会在子例程堆栈深处抛出错误。通常是这样的：
ERROR 91 Object variable or With block variable not set [ComponentName:ClassName.cls:MethodName]
当相同的Web应用程序代码改为以调试模式构建时，相同的错误发生，但它们是间歇性的。如果在Web应用程序中重复执行相同的操作10次（输入相同，其他所有内容均相等），我们将大约看到一次该问题。
第二种情况：
除了Web应用程序外，我们还有一个.NET 3.5 C#应用程序，构建为目标为x86，在Windows Server 2008 R2（64位）上作为Windows服务运行。此服务调用与网站使用的DLL相关的ActiveX EXE（共同遗产和依赖项）。 ActiveX EXE使用/regserver开关注册，并添加对.NET项目的引用。生成的Interop类被使用。由于ActiveX EXE的性质，方法调用在其自己的线程中异步执行，并使用事件通知调用者完成。
如果以发布模式构建.NET应用程序，则对EXE的方法调用不会引发错误（就我所见），但是指示成功的ActiveX EXE应该引发的事件未被.NET应用程序接收到。
如果相同的.NET应用程序代码改为以调试模式构建，则事件将由EXE引发并被.NET应用程序接收/处理。
我将这些问题一起发布，因为它们都会随着调试与发布版本的更改而改变，我的直觉是原因是相关的。目前，我们正在关注垃圾回收可能存在的问题，以及ActiveX EXE中外部进程工作和Web应用程序中的线程问题。欢迎提出任何需要调查的领域的想法。
第一种情况：
我们有一个ASP.NET Web应用程序，.NET 3.5，C#，针对x86构建，运行在IIS7 / Windows Server 2008 R2（64位）上。ASP.NET Web应用程序在启用32位应用程序的默认应用程序池下运行。
此Web应用程序利用一些使用VB6编写并构建为ActiveX DLL的旧组件。这些DLL使用regsvr32注册。对这些组件的引用被添加到Web应用程序项目（Visual Studio 2008）中，我们正在使用生成的Interop类。
当以发布模式构建Web应用程序时，每次调用这些旧的VB6组件时，都会在子例程堆栈深处抛出错误。通常是这样的：
ERROR 91 Object variable or With block variable not set [ComponentName:ClassName.cls:MethodName]
当相同的Web应用程序代码改为以调试模式构建时，相同的错误发生，但它们是间歇性的。如果在Web应用程序中重复执行相同的操作10次（输入相同，其他所有内容均相等），我们将大约看到一次该问题。
第二种情况：
除了Web应用程序外，我们还有一个.NET 3.5 C#应用程序，构建为目标为x86，在Windows Server 2008 R2（64位）上作为Windows服务运行。此服务调用与网站使用的DLL相关的ActiveX EXE（共同遗产和依赖项）。 ActiveX EXE使用/regserver开关注册，并添加对.NET项目的引用。生成的Interop类被使用。由于ActiveX EXE的性质，方法调用在其自己的线程中异步执行，并使用事件通知调用者完成。
如果以发布模式构建.NET应用程序，则对EXE的方法调用不会引发错误（就我所见），但是指示成功的ActiveX EXE应该引发的事件未被.NET应用程序接收到。
如果相同的.NET应用程序代码改为以调试模式构建，则事件将由EXE引发并被.NET应用程序接收/处理。
我将这些问题一起发布，因为它们都会随着调试与发布版本的更改而改变，我的直觉是原因是相关的。目前，我们正在关注垃圾回收可能存在的问题，以及ActiveX EXE中外部进程工作和Web应用程序中的线程问题。欢迎提出任何需要调查的领域的想法。