Как я могу отлаживать ошибки кучи в библиотеке классов C#?

Question

Я получаю ошибку кучи коррупции в библиотечном модуле C#, который я вызываю через COM в приложении C++. Специфическая ошибка:

КУЧА: Free Heap блок 4b61bb8 модифицированный в 4b61be8 после того, как был освобожден
...
Это может быть связано с коррупции кучи и указывает ошибка в [ app] .exe или любой из загруженных DLL.

В верхней части стека вызовов является:

CustomMarshalers.dll!System.Runtime.InteropServices.CustomMarshalers.EnumeratorViewOfEnumVariant.MoveNext() + 0x168 bytes 

Теперь я понимаю, что .NET должен был смягчать проблемы с памятью, не делает больше проблем памяти с было невозможно исправить. Тем не менее, я не могу думать ни о чем, что я мог бы сделать, чтобы вызвать ошибку памяти или как я могу попытаться ее исправить. В конкретном модуле используются компоненты Microsoft.VisualStudio.VCProjectEngine .NET для итерации файлов проекта VC с помощью довольно простых итераторов. Он ломается в инструкции foreach во время итерации файлов в фильтре (папке) VCProject, после того, как он выполнил предыдущие 100 вызовов. Фактический код, который является нарушением:

IVCCollection CollectionFiles = (IVCCollection)FolderInProject.Files; 
    foreach (VCFile File in CollectionFiles) 
    { 
     [...] 
    } 

Как я могу отлаживать это?

Update:

Когда я звоню, если из чистого приложения C# консоли (не COM или нативный код не участвует), я получаю:

Необработанное исключение типа 'System.AccessViolationException' произошел в [component] .dll

Дополнительная информация : Попытка прочитать или защищенная память. Это часто указание на то, что другая память повреждена.

Все еще не знаю, как я мог бы отладить это. Очевидно, что где-то происходит ошибка памяти, но как я могу ее отслеживать в чистом управляемом коде, где модель памяти даже не отображается?

Answer 1

Это похоже на то, что ваш COM-интерфейс неправильно перенаправляет параметр/возвращаемую переменную, в результате чего управляемая память неожиданно освобождается GC или неуправляемой памятью, которая может быть повреждена из-за некорректного маршалинга. Вы можете получить более тонкий контроль над интерфейсом COM, созданным путем создания собственного Primary Interop Assembly для COM-компонента. С небольшим количеством работы вы можете проверить метод оскорбления на COM-объекте и убедиться, что все его параметры имеют правильные метаданные, чтобы убедиться, что они правильно настроены.

Теперь, возможно, вы правильно маршируете все, но вы не совсем правильно назовете интерфейс, проявляя себя как ненадлежащее использование параметра, который в конечном итоге уничтожает неуправляемую память. Это менее интересно отслеживать, особенно если у вас нет доступа к источнику COM.

Одна из трюков - разрешить программе выходить из строя вне вашего отладчика, нажмите «Отладка», в результате чего откроется окно JIT Debugger.Затем установите флажок «Выбрать механизм отладки» (или что-то в этом роде) и убедитесь, что отмечены флажки Managed и Native. Экземпляр VS, который появляется, должен быть разбит на фактический код, который умер, а не на ближайший управляемый код до смерти.