Тестируемое автономно работающее приложение завершается вскоре после подключения с VS2010 SP1 в x86

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 байтов 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 :: 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 () + 0x5a байт
clr.dll! SlowAllocateString () + 0x41 байт
clr.dll! UnframedAllocateString () + 0x11 байт
clr.dll! StringObject :: NewString () + 0x26 байт clr.dll! Int64ToDecStr () + 0x12e байт
clr.dll! COMNumber :: FormatInt64 () + 0x17e байт 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

Переполнение буфера в буфере, выделенном для стека, является печально известным вектором внедрения вируса.Microsoft очень серьезно относится к устранению этого потенциального потока в своем коде.Языки C и C ++ были первыми.Управляемый код отстает, это не то, что должно происходить в среде управляемого выполнения.

Тем не менее, CLR версии 4 был построен с установленной защитой, в отличие от более ранних версий CLR.И он делает свою работу, хотя это случается крайне редко.Я уже видел вопрос об этом только один раз.

Решение этой проблемы будет трудным, особенно если у вас нет очевидных указаний на то, что неуправляемый код в вашем приложении может отключить эту защиту.Лучше всего сделать минимальное повторение и обратиться в службу поддержки Microsoft, чтобы показать им, что происходит не так.Вероятно, выяснить, что сработало во время работы над репродукцией.

Answer 2

Похоже, я должен быть в состоянии сузить его, введя в свой код вызовы 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

Answer 3

правильная подпись взаимодействия?попробуйте использовать http://clrinterop.codeplex.com/releases/view/14120 для генерации и попробуйте снова.