Dumpstack log tmp что это за файл и как его удалить windows 10

Обновлено: 21.11.2024

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

Можно ли удалить системный файл swapfile в Windows 10?

Но вы можете удалить этот файл, если хотите. … Снимите флажок «Автоматически управлять размером файла подкачки для всех дисков», выберите диск, выберите «Без файла подкачки» и нажмите «Установить». Оба файла подкачки. sys и файл подкачки. sys будут удалены с этого диска после перезагрузки компьютера.

Что такое swapfile sys и можно ли его удалить?

sys и можно ли его удалить? Похоже на файл подкачки. sys, файл подкачки. sys — это функция Windows 10, которая использует пространство на жестком диске, когда ваша оперативная память либо заполняется, либо может использоваться более эффективно.

Безопасно ли удалять системный файл подкачки в Windows 10?

Если вы не измените его, файл подкачки Windows 10 останется на жестком диске даже после завершения работы. В этом практическом руководстве показано, как настроить файл реестра Windows 10, чтобы принудительно удалить файл подкачки. sys при каждом выключении компьютера, что устраняет все потенциальные уязвимости в системе безопасности.

Безопасно ли удалять файл подкачки?

Вы не можете удалить файл подкачки. sudo rm не удаляет файл. Он «удаляет» запись каталога. В терминологии Unix это «разъединяет» файл.

Должен ли я отключить подкачку Windows 10?

Отключив подкачку, вы также предотвратите выполнение алгоритмами памяти ненужных операций — перемещение данных из ОЗУ в подкачку и наоборот — в случае SSD это предотвратит чрезмерный износ. И в любом случае это повысит производительность за счет исключения лишних операций.

Что такое TMP журнала Dumpstack?

журнал. температура Все это уже было представлено Microsoft в Windows 8. Файл используется, когда Windows должна записать дамп. Это скрытый системный файл в корневом каталоге C: диска Windows (см. также объяснение в этой ветке форума MS Answers).

Безопасно ли удалять Hiberfil SYS Windows 10?

Хотя hiberfil. sys — это скрытый и защищенный системный файл, вы можете смело удалить его, если не хотите использовать параметры энергосбережения в Windows. Это связано с тем, что файл гибернации не влияет на общие функции операционной системы.

Безопасно ли удалять Hiberfil SYS?

Итак, безопасно ли удалять файл hiberfil. система? Если вы не используете функцию гибернации, то удалить ее совершенно безопасно, хотя это не так просто, как перетащить ее в корзину. Тем, кто использует режим гибернации, придется оставить его на месте, так как для этой функции требуется файл для хранения информации.

Можно ли удалить файл подкачки sys?

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

Почему файл подкачки такой большой в Windows 10?

Нажмите на вкладку "Дополнительно". В окне «Параметры производительности» перейдите на вкладку «Дополнительно». В поле «Виртуальная память» нажмите «Изменить…». Затем снимите флажок «Автоматически управлять размером файла подкачки для всех дисков», затем нажмите кнопку «Нестандартный размер».

Какой оптимальный размер файла подкачки для Windows 10?

В большинстве систем Windows 10 с 8 ГБ ОЗУ и более операционная система хорошо управляет размером файла подкачки. Размер файла подкачки обычно составляет 1,25 ГБ в системах с 8 ГБ, 2,5 ГБ в системах с 16 ГБ и 5 ГБ в системах с 32 ГБ. Для систем с большим объемом оперативной памяти файл подкачки можно уменьшить.

Можно ли удалить старую Windows?

Через десять дней после обновления до Windows 10 ваша предыдущая версия Windows будет автоматически удалена с вашего ПК. Однако если вам нужно освободить место на диске и вы уверены, что ваши файлы и настройки находятся там, где вы хотите, чтобы они были в Windows 10, вы можете безопасно удалить их самостоятельно.

Ранее в этом году я создал задачу для конференции Source Boston 2013, основанную на методе захвата фильтра дампа, описанном на этом веб-сайте. Задача заключалась в серии исправлений файлов, которые пользователь должен был косвенно принудительно применить, изменив файл журнала стека дампа. Исходный код драйвера фильтра аварийного дампа, используемого в этом задании, размещен в коде Google. Вы также можете загрузить копии файлов дампа, созданных после выполнения ключевых шагов (дамп после этапа 1 и дамп после этапа 3 — переименуйте «.key» в «.dmp»).

Конечная цель состоит в том, чтобы пользователь заставил драйвер фильтра аварийного дампа считать ключ CTF с диска, используя путь ввода-вывода аварийного дампа. Как указано в методе захвата фильтра дампа, это принуждение возможно путем манипулирования содержимым недокументированного файла DumpStack.log.tmp, который предоставляется пользователю драйвером фильтра дампа задачи (замаскированным под storport_lsi.sys). В рамках решения проблемы эта манипуляция заставляет драйвер фильтра дампа использовать внутренние функции регистрации в файле crashdmp.sys для чтения и записи произвольных участков на диске (через путь ввода-вывода аварийного дампа).

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

  1. Объясните пользователям, как работает стек аварийного дампа.
  2. Покажите, что путь сбоя представляет собой совершенно другой путь к диску, чем обычная работа системы.
  3. Продемонстрируйте, что путь сбоя можно использовать вне обычного механизма сбоя.

Участникам была предоставлена ​​виртуальная машина с предустановленной Windows 8 x86 Professional с использованием лицензии BizSpark, предоставленной конференцией.

Система загрузит storport_lsi.sys, драйвер фильтра аварийного дампа, который обрабатывает все аспекты задачи во время выполнения. Он также проверяет систему на наличие ошибок каждые 4 минуты. Этот файл называется «storport_lsi», чтобы он не вызывал подозрений. Название происходит от «storport.sys», одного из трех драйверов порта хранилища, предоставляемых Microsoft, и «LSI_SAS.sys», популярного драйвера мини-порта хранилища, предоставляемого корпорацией LSI.

В вызове используется поддельный ключевой файл («??C:Userstesterdesktopkey.txt»). Настоящий ключ вызова хранится по смещению 0x300 в файле c:WindowsSystem32Driversbeep.sys (ключ — это «ключ», который хранится на диске в виде большого двоичного объекта в кодировке base64 «a2V5e3RoZXN3b3Jkb2ZhdGhvdXNhbmR0cnV0aHN9»).

Настройка

Виртуальная машина, предоставленная на CTF, уже настроена. Если вы хотите настроить собственную виртуальную машину, выполните следующие действия:

  1. Создайте административное запланированное задание (или используйте следующее: disableautorepair-taskscheduler.xml — переименуйте «.key» в «.xml»), которое запускается при запуске и выполняет различные необходимые команды BCD, описанные в таблице 1 ниже. NB: если учетная запись для входа имеет пустой пароль, необходимо отключить политику локальной безопасности «Учетные записи: ограничить использование локальной учетной записью пустых паролей…»
  2. Установите имена значений, указанные в таблице 2 ниже, в разделе реестра HKLMSystemCurrentControlSetCrashControl
  3. Определите смещение и размер файла beep.sys с помощью инструмента GetDiskRuns.exe (переименуйте «.key» в «.exe»)

  1. Если он отличается от предустановленных значений offset=26808320 и size=6144, драйвер storport_lsi.sys необходимо обновить и пересобрать для этой платформы.
  2. Также можно загрузить отладочную сборку драйвера storport_lsi.sys (переименовать «.key» в «.sys») и просмотреть выходные данные отладки, чтобы определить эту информацию.

Чтобы исправить beep.sys, чтобы он содержал ключ, сделайте следующее:

  • Включить ведение журнала дампа (см. раздел «Сценарий вызова» ниже)
  • Перезагрузить
  • Измените файл c:dumpstack.log.tmp, чтобы он содержал параметры, необходимые для исправления ключа:
  • Сохраните журнал; это вызовет проверку на наличие ошибок.
  • Перезагрузите компьютер и убедитесь, что в файле есть ключ
  • Отключите ведение журнала стека дампа (требуется перезагрузка), удалите файлы журнала и очистите все другие следы:
    • Удалите копию storport_lsi.sys, созданную в Via100d2.sys, и создайте новую копию storport_lsi.sys.
    • Удалить все файлы минидампа/дампа
    • Очистить журналы событий
    • AppDataLocalTempWER*.xml

    Команда BCD

    Цель

    Таблица 1: Команды BCD

    < /таблица>

    Таблица 2: значения реестра

    –==[ ЭТАП 1: Включить ведение журнала стека дампа]==–

    Чтобы перейти ко второму этапу задания, пользователь должен включить ведение журнала стека дампа (c:DumpStack.log.tmp) через реестр:

    После проверки системы, если ведение журнала включено, сообщение «Файл еще не указан!!» появится, и этап 2 начнется после перезагрузки. Если ведение журнала не было включено, появится сообщение «ЕЩЕ НЕ БЕЗУМНО? Ведение журнала дампа стека отключено», и этап 1 повторяется после перезагрузки.

    Примечание. Где-то в моем коде есть ошибка, из-за которой я не могу изменить сообщение об ошибке на этом этапе задания.Я не смог выделить, где в коде это происходит, поэтому вместо вывода очевидного сообщения на экран код и параметры проверки ошибок используются для записи подсказки в шестнадцатеричных цифрах ASCII («логгирование дампа»): BugCheck 0x64756d70. Обратите внимание, что синий экран в Windows 8 будет отображать только код проверки ошибок — чтобы увидеть остальную часть строки, хранящейся в параметрах проверки ошибок, пользователю потребуется загрузить файл дампа в Windbg.

    –==[ ЭТАП 2: Манипуляции с содержимым журнала таким образом, чтобы файл считывался через аварийный путь ввода/вывода ]==–

    При запуске системы storport_lsi.sys изменит дескриптор и параметры безопасности в файле журнала стека дампа, чтобы пользователь мог редактировать его с правами администратора (исключительный дескриптор, который обычно принадлежит файлу crashdmp.sys, также удаляется). Чтобы выполнить этот шаг задачи, пользователь должен понимать, что он может редактировать файл и что, если в содержимом файла журнала указан полный путь к файлу, содержимое этого запрошенного файла будет прочитано с использованием аварийного ввода-вывода. path и копируется в файл журнала стека дампа при каждом последующем использовании пути сбоя (например, когда происходит сбой или система переходит в спящий режим). Для этого пользователю потребуется отредактировать файл журнала следующим образом:

    1. Запускайте Блокнот от имени администратора
    2. Откройте C:DumpStack.log.tmp
    3. Очистить содержимое
    4. Введите допустимый путь в формате ??C:
      1. "Действительный путь" определяется как любой файл на загрузочном томе, который не является одним из файлов и имеет размер не менее 512 байт (требуется для подкачки ввода-вывода)

      Storport_lsi.sys будет периодически проверять содержимое файла журнала стека дампа во время нормальной работы системы. Когда в файл будет сохранен действительный путь к файлу, storport_lsi.sys «подготовит» этот файл для копирования в C:DumpStack.log.tmp и немедленно проверит систему на наличие ошибок (чтобы пользователь знал, что он сделал что-то правильно).

      Если действующий файл находится в промежуточном состоянии или истекает интервал проверки на наличие ошибок (в зависимости от того, что наступит раньше), storport_lsi.sys проверит систему на наличие ошибок. Если в файле журнала не найден правильный путь, storport_lsi.sys отобразит сообщение об ошибке «Файл еще не указан!!» и после перезагрузки снова начнется этап 2.

      Если пользователь укажет на рабочем столе какой-либо действительный файл, отличный от файла key.txt, его содержимое (до 1 МБ) будет скопировано в DumpStack.log.tmp и появится там при перезапуске системы. Сообщение об ошибке будет выглядеть так: «Файл скопирован. Крутая история, бро», и этап 2 начнется заново при перезапуске.

      Если пользователь укажет поддельный файл ключа, сообщение об ошибке будет выглядеть так: «Файл ключа пуст, хорошая попытка! [path]|[0xoffset]|[0xbyte1],[0xbyte2]…», и этап 3 начинается при перезапуске.

      –==[Этап 3: Манипуляции с содержимым журнала, чтобы вызвать запись произвольного файла через аварийный путь ввода-вывода]==–

      В этот момент пользователь должен понять, что он смог скопировать содержимое файла в DumpStack.log.tmp, манипулируя журналом стека дампа, и теперь ему нужно заполнить его специальной командой, чтобы вызвать запись куда-либо (они не не знаю что и куда писать). Суть последнего шага в задаче — заставить их ЗАПИСАТЬ что-то в любой файл на диске через аварийный путь ввода-вывода. Это делается путем предоставления команды в формате [path]|[0xoffset]|[0xbytes]:

      Чтобы выполнить задание, пользователь должен вызвать запись в любой произвольный файл на диске. Storport_lsi.sys будет знать, что это уникальная запись, потому что, будучи частью драйвера аварийного фильтра, его обратный вызов DumpWrite будет уведомляться всякий раз, когда для записи на диск используется путь аварийного дампа. Внутри DumpWrite storport_lsi.sys может проверить, предназначена ли запись для файла, отличного от файла дампа или файла журнала дампа, и если да, то предположить, что пользователь успешно разобрался с этим этапом задачи.

      Если пользователь инициирует запись, обратный вызов DumpWrite добавит ключ к сгенерированному файлу дампа. Он также отключит драйвер storport_lsi.sys, просто переименовав его в «Via100d2.sys». Последним сообщением об ошибке будет «Тролль завершен. У нас тут задира.”

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

      –==[Этап 4: Ключ сбрасывается в файл аварийного дампа]==–

      При перезагрузке после завершения этапа 3 вызов завершается, и ключ сохраняется в файле минидампа, сгенерированном в папке Windowsminidump. Созданный мини-дамп, скорее всего, поврежден и не может быть загружен Windbg или успешно проанализирован инструментами анализа дампа (такими как dumpchk). Это сделано наполовину, чтобы сделать извлечение ключа немного более трудоемким, а также потому, что я слишком ленив, чтобы разработать стратегию того, какие блоки памяти я не должен перезаписывать в своем обратном вызове дампа, когда я добавляю ключ к файлу дампа (нет простого способа узнать, является ли конкретный MDL, переданный обратному вызову моего драйвера, частью загруженного списка модулей, KRPC, стека потоков или любой другой части отладочных данных, добавляемых к дампу ).Но ключ будет разбросан повсюду в файле дампа, так что проницательный наблюдатель должен это заметить.

      Выводы: рекомендации по дизайну

      Разрабатывая эту задачу, я хотел сделать ее достаточно сложной, чтобы оперативные криминалистические методы извлечения ключа не увенчались успехом, но при этом достаточно интуитивно понятными, чтобы пользователь естественным образом направлялся к решению (использовать сбой I/ О путь). Способ защиты ключа зависит от того, где он хранится.

      Первый вариант, который является идеальным, заключается в том, чтобы показать пользователю файл ключа на рабочем столе, но не разрешить ему доступ к нему по обычному пути. Эта настройка дала бы пользователю понять, что ему нужно открыть этот файл, но обычные методы не работают. Эта блокада, естественно, заставит их рассмотреть другие способы доступа к диску (т. е. аварийный путь). Есть три очевидных способа предотвратить банальный доступ к файлу на живом диске:

      1. Подключите драйвер порта диска к обычному пути ввода-вывода, чтобы отклонить запрос к физическим секторам
      2. Установить фильтр файловой системы и запретить доступ на уровне файловой системы.
      3. Удерживать монопольную блокировку файла ключа в нашем драйвере

      Варианты 2 и 3 чувствительны к прямому доступу к необработанному диску и сквозным запросам scsiport. Другая криминалистическая экспертиза удаленного диска, такая как F-Response (через iSCSI), также может помешать вариантам 2 и 3. Вариант 1 — сложная задача, как по причинам стабильности, так и по причинам полноты, и еще хуже тот факт, что он должен работать в Windows 8. , который перешел исключительно на использование драйвера storport.sys. Обратите внимание, что мы предполагаем, что тривиальные офлайн-атаки (например, доступ к файлу vmdk) не разрешены, поскольку виртуальная машина находится в облаке.

      Другой вариант – встроить ключ в такое место на диске, где пользователь не будет его искать. Этот вариант приемлем с точки зрения защиты, потому что он делает криминалистику в реальном времени спорной (да, они могут читать все сектора, но будут ли они искать строки base64??) и обеспечивает разумный уровень защиты ключа. Основная опасность связана с самим драйвером storport_lsi.sys, который можно выгрузить из памяти и отменить. Тем не менее, пользователь должен быть солидным реверсером И обладать глубокими знаниями о внутренностях Windows, чтобы понять некоторые структуры, которые ему нужно будет реверсировать (пары отображения первичных дисков). Хотя это, безусловно, выполнимо, этот вариант дает нам лучшее из обоих миров — защиту ключа без серьезной дестабилизации системы. Однако есть два основных недостатка:

      • Статическое смещение, хранящееся в storport_lsi.sys, должно быть извлечено при настройке задачи, и возможно изменение дискового пространства для beep.sys
      • Как сделать обнаружение этого аспекта задачи интуитивно понятным для пользователя?

      Если на диске выполняется изменение для beep.sys (например, с помощью дефрагментации), хотя маловероятно, это приведет к полному сбою задачи, поскольку storport_lsi.sys не сможет правильно получить ключ. Это приемлемый риск, так как это очень маловероятный сценарий. Чтобы решить вторую проблему, я решил не заставлять пользователя получать какие-либо знания или сведения о расположении ключей. Это просто укрытие, и драйвер storport_lsi.sys знает, как автоматически извлечь его через аварийный путь ввода-вывода, как только пользователь выполнит этапы проверки.

      Хотя для извлечения ключа из beep.sys можно использовать обычный путь ввода-вывода, у пользователя нет реального способа узнать, где искать, поскольку storport_lsi.sys не использует имена файлов для извлечения ключа из beep.sys — использует специальный код управления вводом-выводом, выдаваемый драйверу файловой системы, который сохраняет смещение файла в специальных структурах, называемых дисковыми прогонами. Пользователь может перевернуть storport_lsi.sys, найти код, который запрашивает у драйвера файловой системы FSCTL_QUERY_RETRIEVAL_POINTERS, и перевернуть структуры, но это требует дополнительных навыков и нетривиального количества времени. Ключ хранится в двоичном файле драйвера beep.sys с использованием пути ввода-вывода аварийного дампа, поэтому не существует модификаций времени MAC или других криминалистических доказательств.

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

      • Легче и чище кодировать
      • Более удобный интерфейс для пользователя (хотя и не такой увлекательный)
      • Спящий режим позволит использовать больше/разнообразие функций испытаний
      • Легче поддерживать состояние вызова.
      • Дополнительные параметры для скрытия ключа в памяти

      Однако в VMWare просто невозможно использовать гостевой режим гибернации. Это известная проблема. Рабочая станция VMWare фактически устанавливает службу через VMWare Tools, которая отключает гостевой режим гибернации (через вызов ZwPowerInformation, чтобы указать ОС не резервировать место для hiberfil.sys), предположительно, потому что их собственная функция «Приостановить» будет конфликтовать.Разумеется, повторное включение гостевого режима гибернации (путем удаления службы) приводит к тому, что VMWare задыхается при выходе из режима гибернации.

      Устранение неполадок

      Что нужно попробовать в первую очередь:

      • Перезагрузите и повторите операцию, вызвавшую проблему
      • См. известные проблемы ниже

      Обратите внимание: если что-то пойдет не так во время испытания, storport_lsi.sys можно отключить, просто удалив его из ключа реестра или удалив файл с диска в консоли восстановления, нажав SHIFT+F8 при запуске (должен нажимать быстро и многократно — есть задержка около 10 секунд, прежде чем машина может проверить ошибку!). В меню начальной загрузки выберите:

      • Выберите «По умолчанию» или «Другие параметры».
      • Другие варианты
      • Устранение неполадок
      • Дополнительные параметры
      • Командная строка

      Теперь введите в командной строке: «del d:windowssystem32driversstorport_lsi.sys» (в режиме восстановления загрузочный диск монтируется как «D:»).

      Вместо того, чтобы удалять драйвер, сначала попробуйте удалить вызывающий ошибку файл d:dumpstack.log.tmp таким же образом, как описано выше. Если проблемный файл помещен в журнал стека дампа, он останется там и вызовет бесконечный цикл перезагрузок.

      Другие более надуманные вещи, которые "возможно"/"наверняка будут" решать проблему:

      В то время как метод обхода фокусируется на более продвинутых методах использования пути ввода-вывода аварийного дампа полностью вне его предполагаемой среды, метод захвата фильтра дампа фокусируется на новых функциях ведения журнала в Windows 8, которые непреднамеренно предоставляют драйверу фильтра аварийного дампа простой способ использовать аварийный путь ввода-вывода во время сбоя или гибернации для чтения/записи на диск. Чтобы полностью понять эту технику, нам нужно изучить некоторые внутренние механизмы работы crashdmp.sys.

      В обзоре фильтров аварийного дампа было отмечено, что функция LoadFilterDrivers создает недокументированную структуру контекста фильтра для каждого установленного фильтра аварийного дампа. Наблюдая за тем, что копируется в смещения этой структуры внутри LoadFilterDrivers и FilterCallback, можно реконструировать определение структуры. Отправной точкой для определения структуры контекста фильтра является вызов подпрограммы DriverEntry, которая происходит в функции FilterCallback. Соответствующая декомпиляция показана ниже.

      Этот вызов сразу показывает, что два указателя, которые передаются функции DriverEntry() фильтра, на самом деле являются указателями на поля в родительской структуре (контексте фильтра) с первым аргументом (указатель на тип FILTER_EXTENSION) со смещением 0, а второй аргумент (указатель на тип FILTER_INITIALIZATION_DATA) по смещению 0x28 (все значения смещения относятся к платформам x86).

      Единственные другие ссылки на поля в этой структуре контекста фильтра встречаются в LoadFilterDrivers. Уже установлено, что эта функция поддерживает связанный список структур контекста фильтра, и на основе кода, который назначает ссылки указателя, структура LIST_ENTRY находится по смещению 0x78. Два дополнительных назначения в LoadFilterDrivers показывают наличие двух полей указателей со смещением 0x84 и 0x88. Указатель со смещением 0x84 ссылается на структуру глобального контекста, используемую в драйвере crashdmp.sys, а второй указатель со смещением 0x88 — это структура, содержащая информацию об образе драйвера фильтра. Шестое и последнее поле в структуре контекста фильтра не упоминается и поэтому неизвестно. Реконструированное определение этой структуры показано ниже.

      Непрямая передача структуры контекста бухгалтерского учета драйверу — обычная практика Microsoft. Однако неясно, почему существует поле GlobalContext, так как оно больше нигде не упоминается в двоичном файле crashdmp.sys, не требуется драйверам фильтров и представляет собой ненужное раскрытие внутреннего состояния операционной системы (структура глобального контекста поддерживает внутреннее состояние). для стека дампа и используется почти во всех его функциях). В результате любой драйвер фильтра может манипулировать данными, хранящимися в этом контексте. Например, драйвер фильтра может отменить связь с другими драйверами фильтра (отключив шифрование всего диска для файла гибернации и файлов сбоя).

      Полное восстановление определения структуры глобального контекста выходит за рамки этого веб-сайта. Однако некоторые поля внутри этой структуры, которые управляют функцией регистрации стека дампа, представляют раскрытие внутреннего состояния, которое может быть захвачено для произвольного чтения/записи через аварийный путь ввода-вывода. Прежде чем обсуждать эти поля, необходимо дать общее представление о том, что такое журналирование стека дампа.

      Ведение журнала дампа стека — это недокументированная функция механизма аварийного дампа, представленная в Windows 8. Файл журнала, расположенный по адресу :DumpStack.log.tmp, по умолчанию отключен. Когда этот параметр включен, crashdmp.sys будет записывать основную диагностическую информацию на каждом этапе процесса создания дампа (например, когда был запущен дамп, какие модули вызывались в стеке фильтров и т. д.).Его можно включить, задав для имени параметра реестра HKLMSYSTEMCurrentControlSetControlCrashControlEnableLogFile ненулевое значение. Размер файла журнала и его уровень детализации контролируются с помощью имени параметра реестра HKLMSYSTEMCurrentControlSetControlCrashControlDumpLogLevel. В таблице ниже приведены поддерживаемые уровни ведения журнала стека дампа и их влияние.

      Если этот параметр включен в реестре правильно, файл журнала создается и инициализируется в файле crashdmp.sys!CrashdmpInitialize после завершения всех других инициализаций стека дампа (включая загрузку фильтров). Функция crashdmp.sys!InitDumpLogFile выполняет следующие задачи для инициализации файла журнала:

      1. Вызывает CheckForLogFile — пытается открыть любой существующий файл журнала и, если он имеет правильную подпись заголовка, переименовывает этот существующий файл в C:DumpStack.log
      2. Сохраняет и устанавливает новый размер файла журнала на основе DumpLogLevel.
      3. Вызывает CreateLogFile — создает файл C:DumpStack.log.tmp как скрытый системный файл в монопольном режиме с дескриптором безопасности на уровне системы, сохраняет открытый дескриптор в глобальном контексте.
      4. Вызывает GetFileDiskRuns — находит структуру макета файла, описывающую физический макет файла журнала, отправляя FCTL_QUERY_RETRIEVAL_POINTERS драйверу файловой системы, и сохраняет результирующую структуру в глобальном контексте.
      5. Выделяет вспомогательный буфер размером со страницу, используемый для форматирования строки журнала перед ее записью в файл журнала.

      Поле SectorLengthInBytes указывает, сколько байтов хранится в расположении StartingLogicalOffsetInBytes, что представляет собой логическое смещение начала указанного сектора относительно начала содержащего его тома. Обратите внимание, что FSCTL_QUERY_RETRIEVAL_POINTERS можно использовать только для файлов, которые гарантированно находятся на загрузочном томе. Информация о структуре диска для файлов, которые могут занимать несколько томов, может быть получена только с помощью FSCTL_GET_RETRIEVAL_POINTERS, который использует другую структуру для представления дисковых дисков (или сопоставления пар). ). Драйвер crashdmp.sys может безопасно использовать FSCTL_QUERY_RETRIEVAL_POINTERS, поскольку файл журнала (а также файл дампа) гарантированно находится на загрузочном томе, который имеет однозначное сопоставление номеров виртуальных кластеров (VCN) с логическими кластерами. Числа (LCN).

      Поскольку для файла может быть выполнено несколько запусков, структура макета файла, хранящаяся в crashdmp.sys, представляет собой массив MappingPairs со значением счетчика, указывающим, сколько записей содержится в массиве:

      Функции ведения журнала в файле crashdmp.sys, которые напрямую зависят от структуры макета файла журнала, описаны ниже:

      • WriteLogDataToDisk — перебирает прогоны диска, хранящиеся в структуре глобального контекста, создает MDL для каждого запроса и использует внутренние функции ввода-вывода (которые вызывают драйвер порта дампа) для записи данных на диск с использованием пути ввода-вывода после сбоя. /li>
      • ReadLogDataFromDisk — то же, что и WriteLogDataToDisk, за исключением того, что для чтения данных журнала с диска используются функции чтения.

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

      Однако эффект замены структуры разметки диска для указания на какой-либо другой файл на диске заключается просто в том, что замененный файл будет действовать как файл журнала стека дампа и будет перезаписан содержимым журнала. Это действительно ничего не дает. Достижение произвольного чтения/записи с помощью механизма регистрации сбоев требует вызова функций WriteLogDataToDisk и ReadLogDataFromDisk непосредственно из драйвера фильтра аварийного дампа. Поскольку эти функции не экспортируются, их можно найти, просканировав текстовую часть файла crashdmp.sys во время выполнения.

      Для вызова этих функций необходимо воссоздать их прототипы путем обратного проектирования crashdmp.sys. Эти прототипы показаны ниже.

      ReadLogDataFromDisk принимает указатель на структуру глобального контекста; указатель на выходной буфер; индекс в массиве дисковых запусков, представляющий расположение сектора целевого файла для начала чтения; количество байтов для чтения; и смещение в данные, описанные запрошенным дисковым прогоном. Одно место в файле crashdmp.sys, использующее эту функцию, передает 0 для номера запуска и параметров смещения, что приводит к чтению всего файла.WriteLogDataToDisk принимает указатель на структуру глобального контекста; указатель на выходной буфер, который всегда является вспомогательным буфером, выделенным в структуре глобального контекста; и флаг BOOLEAN, указывающий, следует ли обновлять информацию о позиции журнала в структуре глобального контекста. Обе функции имеют необычные прототипы (обозначенные как __userpurge в IDA Pro) из-за оптимизации компилятора x86 для пользовательских соглашений о вызовах в рамках параметра /LTCG (генерация временного кода связи). Эта оптимизация использует произвольные назначения регистров для первого параметра функции. В случае ReadLogDataFromDisk первый параметр передается в ecx, что легко имитируется с помощью соглашения о вызовах __thiscall. Однако для WriteLogDataToDisk параметр должен быть явно сохранен в edi с использованием встроенного ассемблера перед вызовом функции.

      Прежде чем разрабатывать стратегию использования этих функций вне файла crashdmp.sys, важно помнить, что эти функции можно использовать только во время сбоя или перехода в спящий режим. Причина двоякая:

      1. Эти функции неявно предполагают ограничения среды аварийного дампа, то есть однопоточный/непрерывный ЦП, синхронный ввод-вывод, HIGH_IRQL, а обычный путь ввода-вывода отключен (в противном случае в процессе будет удалено) 2 .
      2. Crashdmp.sys хранит указатели на свои внутренние функции, которые выдают запросы ввода-вывода к драйверу порта дампа в структуре глобального контекста. Эти указатели функций не инициализируются до тех пор, пока они не потребуются (во время сбоя или гибернации). Таким образом, вызов любой из функций ведения журнала вне контекста сбоя/гибернации приведет к разыменованию нулевого указателя.

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

      По этим причинам путь к журналу должен быть взломан в два этапа: этап до сбоя, когда извлекается макет целевого файла, и этап после сбоя, когда макет имплантируется и вызываются необходимые функции для достижения желаемого чтения. (s) и/или написать(s). Двухэтапный процесс угона показан ниже (сбой показан для иллюстрации, но событие гибернации будет работать так же).

      Рисунок 1. Двухэтапный захват пути ведения журнала

      Пример использования двухэтапного подхода для захвата функций пути ведения журнала для исправления драйвера на диске:

      Мэттью – фрилансер, написавший множество статей на различные темы, связанные с технологиями. Основное внимание он уделяет ОС Windows и всему, что с ней связано. Он увлечен. Подробнее

      • Система Windows может стать новым лучшим другом человека. Помимо многочисленных преимуществ, он также предоставляет процесс, предназначенный для сохранения содержимого вашей оперативной памяти в случае сбоя системы и создания его дампа в файле данных.
      • Файлы сбоя, безусловно, полезны и могут помочь разработчикам в дальнейшем исправлять и предотвращать ошибки BSOD, но они имеют тенденцию накапливаться и занимать значительную часть вашего дискового пространства, поэтому вы можете время от времени удалять их.
      • Если вы действительно хотите улучшить свою игру, погрузитесь в наш центр ошибок Windows 10 и быстро освойте все исправления от экспертов.

      Для решения различных проблем с ПК мы рекомендуем DriverFix:
      Это программное обеспечение будет поддерживать работоспособность ваших драйверов, тем самым защищая вас от распространенных компьютерных ошибок и сбоев оборудования. Проверьте все свои драйверы прямо сейчас, выполнив 3 простых шага:

      Файлы дампа памяти, иначе аварийные дампы, — это системные файлы, сохраняемые во время сбоев на синем экране. При появлении сообщения об ошибке BSOD Windows сохраняет копию системной памяти.

      Эти файлы аварийного дампа затем могут помочь разработчикам исправить системные сбои BSOD. Пользователи могут отправлять аварийные дампы разработчикам при подаче заявок в службу поддержки.

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

      Однако пользователи также могут удалять аварийные дампы с помощью утилит очистки.

      Как удалить файлы дампа системной памяти в Windows?

      1. Удалить аварийные дампы с помощью очистки диска
      2. Удалить аварийные дампы с помощью командной строки
      3. Отключить аварийные дампы

      1. Удаление аварийных дампов с помощью очистки диска

      1. Пользователи могут стирать аварийные дампы с помощью собственной функции очистки диска Windows.Для этого запустите «Выполнить» с помощью сочетания клавиш Windows + R.
      2. Введите cleanmgr в текстовом поле «Выполнить» «Открыть».
      3. Нажмите Ctrl + Shift + Enter, чтобы открыть Очистку диска от имени администратора.
      4. Выберите диск C: в окне выбора диска и нажмите кнопку "ОК".
      5. Установите флажок "Файлы дампа памяти системной ошибки".
      6. Затем нажмите кнопку ОК.
      7. Пользователям, которые не могут найти параметр «Файлы дампа памяти системной ошибки» в программе «Очистка диска», следует открыть эту утилиту с помощью командной строки с повышенными привилегиями. Введите

        8. в подсказке и нажмите клавишу возврата. Это откроет Очистку диска с дополнительными опциями флажков.

        2. Удалить аварийные дампы с помощью командной строки

        1. Пользователи также могут стирать аварийные дампы с помощью ряда команд командной строки. Для этого откройте аксессуар «Бег».
        2. Введите cmd в меню «Выполнить» и нажмите клавиши Ctrl + Shift + Enter.
        3. Затем введите в подсказке следующие отдельные команды и нажимайте Enter после ввода каждой.

        fsutil usn deletejournal /d /n c:

        удалить «%temp%*» /s /f /q

        удалить "C:$Recycle.bin*" /s /f /q

        удалить «%systemroot%temp*» /s /f /q

        vssadmin удалить тени /for=c: /all /quiet

        Dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase

        3. Отключить аварийные дампы

        1. Пользователи могут отключить создание аварийных дампов, чтобы не занимать больше места на жестком диске. Введите Панель управления в текстовом поле «Выполнить» «Открыть» и нажмите клавишу «Ввод».
        2. Затем нажмите «Система», чтобы открыть апплет панели управления, показанный непосредственно ниже.
        3. Нажмите "Дополнительные параметры системы" в левой части окна, чтобы открыть вкладку "Дополнительно".
        4. Затем нажмите кнопку "Настройки" в разделе "Загрузка и восстановление".
        5. Выберите вариант (нет) в раскрывающемся меню, показанном непосредственно ниже, чтобы отключить аварийные дампы.
        6. Затем нажмите кнопку ОК.

          7. Итак, пользователи могут удалить аварийные дампы в Windows несколькими способами. Удаление аварийных дампов может освободить довольно много места на жестком диске, поэтому обязательно сделайте это.

          Сообщите нам, какой метод вы выбрали, в разделе комментариев ниже.

          Хотите узнать больше о системных файлах? Изучите нашу страницу и соберите всю информацию, с которой сможете справиться.

          По-прежнему возникают проблемы? Исправьте их с помощью этого инструмента:

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

    Имя параметра реестра Установить значение Назначение
    CrashDumpEnabled 3 Устанавливает тип дампа «маленький дамп памяти», т. е. минидамп
    MinidumpDir %SystemRoot%Minidump Устанавливает выходная папка minidump
    DumpFilters добавить «storport_lsi.sys» без кавычек и новой строки Включает драйвер фильтра аварийного дампа< /td>
    Автоперезагрузка 0 (НЕОБЯЗАТЕЛЬНО) отключает автоматическую перезагрузку после сбоя