mscorwks.dll中出现异常代码c0000005的原因及解决方法是什么?

发布于 2024-10-09 11:58:23 字数 683 浏览 1 评论 0 原文

当应用程序在使用测试完成启动的 Windows Server 2008 R2 上运行时,从 mscorwks.dll 引发异常代码 C0000005。其他平台(Windows XP、Server 2003 R2、Windows 7 32 位和 64 位)不存在此异常。

单次执行的事件日志包含许多由 .NET 运行时引发的事件 ID 为 1023 的以下事件:

.NET 运行时版本 2.0.50727.4952 - 致命执行引擎错误 (7383851A) (80131506)

应用程序本身使用 Visual Studio 从 WSDL 文件生成的 SOAP 接口,这是一个嵌入了互操作,并且面向 .NET 4。

sfc /scannow 是运行并发现受影响系统上的系统文件没有问题。

可以进行哪些故障排除来确定解决方案?

The exception code C0000005 is thrown from mscorwks.dll when the application is run on Windows Server 2008 R2 launched using test complete. Other platforms (Windows XP, Server 2003 R2, Windows 7 32-bit and 64-bit) do not present this exception.

The event log from a single execution has many of the following event with event ID 1023 raised by the .NET Runtime:

.NET Runtime version 2.0.50727.4952 - Fatal Execution Engine Error (7383851A) (80131506)

The application itself makes use of a SOAP interface generated by Visual Studio from a WSDL file, a COM object with an embedded interop, and is targeting .NET 4.

sfc /scannow was run and found no problems with system files on the affected system.

What troubleshooting can be done to identify a solution?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

情话墙 2024-10-16 11:58:24

0xC0000005 是包装 Win32 错误的异常代码,表示“访问被拒绝”。鉴于您正在使用 COM 互操作并收到 ExecutionEngineException(在 COM 中,COR_E_EXECUTIONENGINE;0x80131506),我的猜测是,它要么是 COM 组件中的 NULL 指针,要么是错误的 ComImport 指令在您的 .NET 代码中。

A 0xC0000005 is an exception code wrapping a Win32 error which means "Access Denied." Given that you are using COM interop and are getting an ExecutionEngineException (in COM, COR_E_EXECUTIONENGINE; 0x80131506), my guess is that either it's a NULL pointer in the COM component or a faulty ComImport directive in your .NET code.

早乙女 2024-10-16 11:58:24

此错误是由 TestComplete 7 与混合托管/非托管应用程序中的堆交互方式中的缺陷引起的。使用以下代码块代替使用 TestedApp.Run 方法,该代码块根据您选择的脚本语言进行了修改,如 VBScript

Dim oScript, command
Set oScript = CreateObject("WScript.Shell")

command = "%comspec% /c " & PATH_TO_EXE & " " & Args
oScript.Run command, 10, True 

相关的 MSDN 文章是 运行方法(Windows 脚本宿主)

This error is caused by flaws in the way that TestComplete 7 interacts with the heap in mixed managed/unmanaged applications. Instead of using the TestedApp.Run method using the following block of code, modified for you choice of scripting language, presented in VBScript:

Dim oScript, command
Set oScript = CreateObject("WScript.Shell")

command = "%comspec% /c " & PATH_TO_EXE & " " & Args
oScript.Run command, 10, True 

The relevant MSDN article is Run Method (Windows Script Host).

谜兔 2024-10-16 11:58:24

TestComplete 7(包括最新更新 7.52)仅支持 .NET Framework 4 至 .NET 4 Beta 2 版本。它不支持 Framework 的发行版本,因此这可能是问题的原因。

尝试构建面向 .NET 2.0 的应用程序。这应该可以解决问题。

要测试 .NET 4 应用程序,您需要使用 TestComplete 8

TestComplete 7 (including the latest update 7.52) supports .NET Framework 4 only up to version .NET 4 Beta 2. It does not support the release version of the Framework, so this may be the reason of the problem.

Try building the application targeting .NET 2.0. This should resolve the problem.

To test .NET 4 applications, you will need to use TestComplete 8.

浮光之海 2024-10-16 11:58:23

致命引擎执行错误和访问冲突都是同一问题的症状。当 .NET 垃圾收集器检测到垃圾收集堆的内部结构被破坏时,就会产生 FEEE。访问冲突是一种硬件异常,当处理器被要求访问具有无效地址的内存时,会引发该异常。 AV 的一个常见原因是堆损坏。

此类事故通常是由非托管代码引起的。非托管代码存在潜在的内存管理错误,这些错误可能会很长一段时间被忽视,这种情况也很常见。该错误造成的损害往往是相当随机的。只需在具有不同内存分配模式的另一个操作系统上运行它就足以触发炸弹。

你有一个很好的候选人来找出问题的根源。您需要与 COM 服务器供应商或作者合作来追踪错误。

Fatal Engine Execution Error and an access violation are both symptoms of the same problem. FEEE is raised when the .NET garbage collector detects that the internal structure of the garbage collected heap is destroyed. An access violation is a hardware exception, raised by the processor when it is asked to access memory with an invalid address. A common cause of an AV is heap corruption.

These kind of mishaps are very commonly caused by unmanaged code. It is also quite common for unmanaged code to have latent memory management bugs that can go unnoticed for a long time. The kind of damage the bug can do tends to be quite random. Just running it on another operating system which has a different memory allocation pattern can be enough to trigger the bomb.

You have an excellent candidate for the source of the trouble. You'll need to work with the COM server vendor or author to chase the bug.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文