我在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)上看到的一个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 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()
[下面的框架可能不正确和/或缺失,没有为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 是在适当的保护下构建的。它也完成了它的工作，尽管这种情况发生的极其罕见。我以前只见过一次有关此问题的问题。

解决这个问题将会很困难，特别是当您没有明显的原因导致应用程序中的非托管代码可能会触发此保护时。最好的办法是进行最小程度的重现，然后联系 Microsoft 支持人员，向他们展示问题所在。在努力获取复制品的同时找出是什么原因导致了它的失败是一个可能的结果。