В этой статье описано решение проблемы, из-за которой операционная система с включенным режимом отладки может зависать, если отладчик не подключен.
Применимо к: Windows Server 7 с пакетом обновления 1, Windows Server 2012 R2
Исходный номер базы знаний: 2816225
Симптомы
На компьютере под управлением Windows 7 или Windows Server 2008 R2 после установки средств отладки для Windows операционная система с включенным режимом отладки может зависнуть, если приложение создает исключение в пользовательском режиме.
Причина
Если режим отладки включен, а отладчик не подключен из-за исключения пользовательского режима, система зависает, ожидая, пока отладчик не отключит точку останова.
Решение
Чтобы устранить эту проблему, отключите режим отладки одним из следующих методов:
- Использование параметров конфигурации системы
- При нажатии клавиатуры windows Key+R открывает окно запуска .
- Введите MSCONFIG и нажмите клавишу ВВОД.
- Выберите вкладку » Загрузка», а затем выберите «Дополнительные параметры».
- Снимите флажок»Отладка «.
- Нажмите кнопку ОК.
- Нажмите кнопку » Применить» и нажмите кнопку «ОК».
- Перезагрузите компьютер.
- Использование интерфейса командной строки
- Откройте командную строку с повышенными привилегиями.
- Введите следующую команду и нажмите клавишу ВВОД:
bcdedit -debug off - Перезагрузите компьютер.
КАК ЗАКРЫТЬ ЗАВИСШУЮ ПРОГРАММУ
Дополнительные сведения
Windows не следует запускать в режиме отладки без возможности восстановления. Режим отладки включен для подключения к отладке ядра с помощью отладчиков, таких как средства отладки для Windows (WinDbg), и должен быть отключен после выполнения этой задачи.
Некоторые системы Windows 7 могут поставляться с включенным параметром DEBUG, обязательно отключите его.
Чтобы скачать средства отладки для Windows и дополнительные сведения, см. статью «Скачивание комплекта драйверов Windows (WDK)».
Обратная связь
Были ли сведения на этой странице полезными?
Источник: learn.microsoft.com
отладка зависающего приложения VS
В Unity зависает редактор. Если сбилдить программу(под вин), то она тоже зависает(no responding). Не могу найти причину: выполняю неопределенное количество раз одно и тоже действие и потом зависание. Поставить breakpoint не могу потому, что не ясно где их ставить. Мне кажется, что зависает где-то в скриптах юнити.
Как можно получить место в котором программа зависает? Можно ли посмотреть какой то журнал где выписаны все действия программы? Я думаю что где-то получается бесконечный цикл, хотя я все циклы проверил. Спасибо!
Отслеживать
70.5k 12 12 золотых знаков 87 87 серебряных знаков 179 179 бронзовых знаков
задан 22 дек 2016 в 16:30
Valera Kvip Valera Kvip
2,667 10 10 серебряных знаков 24 24 бронзовых знака
А MonoDevelop есть? Теоретически должно работать форсированный break. а-ля youtu.be/X8aw1n1ZJQo
22 дек 2016 в 18:11
Как закрыть зависшую программу или игру Windows 11 и Windows 10
22 дек 2016 в 19:49
по идее у студии тоже есть break all , который тоже должен останавливать в месте зависания. но чет не всё так просто видимо там. в итоге через моно схватилось? а то, что в блоге в первой ссылке написано не пробовали?
22 дек 2016 в 19:51
22 дек 2016 в 19:59
Всё. Теперь будет читабельно (я думаю). Специально перенес всё в ответ. Думаю это будет нужная и важная штука тут
23 дек 2016 в 9:46
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Есть минимум три решения (если есть другие — дайте знать): два быстрых и одно долгое. Причем долгое связанно именно с Visual Studio (почему у Microsoft не может быть всё просто?)
Наибыстрейшее (но материально затратное)
Нужно пойти в UnityAssetStore и найти ассет (asset) под названием Panic Button. Он находится в разделе Editor Extensions/System. На данный момент этот ассет находится вот здесь.
Что он делает? Когда приложение крутится в бесконечном цикле и интерфейс Unity висит, достаточно нажать клавиши Shift + Esc и происходит «обрыв» главного потока, интерфейс отвисает. При этом проигрывание ставится на паузу, а в консоли отображается проблемное место:
Как конкретно она работает? Что происходит внутри? Скорее всего то, что будет описано в пункте №3, только сделанное в виде скрипта, упакованного в dll (чтоб никто не видел код ), подключаемую к проекту.
Использовать MonoDevelop
- Пишем скрипт с бесконечным циклом, вешаем на объект и нажимаем Play 🙂
- Идем в MonoDevelop и нажимаем Run → Attach To Process
- В появившемся окне выбираем Unity и нажимаем Attach
- Нажимаем кнопку Pause в MonoDevelop
- Mono уже остановится в проблемном месте и высветится StackTrace
- Остается теперь поставить Breakpoint на строку, изменить значение, которое вводит в бесконечный цикл (в данном случае присвоить i значение 20, например) и нажать Continue Execution
- Вздохнуть с облегчением.
Использовать Visual Studio
-
Пишем скрипт с бесконечным циклом, вешаем на объект и нажимаем Play 🙂 Например скрипт такой:
using UnityEngine; public class Quicksand : MonoBehaviour < void OnMouseDown() < while(true) < // «Mind you, you’ll keep sinking forever!!», — My mom >> >
И через стэк попасть в место зависания. Анимация ниже должна полностью показать, как пробраться туда:
Из него практически видно бесконечный цикл. В реальности код может быть сложнее и будет трудно быстро разобрать, что там происходит, но сильно можно не вникать, ибо есть небольшой трюк (см. следующий шаг):
В итоге во вкладке Autos в Visual Studio должны появится данные значения: 
P.S. Способ с Visual Studio был позаимствован в блоге Unity. Там же можно прочитать, почему способ работает
Источник: ru.stackoverflow.com
Как отлаживать зависшее (тупиковое) многопоточное приложение на C ++?
В java отладка зависшего приложения очень проста. Вы можете взять дамп памяти приложения и использовать анализатор дампа jvm eclipse, чтобы увидеть состояние потоков и где каждый поток был заблокирован? Есть ли что-то подобное для C ++?
задан 01 окт.
Что в среде вы развиваете? (Visual Studio, GNU / Linux) — Steven
Было бы здорово, если бы вы могли говорить об обеих средах. Отладка — это весело и сложно в обеих средах. Поскольку в Windows ядра не устанавливаются автоматически, в Windows это сложнее. У людей могут быть другие мнения — pankajt
9 ответы
То же самое можно сделать и с C ++; принудительно создать дамп ядра и заглянуть в него после. Или, если вы используете MSVC, вы можете просто подключить отладчик к приложению во время его работы. Хит «сломать все» и ковыряться в нитях.
ответ дан 01 окт ’09, 21:10
могу ли я сказать, что ответ, который я дал, был более или менее правильным. MSVC предоставляет очень простой интерфейс для отладки приложений C ++. — панкайт
Магический вызов в gdb:
нить все применить bt
Это запускает команду bt (backtrace) для всех потоков. Если вы полностью не удалили свою программу, вы должны увидеть имена каждой функции. Это работает как для оперативной, так и для посмертной (т. Е. Запуска gdb на ядре) отладки.
ответ дан 02 окт ’09, 06:10
В собственных приложениях Windows я предпочитаю Windbg. Если возможно, я буду отлаживать заблокированный процесс в режиме реального времени, в противном случае полный дамп памяти процесса обычно приведет вас к этому. Мой подход — нарисовать график ожидания документирование отношений между потоками и ресурсами.
Обычно я начинаю с выполнения команды !замки чтобы определить, какие потоки содержат какие-либо критические разделы в заблокированном процессе. Затем я начинаю рисовать график ожидания, выбирая критический участок с наибольшим количеством конфликтов (если есть тупик, на графике будет цикл, поэтому на самом деле не имеет значения, с чего вы начнете).
Найдите поток-владелец и выберите его в отладчике ( ~ позволяет связать идентификаторы потоков с номерами потоков, используемыми отладчиком, используйте ~ *** номер резьбы *** s выбрать тему и КБН для отображения его стека. Если процесс зашел в тупик, то есть вероятность, что он будет выполнять какую-то операцию блокировки, например, искать вызовы RtlEnterCriticalSection или WaitForSingleObject и др.
В ситуации тупика эти вызовы обычно позволяют идентифицировать другой ресурс, которого ждут. Добавьте эту информацию в график ожидания и продолжайте, пока не вернетесь туда, откуда начали.
Если ваш график ожидания пересекает границы процесса, вы можете обнаружить, что вам нужно найти, кому принадлежит объект ядра в другом процессе (вот почему я отлаживаю в реальном времени, если могу). Для этого может пригодиться инструмент sysinternals Process Explorer.
После того, как вы определили участников тупиковой ситуации, вам нужно наложить свои мыслительные ограничения, чтобы понять, куда двигаться дальше. Это может означать изменение порядка получения ресурсов (как кто-то указал), но на самом деле нет общего метода, для которого потребуется дополнительная информация о дизайне приложения, чтобы понять, как удалить циклическую зависимость в графе ожидания. Существуют обстоятельства, при которых цикл может не быть причиной проблемы, например, ваша система может ожидать ввода пользователя, который никогда не поступит (подает руку любому, кто видел вызов MessageBox для процесса, запущенного как служба). Конечно, это еще не все, но я надеюсь, что это может направить вас в правильном направлении.
ответ дан 06 окт ’09, 15:10
Некоторые платформы поддерживают стек.
ответ дан 01 окт ’09, 21:10
pstack — определенно один из вариантов, я часто упускаю его. Спасибо за напоминание. 🙂 — панкайт
- Присоединитесь к запущенному процессу, который находится в состоянии зависания / взаимоблокировки, используя команду ниже gdb -p
- После того, как вы подключились к этому процессу, вы можете увидеть все LWP, используя команду ниже
(gdb) info threads
- Мы видим, что поток 1 и поток 8 находятся в состоянии ожидания, мы можем перейти к каждому из потоков, как показано ниже. (gdb) thread 1 (gdb) bt
Результат выполнения вышеуказанной команды будет таким:
(gdb) thread 1 [Switching to thread 1 (Thread 0xfff0a62000 (LWP 2744))] 0 0x000000fff0f19b9c in __lll_lock_wait_private () from /lib64/libc.so.6 (gdb) bt 0 0x000000fff0f19b9c in __lll_lock_wait_private () from /lib64/libc.so.6 1 0x000000fff0ea3238 in malloc () from /lib64/libc.so.6 2 0x000000fff115df0c in operator new(unsigned long) () from /lib64/libstdc++.so.6 3 0x000000fff11ceddc in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const, std::forward_iterator_tag) () from /lib64/libstdc++.so.6 5 0x000000fff11d1760 in std::basic_string::basic_string(char const*, std::allocator const) () from /usr/sbin/dir/sharedobj/libsockIf.so 16 0x000000fff207d5a4 in socketInterface::socket_callback(ConnectionEvent, char*, int) () from /usr/sbin/dir/sharedobj/libsockIf.so 17 0x000000fff208f43c in ifaceSocket::Callback(ConnectionEvent, char*, int) () from /usr/sbin/dir/sharedobj/libsockIf.so 18 0x000000fff20c4674 in ConnectionOS::ProcessReadEvent() () from /usr/sbin/dir/sharedobj/libconnV2.so 19 0x000000fff20cc808 in ConnectionOSManager::ProcessConns(fd_set*, fd_set*) () from /usr/sbin/dir/sharedobj/libconnV2.so 20 0x000000fff20cf3bc in SocketsManager::ProcessFds(bool) () from /usr/sbin/dir/sharedobj/libconnV2.so 21 0x000000fff1e54aa8 in EventReactorBase::IO() () from /usr/sbin/dir/sharedobj/libthreadlib.so 22 0x000000fff1e5406c in EventReactorBase::React() () from /usr/sbin/dir/sharedobj/libthreadlib.so 23 0x000000fff1e50508 in Task::Run() () from /usr/sbin/dir/sharedobj/libthreadlib.so 24 0x000000fff1e50584 in startTask(void*) () from /usr/sbin/dir/sharedobj/libthreadlib.so 25 0x00000000104a421c in TaskMgr::Start() () 26 0x00000000100ddddc in main ()
- Мы можем проверить структуру pthread_mutex_t и получить подробную информацию о владельце, которого этот поток ожидает ..
(gdb) info reg From r8 field get the very first address (gdb) print *((int*)(0x0000000019ff3d30)) $1 = 2 // Locks (gdb) print *((int*)(0x0000000019ff3d30)+1) $2 = 0 // Count (gdb) print *((int*)(0x0000000019ff3d30)+2) $3 = 2744 // Owner PID
Источник: stackovergo.com