Есть, положим, WTL-программа. Ессно, под Win32, если кто в танке Так вот, по не вполне понятным причинам, она иногда наглухо виснет. Сам GUI-интерфейс. Можно ли как-то определить, а почему произошел взвис? Может, BoundsChecker? Может, аттач к процессу в отладчике и просмотр стека? Словом, поделитесь опытом
в качестве пробного средства я бы попробовал мониторить состояние потоков программы с пом. Process Explorer от sysinternals. Также целесообразно контроллировать активность цикла обработки сообщений каждого потока с пом. трассировки (ATLTRACE напр.)
Можно послать WM_QUIT чтобы проверить или ещё нажать Ctrl+Shift+Esc и посмотреть статус "Выполняется" или "Не отвечает", потом на закладку "Процессы" и понаблюдать (сперва Вид\Выбрать столбцы - Все), если вся загрузка ЦП значит висит в цикле, иначе свои такты отдала потоку другого процесса, посмотреть на счетчики изменения памяти, приаттачится отладчиком надо попробовать обязательно
Скорее нет, он не умеет аттачится к процессу, а запускать и ждать когда зависнет сам понимаешь, отладчик лучше, там запаузил и видишь где и что происходило
IHMO использование профайлера может помочь локализовать проблему (а может и не помочь), самое главное, что бы прога зависла в момент профилирования, а потом посмотреть где больше всего времени затрачено. Только, вероятнее всего, профайлер покажет куда-нибудь в ядро =)
CodeAnalyst вполне нормально определяет бесконечные циклы, а вот если есть deadlock из-за какой-нибудь EnterCriticalSection, тогда да - всё время будет потрачено в ядре и это мало что даст :-(
первый шаг в исправлении ошибки - добиться ее воспроизводства. если воспроизводить ошибку не получается, можно порекомендовать вести логи(кто, что и когда захватил/отпустил)
volodya там с хуками чето намудрено, я с год назад переписывал частично WTL на асм - глючков там хватает, себе по ходу и правил. Пробуй сообщения отключать по очереди для меню если сорцы проги есть, иначе в отладчике такое не ловится - олли всю машину рушил до синего экрана, если хуки есть в проге