Clr.dll! LogHelp_TerminateOnAssert в процессе .NET 4.0

Фон: Я работаю над настольным приложением .NET 4.0 на базе WinForm, которое имеет несколько потоков и таймеров и использует некоторую обработку GDI для пользовательских элементов управления. Во время моего развития я обычно заглядываю в sysinternal Process Explorer, чтобы убедиться, что в моем приложении нет ничего необычного, такого как количество дескрипторов GDI или пользовательских объектов и т.д.

Проблема: При использовании Process Explorer я обнаружил, что вкладка "Темы" для моего свойства приложения в Process Explorer показывает множество и множество записей "clr.dll! LogHelp_TerminateOnAssert + 0x58f68". Это нормально? Я думаю, что это не потому, что не в других приложениях .net(которые я написал в прошлом) показывает одну и ту же запись в своих свойствах в Process Explorer.

Что такое LogHelp_TerminateOnAssert()? (Я считаю, что это функция в clr.dll)

Почему LogHelp_TerminateOnAssert() вызывается так много раз?

Любые указатели будут очень полезны.

Спасибо заранее.

Ответы

Ответ 1

clr.dll! LogHelp_TerminateOnAssert + 0x58f68

Большое число (+ 58f68) указывает, что фактический метод в clr.dll находится далеко от LogHelp_TerminateOnAssert(). Вероятно, вы должны исправить символы и повторить попытку, чтобы получить правильный стек вызовов. Затем вы можете узнать, что такое настоящий метод.

Это не LogHelp_TerminateOnAssert(), поэтому бесполезно узнать, что делает LogHelp_TerminateOnAssert().

Чтобы исправить символы: в Process Explorer перейдите к Options/Configure Symbols, затем введите

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

где c:\symbols - это путь, в котором вы хотите сохранить загруженные файлы.

Ответ 2

Вы упоминаете использование потоков - поскольку каждый поток получает свой собственный стек, может быть, что размер стека по умолчанию в какой-то момент превышается, что вызывает исключение, которое затем захватывается средой выполнения .NET. Какую работу вы делаете в потоках (рекурсия, множество переменных стека и т.д.)?

Я полагаю, что размер стека потоков по умолчанию установлен в 1 МБ - попробуйте установить размер стека в 4 МБ в конструкторе потока и посмотреть, сохраняется ли ошибка.