自由运行测试程序退出后不久，我附上与86 VS2010 SP1 [英] Free-running application under test exits shortly after I attach with VS2010 SP1 in x86
问题描述
在Windows 7 64位系统，当我的x86模式下连接到一个相当复杂的自由运行的应用程序，它运行一段时间，然后重复地退出。
On Windows 7 x64, when I attach in x86 mode to a fairly complex free-running app, it runs for a while, then reproducibly exits.
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继续下去，应用程序退出以同样的方式。
Sometimes if it runs OK, it would hit my breakpoint, I'll inspect the state, but when I hit F5 to keep going, the app exits in the same fashion.
快速搜索错误code告诉我，这是一个堆栈缓冲区溢出。我听说，它可能由不正确的非托管互操作code而引起的。
Quick search for the error code tells me that it's a Stack Buffer Overrun. I hear that it might be caused by incorrect unmanaged interop code.
我可以从调试OK（F5），但自由运行运行，始终连接有这个问题。
I can run from debugger OK (F5), but free-running and attaching always has this problem.
这是我怎么能缩小它有什么想法？
Any thoughts on how I could narrow it down?
编辑：这是一个调用堆栈，我看到了不同的机器（在Windows Server 2008 R2 x64）的位置，可能与上：
Here's a callstack i am seeing on a different machine (Windows Server 2008 R2 x64) here, might be related:
clr.dll！ crt_debugger_hook（）
clr.dll！ _report_gsfailure（）+将0xEB字节
clr.dll!_DoJITFailFast@0（）+，位于0x8字节
clr.dll！CrawlFrame :: SetCurGSCookie（）+ 0x2e9c4f字节
clr.dll！StackFrameIterator ::初始化（）+字节地址0x60
clr.dll！主题:: StackWalkFramesEx（）+ 0x8a字节
clr.dll！主题:: StackWalkFrames（）+ 87H的字节
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 :: GCHeap :: GarbageCollectGeneration（）+ 0xba字节
clr.dll！WKS :: gc_heap :: try_allocate_more_space（）+ 0x1cd0字节
clr.dll！WKS :: gc_heap :: allocate_more_space（）+ 0x13字节
clr.dll！WKS :: GCHeap ::的Alloc（）+ 0x507字节
clr.dll！的Alloc（）+ 5AH即可字节
clr.dll！SlowAllocateString（）+ 0×41字节
clr.dll！UnframedAllocateString（）+ 0×11字节
clr.dll！StringObject :: NewString（）+值为0x26字节
clr.dll！Int64ToDecStr（）+ 0x12e字节
clr.dll！COMNumber :: FormatInt64（）+ 0x17e字节
mscorlib.ni.dll！6c60b8e1（）
[相框下面可能是不正确的和/或缺失，没有加载mscorlib.ni.dll符号]
System.Data.ni.dll！5d8d50b2（）
System.Data.ni.dll！5d8d48a0（）
System.Data.ni.dll！5d8d30ce（）
System.Data.ni.dll！5d89ea62（）
System.Data.ni.dll！5d89bb65（）
System.Runtime.Serialization.ni.dll！564c0746（）
System.Runtime.Serialization.ni.dll！564c1638（）
System.Runtime.Serialization.ni.dll！564db149（）
System.Runtime.Serialization.ni.dll！563a3898（）
System.Runtime.Serialization.ni.dll！563a3829（）
System.Runtime.Serialization.ni.dll！563a43c9（）
System.Runtime.Serialization.ni.dll！563ae33f（）
System.Runtime.Serialization.ni.dll！563adfb6（）
System.Runtime.Serialization.ni.dll！563addf0（）
System.Runtime.Serialization.ni.dll！563add3d（）
System.ServiceModel.ni.dll！5334bed8（）
System.ServiceModel.ni.dll！5334be4c（）
System.ServiceModel.ni.dll！5334bdec（）
System.ServiceModel.ni.dll！5334bd68（）
System.ServiceModel.ni.dll！5334bcf2（）
System.ServiceModel.ni.dll！5334bc4e（）
System.ServiceModel.ni.dll！5335c0e5（）
System.ServiceModel.ni.dll！5334bbdb（）
System.ServiceModel.ni.dll！5338da70（）
System.ServiceModel.ni.dll！53360a39（）
System.ServiceModel.ni.dll！533601e5（）
clr.dll！ThreadNative :: GetCurrentThread（）+，位于0x8字节
mscorlib.ni.dll！6c6715a9（）
mscorlib.ni.dll！6c62a25e（）
clr.dll！ CTPMethodTable 的_CallTargetHelper3 @ 16（）+ 0xF的字节
clr.dll InitMessageData（）！ - 0x1ed205字节
clr.dll！CTPMethodTable :: CallTarget（）+为0x16字节
clr.dll！CTPMethodTable :: OnCall中（）+ 0x1f0ec5字节
0245e346（）
1c0f8fde（）
1c0f88d1（）
1c0f873f（）
1c0f8549（）
0b8aaf79（）
09ac3b9a（）
mscorlib.ni.dll！6c66ae5b（）
mscorlib.ni.dll！6c5f7ff4（）
mscorlib.ni.dll！6c5f7f34（）
mscorlib.ni.dll！6c66ade8（）
clr.dll!_CallDescrWorker@20（）+ 0x33字节
clr.dll!_CallDescrWorkerWithHandler@24（）+ 0x8a字节
clr.dll！方法描述:: CallDescr（）+ 0x148字节
clr.dll！方法描述:: CallTargetWorker（）+ 0×21字节
clr.dll！ThreadNative :: KickOffThread_Worker（）+ 0x129字节
clr.dll！主题:: DoExtraWorkForFinalizer（）+ 0xb6e56字节
clr.dll主题:: ShouldChangeAbortToUnload（） - ！0x5f8字节
clr.dll主题:: ShouldChangeAbortToUnload（） - ！0x53d字节
clr.dll主题:: ShouldChangeAbortToUnload（） - ！0x4a3字节
clr.dll！ManagedThreadBase ::开工（）+ 0x15字节
clr.dll！ThreadNative :: KickOffThread（）+ 0XAF字节
clr.dll！主题:: intermediateThreadProc（）+ 0x48字节
KERNEL32.DLL！@ BaseThreadInitThunk @ 12（）+ 0×12字节
ntdll.dll中！__ RtlUserThreadStart @ 8（）+ 0x27字节
ntdll.dll中！的_RtlUserThreadStart @ 8（）+ 0x1b字节
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]
System.Data.ni.dll!5d8d50b2()
System.Data.ni.dll!5d8d48a0()
System.Data.ni.dll!5d8d30ce()
System.Data.ni.dll!5d89ea62()
System.Data.ni.dll!5d89bb65()
System.Runtime.Serialization.ni.dll!564c0746()
System.Runtime.Serialization.ni.dll!564c1638()
System.Runtime.Serialization.ni.dll!564db149()
System.Runtime.Serialization.ni.dll!563a3898()
System.Runtime.Serialization.ni.dll!563a3829()
System.Runtime.Serialization.ni.dll!563a43c9()
System.Runtime.Serialization.ni.dll!563ae33f()
System.Runtime.Serialization.ni.dll!563adfb6()
System.Runtime.Serialization.ni.dll!563addf0()
System.Runtime.Serialization.ni.dll!563add3d()
System.ServiceModel.ni.dll!5334bed8()
System.ServiceModel.ni.dll!5334be4c()
System.ServiceModel.ni.dll!5334bdec()
System.ServiceModel.ni.dll!5334bd68()
System.ServiceModel.ni.dll!5334bcf2()
System.ServiceModel.ni.dll!5334bc4e()
System.ServiceModel.ni.dll!5335c0e5()
System.ServiceModel.ni.dll!5334bbdb()
System.ServiceModel.ni.dll!5338da70()
System.ServiceModel.ni.dll!53360a39()
System.ServiceModel.ni.dll!533601e5()
clr.dll!ThreadNative::GetCurrentThread() + 0x8 bytes
mscorlib.ni.dll!6c6715a9()
mscorlib.ni.dll!6c62a25e()
clr.dll!CTPMethodTable_CallTargetHelper3@16() + 0xf bytes
clr.dll!InitMessageData() - 0x1ed205 bytes clr.dll!CTPMethodTable::CallTarget() + 0x16 bytes
clr.dll!CTPMethodTable::OnCall() + 0x1f0ec5 bytes
0245e346()
1c0f8fde()
1c0f88d1()
1c0f873f()
1c0f8549()
0b8aaf79()
09ac3b9a()
mscorlib.ni.dll!6c66ae5b()
mscorlib.ni.dll!6c5f7ff4()
mscorlib.ni.dll!6c5f7f34()
mscorlib.ni.dll!6c66ade8()
clr.dll!_CallDescrWorker@20() + 0x33 bytes clr.dll!_CallDescrWorkerWithHandler@24() + 0x8a bytes
clr.dll!MethodDesc::CallDescr() + 0x148 bytes
clr.dll!MethodDesc::CallTargetWorker() + 0x21 bytes
clr.dll!ThreadNative::KickOffThread_Worker() + 0x129 bytes clr.dll!Thread::DoExtraWorkForFinalizer() + 0xb6e56 bytes
clr.dll!Thread::ShouldChangeAbortToUnload() - 0x5f8 bytes
clr.dll!Thread::ShouldChangeAbortToUnload() - 0x53d bytes
clr.dll!Thread::ShouldChangeAbortToUnload() - 0x4a3 bytes
clr.dll!ManagedThreadBase::KickOff() + 0x15 bytes
clr.dll!ThreadNative::KickOffThread() + 0xaf bytes clr.dll!Thread::intermediateThreadProc() + 0x48 bytes
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!_RtlUserThreadStart@8() + 0x1b bytes
EDIT2 事情似乎罚款的应用程序的64位版本，问题只出现在86。
EDIT2 Things seem fine on x64 build of the app, issue only appears in x86.
推荐答案
从Windows SDK NTSTATUS.H头文件：
From the Windows SDK ntstatus.h header file:
//
// 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
溢出在分配的栈缓冲区缓冲区是一个臭名昭著的病毒注射载体。微软变得格外谨慎，避免潜在的线程在他们的code。 C和C ++语言中是第一个。管理code踉踉跄跄的背后，这是不是说应该发生在一个托管执行环境。
A buffer overrun on a stack allocated buffer is an infamous virus injection vector. Microsoft got very serious about eliminating that potential thread in their code. The C and C++ languages were first. Managed code straggled behind, this is not something that is supposed to happen in a managed execution environment.
不过，第4版CLR内建的保护到位，不像早期CLR版本。而它的工作，虽然这是极其罕见的它发生。我只有一次以前见过一个关于它的问题。
Nevertheless, the version 4 CLR was built with the protection in place, unlike earlier CLR versions. And it does its job, although it is exceedingly rare for it to happen. I've seen a question about it only once before.
解决这个问题将是困难的，尤其是当你有没有明显导致什么非托管code。在您的应用程序可能会被绊倒这种保护。做的最好的事情就是让一个最小的摄制，并联系Microsoft支持，向他们展示什么错误。要想知道它车次上工作时获得的摄制是一个可能的结果。
Solving this problem is going to be difficult, especially when you have no obvious lead to what unmanaged code in your application might be tripping this protection. Best thing to do is to make a minimal repro and contact Microsoft Support to show them what is going wrong. Finding out what trips it while working on getting the repro is a likely outcome.
这篇关于自由运行测试程序退出后不久，我附上与86 VS2010 SP1的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
