我在x86中附加VS2010 SP1后不久就出现了自由运行的测试应用程序

在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继续前进时，应用程序以同样的方式退出。

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

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

有关如何缩小范围的任何想法？

编辑：这是我在不同的机器（Windows Server 2008 R2 x64）上看到的一个callstack，可能是相关的：

clr.dll！__ crt_debugger_hook（）
clr.dll！___ report_gsfailure（）+ 0xeb bytes clr.dll！_DoJITFailFast@0（）+ 0x8 bytes clr.dll！CrawlFrame :: SetCurGSCookie（）+ 0x2e9c4f bytes
clr.dll！StackFrameIterator :: Init（）+ 0x60字节
clr.dll！Thread :: StackWalkFramesEx（）+ 0x8a bytes
clr.dll！Thread :: StackWalkFrames（）+ 0x87 bytes clr.dll！CNameSpace :: GcScanRoots（）+ 0xd7 bytes clr.dll！WKS :: gc_heap :: mark_phase（）+ 0xae bytes
clr.dll！WKS :: gc_heap :: gc1（）+ 0x7b字节
clr.dll！WKS :: gc_heap :: garbage_collect（）+ 0x1c1个字节
clr.dll！WKS :: GCHeap :: GarbageCollectGeneration（）+ 0xba字节
clr.dll！WKS :: gc_heap :: try_allocate_more_space（）+ 0x1cd0 bytes clr.dll！WKS :: gc_heap :: allocate_more_space（）+ 0x13 bytes
clr.dll！WKS :: GCHeap :: Alloc（）+ 0x507 bytes clr.dll！Alloc（）+ 0x5a bytes
clr.dll！SlowAllocateString（）+ 0x41字节
clr.dll！UnframedAllocateString（）+ 0x11字节
clr.dll！StringObject :: NewString（）+ 0x26 bytes clr.dll！Int64ToDecStr（）+ 0x12e bytes
clr.dll！COMNumber :: FormatInt64（）+ 0x17e bytes mscorlib.ni.dll！6c60b8e1（）
[下面的框架可能不正确和/或缺失，没有为mscorlib.ni.dll加载符号]

EDIT2在应用程序的x64版本上似乎没什么问题，问题只出现在x86中。

Answer 1

从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是在保护的基础上构建的。 它发挥了作用，尽管它的发生极为罕见。 我之前只见过一次关于它的问题。

解决这个问题将很困难，尤其是当你没有明显的导致你的应用程序中的非托管代码可能会绊倒这种保护时。 最好的办法是制作一个最小的repro并联系Microsoft支持，以向他们展示出现了什么问题。 在找到repro的同时找出它的绊倒可能是一个结果。

Answer 2

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

Answer 3

看起来我应该能够通过在我的代码中注入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