VB.NET应用程序在ntdll.dll中给出内存异常0xc0000005

Question

我正在处理的VB.NET应用程序中存在内存访问异常的问题。我希望能在这里获得一些见解，因为我所做的研究都没有帮助我找到问题。

背景

我正在将许多应用程序从VB6转换为.NET 4.0。在客户端的请求下，我正在进行直接转换，并且只在必要时进行重构，以避免在转换时将其他问题注入代码中。大多数应用程序都是在任何CPU模式下编译的，但由于依赖32位PLC软件或较旧的硬件驱动程序，有些应用程序必须编译为x86。我的开发机器是Windows 7 64位。

问题：

成功转换两个应用程序后，第三个应用程序崩溃了 代码中的随机位置。没有捕获异常，我必须查看我看到异常的事件日志 代码：ntdll.dll上的0xc0000005，我认为是一个内存访问异常。由于应用程序并不总是在同一个地方崩溃，因此很难跟踪。我注意到在调用ADODB期间发生了很多错误（并不总是在同一个地方或同一个调用中），但是在调用form.ShowDialog（）时它也崩溃了。

调用ShowDialog的表单会将一些日志信息写入 DB使用ADODB。虽然我无法确认，但我猜测form.ShowDialog（）在其中一个ADODB调用期间发生异常。 ADODB调用的崩溃发生在已成功用于转换的其他两个应用程序的程序集中，并且它不会在同一位置始终崩溃。

在我对此的研究中，我发现糟糕的互操作可能导致这个问题。想知道ADODB COM调用是否在某种程度上导致了这个应用程序中的问题，即使这些调用在其他应用程序中也没问题。

我观察过的一些地方显然将这个异常抛给了事件日志：

• 新建ADODB.recordset
• 在command.append
中创建新参数
• connection.open calls

任何人都有任何想法如何我可以缩小到可能跟踪 问题根本原因？我感谢您提供的任何帮助或见解。

Answer 1

啊...... PLC让我回归。如果制造商没有更新的驱动程序集，那么您可能正在进行艰苦的战斗。可能发生的是，较新的操作系统要快得多，或者核心更多，或者两者的某种组合导致驱动程序代码中存在“竞争”条件。在经常使用线程的通信中尤其如此。由于驱动程序代码很可能是用C或C ++（非托管）编写的，因此您可能无法控制这些条件。您可以尝试使用运行应用程序的线程模型。如果这样可以提高稳定性，那就去吧。

Apartment-Model Threading in Visual Basic 6

DotNet MTA Thread Attribute

DotNet STA Thread Attribute

最糟糕的情况是，您可以使用驱动程序生成一个单独的进程，并使用各种“进程间通信”技术从主应用程序与其进行通信。如果它崩溃，你会提出另一个，但你的主应用程序仍将继续运行。您甚至可以在绝对最坏的情况下将外部进程编写为VB6应用程序。

祝你好运。