Тип зависания cross thread explorer

Обновлено: 03.07.2024

Почему зависает explorer exe? Есть множество причин, от повреждения системных файлов, до наличия вредоносных программ и вирусов.

Как часто мы сталкиваемся с такой проблемой: открываем папку и тут, на несколько секунд все зависает, а потом и вовсе исчезает. Остается только заставка рабочего стола.

Проблема известна всем пользователям windows. Такое может наблюдаться при копировании файлов, попытке запустить видео.По сути это может появиться где угодно, а связанно это с ошибками работы процесса
Explorer.exe. Не нужно вспоминать браузер IE, тут речь пойдет не об этом.

Для тех, кто не очень осведомлен Explorer.exe – это процесс, отвечающий за все визуальное оформление нашей рабочей среды, хотя это очень упрощенное описание.

В этой статье я постараюсь пролить свет на наиболее частые ошибки этого процесса, которые и вызывают зависание системы.

Если компьютер работал стабильно, но в один ужасный день пошла такая пьянка с зависанием и с пропаданием меню «Пуск» это первый признак того, что что-то нарушает работоспособность процесса Explorer.exe

Причин этому может быть множество, но самые вероятные из них следующие:

1. Вирусы
2. Новая установленная программа
3. Повреждение файла Explorer.exe

Для начала необходимо просканировать всю систему на наличие вирусов при помощи антивирусных программ.
Я советую вам воспользоваться бесплатной программой, не требующей установки,
Но буте внимательны, если у вас установлен Dr.Web, Вам нужен другой антивирус для этого сканирования. (Нод, Касперский одним словом любой, кроме Dr.Web).
Так же можно воспользоваться замечательной программой для удаления SpyWare и троянских программ AVZ.
Наверняка на компьютере Вы нашли и удалили несколько вирусов. Но с этим вряд ли кончились беды.
Скорее всего, вирус (если сбой произошел по его вине) уже повредил файл Explorer.exe. В этом случае необходимо выполнить восстановления файла Explorer.exe

Восстанавливаем работу файла Explorer.exe.

Внимание! Это действие лучше выполнять из безопасного режима (перед загрузкой операционной системы жмем клавишу F8 и выбираем соответствующий режим).

4. Открываем командную строку (Пуск далее выполнить, и в открывшемся окне вводим cmd и нажимаем ввод), далее вводим sfc /scannow (необходимо вставить диск, с которого была установлена система)

Если вирусов в системе не обнаружено или файл Explorer.exe не поврежден, то вспоминайте, какие программы Вы в последнее время устанавливали.

Ошибка Explorer.exe бывает, возникает именно из-за некоторых программ, установленных на компьютере.
Поэтому, попробуйте удалить программу, из-за которой данная ошибка могла возникнуть или выполните восстановление Windows.

Отключаем создание эскизов (файлов thumbs.db)

Но иногда даже этих действий не хватает для исправления ошибки проводника.

Был у меня случай, когда вроде бы уже все было перепробовано, вирусы отловлены, все лишние программы удалены, а не помогло.

А собака оказалась зарыта совсем в другом месте.
Вирус какой-то прогрыз файл кодеков для видео и все проблемы с вылетом Explorer.exe при открытии папки с любым клипом, решились простой переустановкой кодеков.

Вот так бывает, так что перед радикальными мерами, такими как переустановка windows, обязательно попробуйте все другие методы.

При работе с операционной системой Windows случается ситуация, когда программа (процесс) зависает, другими словами просто перестает отвечать на запросы системы (и, соответственно, пользователя). Если программа имеет графический интерфейс, то в заголовке основного окна к имени программы добавляется статус "не отвечает", и сам интерфейс при этом зачастую перестает реагировать на какие-либо запросы оператора и визуально как бы вуалируется (затеняется).

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

Почему приложения виснут? В общем случае основания для подвисания могут быть разные: как внутренние, так и внешние. К внутренним относятся ошибки в коде самого приложения, к внешним же принадлежат события, случающиеся в других процессах, от которых может каким-либо образом зависеть работоспособность нашего приложения. Для выявления подобных зависимостей разработчики предложили нам (начиная с Windows Vista) механизм под названием Обход Цепочки ожидания (Wait Chain Traversal (WCT)), который при помощи специализированных функций позволяет выявлять взаимоблокировки процессов, работающих в системе. В данной статье мы будем рассматривать инструментарий анализа цепочки ожидания зависшего приложения. В качестве подобного инструментария мы будем использовать одно из системных средств, которое носит название Монитор ресурсов .

Монитор ресурсов - системное приложение, являющееся надстройкой монитора производительности, которое отображает информацию об использовании аппаратных (процессор, память, диск, сеть) и программных (файловые дескрипторы, модули) ресурсов системы в реальном времени.

Стоит отметить, что функционал монитора вовсе не ограничивается опциями диагностики подвисших приложений, а основным его предназначением, как раз таки является наблюдение за использованием системных ресурсов, измерение производительности системы. Но в данной заметке мы сосредоточимся на мониторе ресурсов с точки зрения использования функционала для выяснения причины зависания приложений. Дело в том, что в мониторе ресурсов как раз и реализован упоминаемый выше механизм для анализа цепочки ожидания зависшего приложения.

Запуск монитора ресурсов

Все действия данного раздела следует производить из-под учетной записи с правами локального администратора.

Для начала, Монитор ресурсов все же следует запустить :), и сделать это можно несколькими способами. Можно запустить его через панель "Выполнить", которая вызывается нажатием комбинации клавиш Win + R или через строку поиска, затем ввести команду "resmon".

Можно при помощи комбинации Ctrl + Shift + Esc вызвать Диспетчера задач , перейти на вкладку "Быстродействие" и нажать кнопку "Монитор ресурсов".

Анализ цепочки ожидания

Сразу после запуска откроется главное окно монитора ресурсов. Нам необходимо перейти к списку запущенных на данный момент в системе процессов, и сделать это можно несколькими способами, можно активировать вкладку "Обзор", затем раскрыть область "ЦП", а можно сразу перейти на вкладку "ЦП" и развернуть область "Процессы". После развертывания интересующей нас области, мы увидим список исполняющихся в данный момент в системе процессов. Как видно на скриншоте ниже, зачастую монитор ресурсов маркирует зависшие программы (процессы) красным цветом, хотя данное правило действует не всегда. Если нажать на зависшем процессе (в нашем случае это Outlook.exe) правую кнопку мыши, то взору нашему предстанет контекстное меню:

В котором помимо основных методов работы с процессом имеется пункт "Анализ цепочки ожидания". После выбора данного пункта меню откроется отдельное диалоговое окно под названием "Анализ цепочки ожидания", в котором в древовидной форме будут перечислены процессы, окончание потоков которых ждет наше зависшее приложение.

Если внимательно проанализировать цепочки ожидания (на скриншоте, приведенном выше) и сопоставить их друг с другом, то можно сделать вывод, что в нашем случае Outlook блокирует поток 4648 процесса с идентификатором 8160 и именем iexplore.exe , который, на поверку, оказывается ни чем иным как интегрированным в систему браузером Internet Explorer. Почему у нас появилась зависимость от Internet Explorer, на данный момент понять сложно, поскольку детали инцидента давно утеряны, однако могу сделать предположение, что в почтовом клиенте Outlook было открыто какое-либо вложение, требующее функционала IE (возможно ссылающееся на внешний URL). Теперь перед нами стоит задача разблокировать подвисшее приложение (Outlook) с минимальными потерями, в идеале хотелось бы продолжить функционирование в штатном режиме без повреждения рабочих данных. Для достижения данной цели можно поступить достаточно грубо и попросту завершить блокирующий процесс iexplore.exe . Для этого, активируем чекбокс напротив записи iexplore.exe (PID: 8160) поток 4648 и нажмем кнопку Завершить процесс .

При завершении блокирующих процессов будьте предельно осторожными!! Вы должны четко представлять себе назначение тех процессов, которые Вы намерены завершить, не являются ли они критическими для операционной системы, в противном случае поведение системы прогнозировать сложно.

Есть и другой, менее разрушительный способ избавления от блокировки. Можно попробовать изучив проблему глубже, проанализировав все нисходящие цепочки ожидания процесса. Сначала выясняем, кто блокирует (iexplore.exe), потом спускаемся далее к виновному процессу и изучаем его цепочку ожидания и так далее. У нас появляется шанс, что следуя таким образом вниз по дереву блокировок, нам, в конечном итоге, удастся выйти на первопричину. Но вот разблокируются ли в этом случае все процессы вверх по цепочке, точно спрогнозировать нельзя. Но, вернемся к нашей проблеме.
После снятия блокирующих процессов, заблокированное приложение может не отвиснуть. Дело в том, что причиной блокировок могут являться не только внешние процессы, но и системные ресурсы, например программа может постоянно пытаться сохранить данные в файл, который в данный момент блокируется другим источником. Дописать: ЦП - раздел "Связанные дескрипторы".

Начиная с Windows 8, функция "анализ цепочки ожидания" включена в состав диспетчера задач Windows. Основываясь на практических наблюдениях, могу с уверенностью утверждать, что далеко не во всех случаях монитору ресурсов удается построить цепочку ожидания зависшего приложения, иногда она оказывается пуста. Объясняется это тем фактом, что не все зависания зависят от внешних, по отношению к зависшему приложению, событий. Например, поток может зависнуть по своим внутренним причинам: кривой код на бесконечном программном цикле какой-либо внутренней функции, такой как цикл for с неправильным условием, sleep() , delay() и аналогичные функции.

Выводы

С появлением технологии обхода цепочки ожидания, в арсенале технического специалиста появился довольно действенный метод определения причин блокировок зависшего приложения и разблокировки подвисших процессов. Конечно, по уму, при изучении инцидента стоило бы проанализировать более детально, какие именно функции потоков блокируют исполнение и чего именно они ждут, но это уже совершенно другой уровень и мы не ставили себе подобной цели при написании данной статьи. Тем не менее, теперь мы вооружены еще одним, достаточно простым, понятным и быстрым способом разблокировки зависшего (не отвечающего) процесса. Сам по себе способ не требует наличия углубленных технических знаний, а так же специализированных сторонних инструментов и опирается на штатное средство под названием монитор ресурсов (Resource Monitor, resmon), что является ощутимым преимуществом. Резюмируя, можно сказать, что использование функции "анализ цепочки ожидания" зависшего приложения достаточно эффективный способ устранения причины зависания процесса.

. when altering one's mind becomes as easy as programming a computer, what does it mean to be human.

8 июня 2010 г.

Как узнать, почему зависла программа?

Сегодняшняя статья будет посвящена нескольким подходам к отладке зависаний программы.

Состоит она из шести частей:
- Подготовка - общие действия для всех случаев отладки.
- Delphi - отладка зависания в Delphi.
- EurekaLog - поиск причины зависания в EurekaLog.
- Process Explorer - поиск причины зависания утилитой Process Explorer.
- Threads Snapshot - поиск причины зависания утилитой Threads Snapshot.
- Практический пример - пример с искусственным зависанием в программе.

Ну, прежде чем приступать к отладке программы, вам надо бы её пересобрать (делайте Build, а не просто Compile), добавив в неё отладочную информацию. Для разных подходов требуется разные форматы отладочной информации, поэтому лучше включить всё сразу, чтобы не думать :) Это необходимо сделать, чтобы отладочные средства могли показывать вам читабельные названия процедур и номера строк в исходниках. В противном случае, вам придётся иметь дело с машинным кодом и смещениями.

Итак, вам нужно включить (Project/Options/Linking): "MAP file" - Detailed, "Debug Information" (в старых версиях Delphi она называлась "Include TD32 debug info") - True, "Include remote debug symbols" - True:

Кроме отладочной информации, полезно включить опции "Stack Frames" и "Use Debug DCUs" на вкладке "Compiling":

Уж позвольте мне не повторяться, что делают эти опции.

Не забываем сделать Build после изменения опций. Понятно, что если у вас несколько проектов (DLL, BPL и т.п.), то менять опции и пересобирать надо все. Также, если вы используете сборку с run-time пакетами - по возможности, выключите их на время тестирования, ибо пакеты сильно всё усложняют.

Вы можете подумать: "но я не могу воспроизвести это под отладчиком!" или "на проблемной машине у меня не стоит Delphi!". Но не спешите переходить к следующему разделу.

Во-первых, вам необязательно запускать программу в Delphi. Вы можете запустить программу как обычно, вне среды, и работать с ней, пока она не зависнет - после чего подключить к ней отладчик. Во-вторых, если на машине не стоит Delphi - вы можете установить на неё удалённый отладчик. Подробнее об удалённом отладчике - см. справку или мою статью (большой объём, вот вариант в PDF) - раздел 2, в конце секции 2.1.1. про работу с отладчиком.

Для отладки зависшего проекта в Delphi его, конечно же, нужно открыть. Предварительно он должен быть скомпилирован - с установленными опциями отладки, как мы сделали выше. Кроме того, для локальной машины желательно, чтобы вы запускали программу из Output path, указанном в опциях проекта (т.е. не перемещали бы скомпилированный exe перед запуском).

Итак, вы запустили свою программу, она сколько-то там поработала и зависла. Открываем Delphi, загружаем нужный проект и делаем Run/Attach to process:

Из списка выбираем вашу программу (введя при необходимости имя удалённой машины, если Delphi и программа находятся на разных машинах), устанавливаем галочку "Pause after attach" и жмём "Attach".

Отладчик подключится к процессу и установит его на паузу - путём возбуждения точки останова в потоке отладчика:

Вы можете игнорировать поток отладчика - просто перейдите на окно Threads и выберите любой свой поток для его отладки. Вы можете просмотреть стек вызовов, переключаться между потоками, анализировать переменные, делать пошаговое выполнение и т.п. - в общем, пользоваться отладчиком Delphi как обычно. Если вы включали отладочную информацию, то вы можете закрыть окно CPU и пользоваться отладкой по исходному тексту.

Напомню, что при возможности отладку зависаний стоит производить в ОС Vista и выше - потому что в этих системах появилась новая возможность для отладчиком: Wait Chain Traversal. Отладчик Delphi последних версий поддерживает WCT. Поэтому, если вы используете BDS 2009 или выше и Windows Vista или выше, то в окне Threads напротив каждого потока в колонке "Wait Chain" можно увидеть его статус, чего он ждёт, есть ли взаимоблокировка и т.п.:

В EurekaLog есть фишка "Anti-Freeze". Собственно, её я уже разбирал в отдельной статье, поэтому не буду останавливаться сейчас - у нас и так сегодня куча материала.

Если же по каким-то причинам среда Delphi для вас недоступна - вам придётся производить отладку руками.

Перед тем, как производить отладку, надо подготовить Process Explorer. Здесь будет два шага - оба опциональных, но для максимального удобства лучше сделать оба.

Шаг первый - настроить Process Explorer на загрузку отладочных символов. Дело в том, что Windows поставляется с обычными исполняемыми модулями без отладочной информации. Для своих программ мы только что включили генерацию отладочной информации (см. первый пункт), то как мы можем сделать это для Windows, чьи исходники нам недоступны? Ну, Microsoft позаботилась об этом: она распространяет отладочную информацию для своих программ отдельно. Вы можете скачать её и получить читабельные стеки вызовов.

Для начала вам понадобится скачать и установить Windows Debugging Tools. Затем, вам нужно решить, качать ли всю отладочную информацию скопом или же пусть она качается по запросу отладочной программы. Если вы выбрали первый путь - то вперёд, качаем и устанавливаем. Лично я выбираю второй путь.

Для второго способа вам нужно создать папку на своей машине с правом чтения-записи файлов и папок в ней. После чего остаётся только настроить Process Explorer:

В первом поле указывается путь к DbgHelp.dll - если вы устанавливали Windows Debugging Tools, то берите библиотеку оттуда. Если нет - то берите C:\Windows\System32\dbghelp.dll (однако я не уверен, будет ли это работать).

После того, как вы это настроили, Process Explorer будет пытаться получить отладочную информацию о каждом необходимом файле и кэшировать её в указанной папке. Поэтому, когда вы просматриваете потоки процесса или их стек вызовов, вы можете иногда видеть надпись "Loading symbols for ABC.exe+0xXYZ. ". В общем, после этого вам станет доступно больше информации для системных модулей.

Второй момент, который нужно сделать - сконвертировать map-файл вашего проекта в формат, понимаемый Process Explorer. Дело в том, что Delphi создаёт только различные Borland-ские форматы отладочной информации, а Process Explorer, как утилита Microsoft, понимает только Microsoft-ские форматы отладочной информации. Я уже говорил об этом. Сделать это можно утилитой map2dbg. Это простая консольная утилитка. Качаете архив, распаковываете, открываете консоль и пишете:

По файлам Project1.exe и Project1.map утилита сделает вам файл Project1.dbg, который может быть использован в Microsoft-ских утилитах.

Что-ж, я тут много чего сказал. Давайте я продемонстрирую, что вы получаете, выполнив указанные выше вещи. Ниже - три скриншота. Слева направо: вид стека вызовов без выполнения обоих пунктов (т.е. без системной и без проектной отладочной информацией), вид стека вызовов с первым пунктом (с системной, но без проектной отладочной информацией) и вид стека вызовов с обоими пунктами (с системной и с проектной отладочной информацией):

Как видите, подключение отладочной информации даёт вам три вещи:

- Более читабельный стек вызовов (вместо имя-модуля+смещение вы получаете имя-модуля!процедура+смещение)
- Более полный стек вызовов (без отладочной информации эвристика трассировки стека может опускать вызовы)
- Более правдивый стек вызовов (анализатор может неверно определять имя функции, если идёт вызов внутренней функции, которая не имеет публичного имени, но рядом находится другая функция, которая как-раз таки имеет публичное имя - поэтому анализатор может посчитать внутреннюю функцию частью публичной)

Если вы не будете (или не сможете) подключать отладочную информацию - вам придётся работать со смещениями. Вы конечно, можете искать смещения в map-файле руками, но это весьма хлопотно. Гораздо проще просто выписать на бумажку все числа, приписав имя модуля. Затем запускаете проект у себя, ставите его на паузу и используете команду Search/Goto address. Вводите адрес - и Delphi переводит вас на строчку в исходном тексте, а если это невозможно - то открывает окно CPU. Какой вводить адрес? Два примера. Вы выписали Project1.exe + $1234 и Project2.dll + $4321. Базовый адрес exe обычно не меняется и равен $400000. Вы загрузили проект у себя. Базовый адрес exe тот-же - $400000, а вот DLL оказалась загруженной по адресу $50000000 (вы можете выяснить это в окне Modules: View/Debug Windows/Modules). Тогда вас интересуют адреса $400000 + $1234 = $401234 и $50000000 + $4321 = $50004321.

Фух, разобрались. Как видите, намного удобнее подключать отладочную информацию, чем работать без неё :)

Теперь, что вы собственно должны делать для отладки зависания. Ну, вы запускаете свою программу и работаете с ней, пока она не зависнет. Потом вы запускаете Process Explorer, выбираете в списке процессов свою программу, правый щелчок -> Properties (свойства). В свойствах процесса переходим на вкладку Threads (потоки):

Здесь вы можете посмотреть, чем занимаются потоки вашей программы. Кто кушает процессор, кто чего-то ждёт и т.п. Выберите поток и нажмите кнопку "Stack" для просмотра его стека вызова (пример окна - см. три скриншота чуть выше).

Конечно, вы не сможете посмотреть переменные или что-то такое - только состояние и точки выполнения потоков. Так что вам придётся использовать свои телепатические способности, чтобы определить причину зависания.

Ну, использование Process Explorer хотя и несложно, но не выглядит таковым. Для новичка тут много работы и новых понятий. Да и вся эта возня с отладочной информацией не слишком удобна. Поэтому я написал простую утилитку (сейчас - часть EurekaLog Tools), которая позволяет вам выбрать запущенный процесс и дампит в текстовый файл информацию по всем потокам, включая:

- Базовая инфа: ID, приоритет и т.п.
- Стек вызова. Используются следующие источники отладочной информации: Borland-ские, JCL, EurekaLog и madExcept. Чуть позже добавлю поддержку Microsoft-ских и закачку по запросу, как у Process Explorer.
- Информация от Wait Chain Traversal (на Windows Vista и выше).
- Контекст потока - регистры и флаги.

Собственно, вы запускаете свою проблемную программу и работаете в ней, пока она не зависнет. Потом запускаете утилиту Threads snapshot и тыркаете её на зависший процесс. Она снимет вам снимок потоков, который вы сможете проанализировать.

Как видите - достаточно простая и удобная альтернатива ручной отладке с Process Explorer. Дополнительный плюс - вы можете попросить вашего клиента снять вам снимок процесса на его машине. В случае же с Process Explorer-ом - навряд ли вы сможете объяснить клиенту, что куда ставить и где жать. Не забудьте только передать все необходимые файлы (map-файлы, например).

Я написал эту утилиту буквально только что за два дня. Поэтому она "немножко" сыровата. Нормальная и отлаженная версия этой утилиты должна войти в EurekaLog v7.

Я написал простую программу с двумя кнопками. Вы можете использовать её как обучающий пример. Первая кнопка создаёт несколько потоков, которые ждут друг друга. Вторая кнопка вызывает порчу памяти, приводящую к зависанию. Запустите программу, нажмите на кнопку и попробуйте выяснить причину зависания. Посмотрим, как мы сможем отладить эти два случая.

В Delphi: если у вас есть поддержка WCT, то отладка первой кнопки вообще не представляет сложностей: запустили, нажали, поставили программу на паузу и смотрим окно Threads:

Если же WCT у вас нет, то придётся поработать головой и руками. Вы должны проанализировать стеки вызова каждого потока: щёлкаете по потокам в окне "Threads" и смотрите стеки вызовов:

После переключения на поток открывается окно CPU с текущей выполняемой инструкцией, но вы можете щёлкать по строчкам в окне "Call stack", чтобы посмотреть исходный код.

Проанализировав стеки вызовов всех трёх потоков, вы составите картину произошедшего.

Как эта же ситуация выглядит в Process Explorer и Threads snapshot? Ну, вы запускаете Process Explorer и смотрите стеки потоков (у меня первый поток открывался около минуты, не знаю, с чем связано - потом пошло гладко):

Хотя вы не видите здесь номеров строк, но вы видите имена функций и последовательность вызовов - например, в примере выше обратите внимание на Thread1Func, различные dispatch-функции, CriticalSection.Aquire и т.п. И снова: вы смотрите стеки вызова всех потоков и реконструируете ситуацию. Сделать это будет сложнее, чем используя Delphi (ибо нет номеров строк), но с известной долей телепатии - вполне возможно.

Что касается Threads snapshot, то она даёт такой лог (я отрезал лишние части для уменьшения лога):

К сожалению, вывод WCT пока не очень форматирован (это моё домашнее задание! :) ), но цепочку ожиданий увидеть можно. Плюс стеки потоков (к сожалению, без системной отладочной информации - это моё второе домашнее задание!) самым решительным образом намекают на происходящее.

Второй случай сложнее. Потому что зависание -лишь внешнее проявление другой проблемы.

Итак, в Delphi вы запускаете программу, она виснет, мы ставим её на паузу. У нас только один поток, поэтому WCT нам не помощник, даже если он есть. Поэтому сразу переключаемся на главный поток и смотрим стек вызовов:

Опять-таки: щёлкая по стеку вызовов, мы видим исходный код.

В этот раз, простой анализ стека вызовов нам не помогает. Пока что неясно, что же случилось. Тем более, что программа вроде бы не висит, а что-то делает (т.е., строго говоря, у нас не зависание, а зацикливание). Поэтому мы начинаем пошаговый прогон программы. Пройдясь по коду мы видим, что код постоянно крутит цикл со Sleep, проверяя некий флаг. Мы видим, что этот код - код менеджера памяти FastMM. Почитав комментарии в коде, мы узнаём, что FastMM пытается получить блокировку. А проверяемый флаг - это признак занят/свободен. Поскольку FastMM проверяет этот флаг уже полчаса - ясно, что тут что-то не так. Этот же вывод следует из того, что в нашёй программе всего один поток - т.е. ждать-то и вовсе некого, кроме нас в программе никого нет. Иными словами, состояние флага не соответствует действительности - т.е. он испорчен вследствие повреждения памяти.

К сожалению, найти повреждение памяти не так-то просто и это отдельная тема, которую я недавно закончил обсуждать.

Поэтому, задача анализа зависания - выяснить причину. Мы её нашли: это - повреждение памяти. Дальше, анализ зависания закончен, но проблема пока не найдена и не устранена - мы переходим к анализу и поиску проблем с памятью.

Собственно, второй случай выглядит примерно аналогично везде (в Delphi, Process Exporer и Threads snapshot): мы получаем примерно один и тот же стек вызовов, который может меняться время от времени, но всегда это будет цикл и с вероятностью в 99% - стоять на Sleep. Делается просто несколько проверок, чтобы в этом убедиться. Для примера - вот как это выглядит в Process Explorer:

Напомню, что из этого мы вынесем только вывод (не однозначный, конечно же, а всего лишь обоснованное предположение), что у нас есть повреждение памяти. Дальше - это уже другая история.

Фух. На сегодня у меня всё. Надеюсь, этот материал был полезен. Если хотите, вот ещё дополнение - презентация по ручному поиску места ошибки по адресу (см. "How to find the exception source line"). На английском, но может пригодится или будет интересно.

За 6 часов игры может выкинуть раз 7. Стало вылетать после последнего обновления клиента. В прошлом обновлении все было отлично. Остальные игры без проблем.

Карта RX480. Драйвера последние. Пробовал ВСЕ версии драйверов осле выхода этой карты, дабы исключить проблему драйверов. Винда 7 64 бита.

Описание:
Ошибка привела к остановке взаимодействия программы с Windows.

Сигнатура проблемы:
Имя события проблемы: AppHangB1
Имя приложения: WorldOfTanks.exe
Версия приложения: 0.9.17.50
Отметка времени приложения: 585a5c2b
Сигнатура зависания: 4fc0
Тип зависания: 2048
Версия ОС: 6.1.7601.2.1.0.256.1
Код языка: 1049
Доп. сигнатура зависания 1: 4fc08e832b1cc773dae09dac259714da
Доп. сигнатура зависания 2: 2059
Доп. сигнатура зависания 3: 205906576aa1f163cd51e50b6857cf1e
Доп. сигнатура зависания 4: 4fc0
Доп. сигнатура зависания 5: 4fc08e832b1cc773dae09dac259714da
Доп. сигнатура зависания 6: 2059
Доп. сигнатура зависания 7: 205906576aa1f163cd51e50b6857cf1e

Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
C:\Windows\system32\ru-RU\erofflps.txt

Прикрепленные файлы

Прикольно. У меня бывают дисконнекты, при чем с моим тырнетом не связанные. Вчера вон в начале боя выбило, проверяют тырнет - все ок, пинги ходят. Минуты через 2 пустило обратно, но уже поздняк, труп))

Описание:
Ошибка привела к остановке взаимодействия программы с Windows.

Сигнатура проблемы:
Имя события проблемы: AppHangB1
Имя приложения: WorldOfTanks.exe.

А где вы описание ошибки нашли? А как выкидывает? Просто клиент закрывается? У меня вот закрывается и после перезахода отключается чат и команды.

Его в могилу провожал насмешек шквал,
Иные хохотали просто бешено.
И только я, лишь я один рыдал.
Я так мечтал узреть его повешенным . © Хилэр Беллок

Приложение перестает отвечать. При закрытии через диспетчер задач нажмите просмотреть дополнительные параметры - там есть описание ошибки. Клиент не закрывается, а перестает отвечать

Описание:
Ошибка привела к остановке взаимодействия программы с Windows.

1. Проверьте, есть ли подобная проблема в безопасном режиме игры. Если проблемы не будет, то причина в модификациях клиента игры.

Читайте также: