У нас есть управляемое приложение C# (MS Visual Studio 2010, целевая структура: .Net 4 Client Profile), который использует неуправляемые COM-объекты через Interop, а также использует функции P/Invoke для вызова в нашей собственной DLL (C++). Вызовы P/Invoke производятся от System.Threading.Task процедур и поэтому могут проходить одновременно. Мы ограничиваем общее количество одновременных заданий до 10.Ошибка выполнения библиотеки VC++ MS VC++ Запуск управляемого приложения C#
Приложение может работать некоторое время, постоянно создавая задачи и вызывая неуправляемые функции. В какой-то момент появится диалоговое окно - Microsoft Visual C++ Runtime Library/Runtime Error!/Приложение запросило Runtime для его необычного завершения ...
В результате диалогового окна нет записей журнала событий. 
Пока отображается диалоговое окно, приложение продолжает работать, хотя его использование памяти продолжает расти. Как отслеживается в TaskManager и VMMap (Sysinternals), использование памяти увеличивается еще на 5-10 минут, а затем приложение падает.
Вопрос: Почему приложение продолжает работать даже после появления диалогового окна с ошибкой?
Непосредственно перед сбоем, то есть по мере исчерпания памяти System.OutOfMemoryException выбрасывается любым кодом, который пытается выделить память и попадает на C#.
Так что на данный момент журнал событий приложений имеет новую запись означает следующее:
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18798 Exception code: 0xe0434352 Fault offset: 0x0000c42d Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException
Никакой дополнительной информации не имеется; файлы дампа не генерируются. Наши неуправляемые компоненты (COM DLL, DLL) не отображаются как модули сбоев.
Вот список инструментов, мы использовали до сих пор:
DbgView для просмотра ATL следов от используемых компонентов.
VMMap исследовать фрагментации, кучи и т.д.
DebugDiag, чтобы проверить на наличие утечек памяти, анализировать управляемые и неуправляемые память, стек вызовов и т.д.
Если есть какие-либо другие методы или методы, которые могут быть использованы для определения фактической последовательности вызовов, которые приводят к ошибке выполнения MS C++ Runtime, любое конструктивное предложение было бы оценено.
Поскольку вы видите увеличенное использование памяти, возможно, это будет начало рассмотрения неуправляемых вызовов PInvoke и того, как данные сортируются. Его глубокий предмет, но неспособность запоминать память, позволяя памяти собирать мусор, пока неназванный код все еще использует его, включая возможные условия гонки от потоковой передачи этих данных, может вызвать аномальные сбои. Я желаю вам удачи, это жесткая печенья, чтобы взломать. – Kratz
Вам нужно отладить это. Инструмент и осмотрите. Не совсем предмет для SO, который уже. –
@CaptainObvlious Я не думаю, что просить МЕТОД делает это вне темы. – JNK