c# - 在 x86 中附加 VS2010 SP1 后不久，测试中的自由运行应用程序退出

Question

在 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)上看到的调用堆栈，可能相关:

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 bytes
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 bytes
clr.dll!WKS::gc_heap::garbage_collect() + 0x1c1 bytes
clr.dll!WKS::GCHeap::GarbageCollectGeneration() + 0xba bytes
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 bytes
clr.dll!UnframedAllocateString() + 0x11 bytes
clr.dll!StringObject::NewString() + 0x26 bytes clr.dll!Int64ToDecStr() + 0x12e bytes
clr.dll!COMNumber::FormatInt64() + 0x17e bytes mscorlib.ni.dll!6c60b8e1()
[Frames below may be incorrect and/or missing, no symbols loaded for 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

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

然而，与早期的 CLR 版本不同，第 4 版 CLR 是在适当的保护下构建的。它完成了它的工作，尽管它发生的情况极为罕见。我以前只看过一次关于它的问题。

解决这个问题会很困难，尤其是当您没有明显的线索表明您的应用程序中的哪些非托管代码可能会触发此保护时。最好的办法是进行最少的重现并联系 Microsoft 支持以向他们展示出了什么问题。在努力获得重现的同时找出是什么绊倒了它是一个可能的结果。