Тестируемое автономно работающее приложение завершается вскоре после подключения с VS2010 SP1 в x86
В 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, чтобы продолжить работу, приложение закрывается таким же образом.
Быстрый поиск кода ошибки говорит мне, что это переполнение буфера стека. Я слышал, что это может быть вызвано неправильным неуправляемым кодом взаимодействия.
Я могу запустить из отладчика ОК (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.
3 ответа
Из заголовочного файла 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++ были первыми. Управляемый код отстает, это не то, что должно происходить в среде управляемого выполнения.
Тем не менее, версия 4 CLR была построена с установленной защитой, в отличие от более ранних версий CLR. И это делает свою работу, хотя это случается крайне редко. Я видел вопрос об этом только один раз.
Решение этой проблемы будет трудным, особенно если у вас нет очевидной причины, по которой неуправляемый код в вашем приложении может отключить эту защиту. Лучше всего сделать минимальное повторение и связаться со службой поддержки Microsoft, чтобы показать им, что происходит не так. Выяснение того, что сработало во время работы над репро, является вероятным результатом.
Похоже, я должен быть в состоянии сузить это, введя вызовы 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 устранения неполадок-PInvoke-5wbEHu80dzF,rZ5U5DaVJaE
Правильная подпись взаимодействия? попробуйте использовать http://clrinterop.codeplex.com/releases/view/14120 для его генерации и повторите попытку.