在我连接到x86中的VS2010 SP1后不久，正在测试中的自由运行应用程序就会退出

本文关键字：测试 自由 运行 退出 应用程序 x86 连接 中的 VS2010 SP1 | 更新日期: 2023-09-27 17:59:07

在Windows 7 x64上，当我以x86模式连接到一个相当复杂的免费运行的应用程序时，它会运行一段时间，然后可复制地退出。

MyApp.exe Managed (v4.0.30319)' has exited with code -1073740791 (0xc0000409).

紧随其后的是

MyApp.vshost.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).

有时，如果它运行正常，它会碰到我的断点，我会检查状态，但当我按下F5继续运行时，应用程序会以同样的方式退出。

快速搜索错误代码告诉我这是一个堆栈缓冲区溢出。我听说这可能是由不正确的非托管互操作代码引起的。

我可以从调试器正常运行（F5），但自由运行和附加总是有这个问题。

有什么想法可以缩小范围吗？

编辑：这是我在另一台机器上看到的调用堆栈（Windows Server 2008 R2 x64），可能与有关

clr.dll__crt_debuger_hook（）
clr.dll___report_gsfailure（）+0xeb字节clr.dll！_DoJITFailFast@0（）+0x8字节clr.dll！CrawlFrame:：SetCurGSCookie（）+0x2e9c4f字节
clr.dll！StackFrameIterator:：Init（）+0x60字节
clr.dll！线程：：StackWalkFramesEx（）+0x8a字节
clr.dll！线程：：StackWalkFrames（）+0x87字节clr.dll！CNameSpace:：GcScanRoots（）+0xd7字节clr.dll！WKS:：gc_heap:：mark_phase（）+0xae字节
clr.dll！WKS:：gc_heap:：gc1（）+0x7b字节
clr.dll！WKS:：gc_heap:：garbage_collect（）+0x1c1字节
clr.dll！WKS:：GC堆：：GarbageCollectGeneration（）+0xba字节
clr.dll！WKS:：gc_heap:：try_allocate_more_space（）+0x1cd0字节clr.dll！WKS:：gc_heap:：allocate_more_space（）+0x13字节
clr.dll！WKS:：GC堆：：Alloc（）+0x507字节clr.dll！Alloc（）+0x5a字节
clr.dll！SlowAllocateString（）+0x41字节
clr.dll！UnframedAllocateString（）+0x11字节
clr.dll！StringObject:：NewString（）+0x26字节clr.dll！Int64ToDecStr（）+0x12e字节
clr.dll！COM编号：：FormatInt64（）+0x17e字节mscorlib.ni.dll！6c60b8e1（）
[下面的帧可能不正确和/或丢失，没有为mscorlib.ni.dll加载符号]

EDIT2应用程序的x64版本似乎一切正常，问题仅出现在x86中。

在我连接到x86中的VS2010 SP1后不久，正在测试中的自由运行应用程序就会退出

从Windows SDK ntstatus.h头文件：

//
// MessageId: STATUS_STACK_BUFFER_OVERRUN
//
// MessageText:
//
// The system detected an overrun of a stack-based buffer in this application. This overrun 
// could potentially allow a malicious user to gain control of this application.
//
#define STATUS_STACK_BUFFER_OVERRUN      ((NTSTATUS)0xC0000409L)    // winnt

堆栈分配的缓冲区上的缓冲区溢出是一种臭名昭著的病毒注入载体。微软非常认真地消除了他们代码中的潜在线程。C和C++语言是最早的。托管代码落后，这不是托管执行环境中应该发生的事情。

尽管如此，与早期的CLR版本不同，版本4的CLR是在适当的保护下构建的。尽管这种情况极为罕见，但它确实发挥了作用。我以前只见过一次关于它的问题。

解决这个问题将是困难的，尤其是当您没有明显的线索表明应用程序中的非托管代码可能会触发这种保护时。最好的做法是进行最低限度的重新编程，并联系Microsoft支持人员，向他们展示问题所在。很可能的结果是，在努力获得谴责的同时，找出是什么绊倒了它。

互操作签名是否正确？尝试使用http://clrinterop.codeplex.com/releases/view/14120生成它并重试。

看起来我应该能够通过在代码中注入GC.Collect（）调用来缩小它的范围：垃圾收集检查GSCookie等。

断开的链接1:http://7388.info/index.php/article/studio/2010-10-17/354.html

断开的链接2：http://www.pubsub.com/Investigating-a-GSCookie-Corruption_Windows-NET-Troubleshooting-PInvoke-5wbEHu80dzF，rZ5U5DaVJaE

相关文章：