The windows video driver timeout detection and recovery delay tdrdelay aida

The windows video driver timeout detection and recovery delay tdrdelay aida

Aida64 отправила мне следующее предупреждение при открытии теста стабильности системы (окно со всеми графиками):

Я хочу узнать больше об этом TdrDelay, что это? Кроме того, я должен принять предложение Aida64?

Тайм-аут обнаружения и восстановления (TDR)

В Windows Vista и более поздних версиях операционная система пытается обнаружить ситуации, в которых компьютеры кажутся полностью «замороженными». Затем операционная система пытается динамически восстанавливаться из замороженных ситуаций, чтобы настольные компьютеры снова реагировали. Этот процесс обнаружения и восстановления известен как тайм-аут обнаружения и восстановления (TDR). В процессе TDR планировщик графического процессора операционной системы вызывает функцию DxgkDdiResetFromTimeout драйвера минипорта дисплея для повторной инициализации драйвера и сброса графического процессора.

TDR означает «Обнаружение и восстановление тайм-аута». Это функция операционной системы Windows, которая обнаруживает проблемы с откликом графической карты и восстанавливает рабочий стол путем сброса карты. Если операционная система не получает ответ от графической карты в течение определенного периода времени (по умолчанию 2 секунды), операционная система сбрасывает графическую карту.

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

Настройка стоимости

Нажмите кнопку Пуск, введите regedit в поле поиска, а затем дважды щелкните файл regedit.exe из приведенных выше результатов. Если вас попросят ввести пароль администратора или подтверждение, введите пароль или предоставьте подтверждение. Найдите и затем щелкните следующий раздел реестра:

В меню «Правка» нажмите «Создать», а затем выберите следующее значение реестра в раскрывающемся меню, соответствующее вашей версии Windows (32-разрядная или 64-разрядная):

Для 32-битного Windows Select DWORD (32-bit ) значение. Введите TdrDelay в качестве имени и нажмите Enter. Дважды щелкните TdrDelay и добавьте 8 данные значения и нажмите ОК.

Для 64-битной Windows

Выберите QWORD (64-bit) значение. Введите TdrDelay в качестве имени и нажмите Enter. Дважды щелкните TdrDelay и добавьте 8 для данных значения и нажмите OK. Закройте редактор реестра и перезагрузите компьютер, чтобы изменения вступили в силу.

NB: я использовал значение 8, но вы всегда можете настроить его. Но в вашем случае я заметил, что у вас уже есть инструмент, который сделает это автоматически для вас.

Источник

TDR (Timeout Detection and Recovery) и сбор файлов дампов

ID 3335

До существования TDR, подобные проблемы драйвера видеокарт приводили к зависанию системы и требовали перезагрузки ОС. Если TDR включена и вы видите сообщение, связанное с TDR, «Видеодрайвер перестал отвечать и был восстановлен», это означает что ОС Windows успешно сбросила драйвер видеокарты.

Эта статья объясняет как получить файл дампа, связанный со сбоем. Агенты службы поддержки NVIDIA могут попросить Вас предоставить файл дампа, связанного с TDR, который содержит важную информацию о видеокарте и драйвере во время сбоя.

Типы файлов дампа о сбоях

Существует два основных типа сбоев:

Системный сбой (BSOD)

Файлы дампа о сбое Kernel Mode бывают разных вариантов:
Минидамп (Minidump)
Полный дамп памяти (Complete Memory Dump)
Дамп памяти Kernel (Kernel Memory Dump)
Малый дамп памяти (Small Memory Dump)

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

Файлы названы «MiniDDMMYY-NN.dmp». DDMMYY означает дату в формате день/месяц/год. NN это число, начинающееся со значения 01 и увеличивается каждый раз, когда новый минидамп создан в конкретный день.

Что касается дамп файлов, связанных с TDR, но не связанных с Синим Экраном Смерти, они находятся в:

Сбой приложения
Файлы дампа User Mode доступны в полном и мини вариантах. Процесс автоматического получения файла дампа user mode детально описан Microsoft по ссылке:

Чтобы перейти к месту на жестком диске, в котором по умолчанию хранятся дамп файлы сбоев:

1) Нажмите сочетание клавиш Win+R, чтобы вызвать окно «Выполнить».
2) Введите следующее в поле «Открыть»:

3) Нажмите кнопку Ок
4) Это должно открыть расположение, в которое Windows по умолчанию сохраняет логи сбоев. Ищите самые недавние файлы, основываясь на дате, так как они означают сбои, возникшие с самым недавним драйвером.

Если ваше приложение часто и стабильно выдает сбои, и сотрудник поддержки NVIDIA просит полный дамп файл, чтобы получить более подробную информацию, будет легче вручную получить полный файл дампа о сбое User Mode, во время сбоя приложения.

1) Когда приложение даст сбой и Windows покажет вам сообщение об ошибке, не закрывайте никаких окон.

2) В это же время, одновременно нажмите клавиши «Control» + «Alt» + «Delete» чтобы вызвать экран блокировки. Выберите «Диспетчер задач» с экрана блокировки. Нажмите на «Подробнее», чтобы получить больше информации.

3) Ищите программу, которая дала сбой и нажмите на нее правой кнопкой мыши. Затем выберите «Создать файл дампа».

4) Это создаст полный файл дампа большого размера. Когда дамп будет создан, его имя и расположение покажет вам Windows.

5) Полные файлы дампа обычно имеют размер между 1 Гб и 1.5 Гб. Из-за большого размера, полные файлы дампа не могут быть приложены к электронному письму и отправлены как приложение. Они должны быть загружены на хостинг для файлов или использовать сервис передачи файлов. Сотрудник службы поддержки NVIDIA может помочь вам с этим.

Чтобы получить больше информации о TDR, посетите сайт Microsoft по ссылке:

Источник

Stability Test Suggestion Dialog (TdrDelay)

By IgelRM,
July 21, 2017 in General Discussion

Recommended Posts

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Similar Content

40min), Memtest86(in bios (1 hour)), TestMem5), all is ok. Sometimes the sound hangs. As if the whole system hangs for

The new AIDA64 release introduces a multi-threaded OpenCL GPGPU AES-256 benchmark to measure cryptographic processing performance of modern graphics processors and APUs. It also provides extended Mantle API diagnostics for the latest AMD Radeon graphics accelerators, and supports the latest video adapters and storage devices.

New features & improvements

[ Press Release (English) ]

[ Press Release (Deutsch) ] [ Press Release (italiano) ] [ Press Release (magyar) ] [ What’s new in AIDA64 v4.50 ]

The latest AIDA64 update introduces a multi-threaded OpenCL GPGPU Hash benchmark to measure SHA-1 hashing performance of modern graphics processors and APUs. It also implements support for Microsoft Windows 8.1 Update 1 and Windows Server 2012 R2 Update 1, and supports the latest graphics and GPGPU computing technologies.

New features & improvements

Microsoft Windows 8.1 Update 1 and Windows Server 2012 R2 Update 1 support OpenCL GPGPU SHA-1 hash benchmark CUDA 6.0 support Socket AM1 motherboards support Improved support for Intel “Broadwell” CPU Preliminary support for AMD “Carrizo” and “Toronto” APUs Preliminary support for Intel “Skylake”, “Cherry Trail”, “Denverton” CPUs Crucial M550 and Intel 730 SSD support GPU details for AMD Radeon R7 265 GPU details for nVIDIA GeForce GTX 745, GeForce 800 Series What’s new since AIDA64 v4.00

OpenCL GPGPU Benchmark Suite AMD Mantle graphics accelerator diagnostics Multi-threaded memory stress test with SSE, SSE2, AVX, AVX2, FMA, BMI and BMI2 acceleration Optimized 64-bit benchmarks for AMD “Kaveri”, “Bald Eagle”, “Mullins”, “Beema” APUs Optimized 64-bit benchmarks for Intel Atom C2000 “Avoton” and “Rangeley” SoC Optimized 64-bit benchmarks for Intel “Bay Trail” desktop, mobile and tablet SoC Full support for the upcoming Intel “Haswell Refresh” platform with Intel “Wildcat Point” PCH Razer SwitchBlade LCD support Preliminary support for Intel Quark X1000 “Clanton” SoC Improved support for OpenCL 2.0 Support for VirtualBox v4.3 and VMware Workstation v10 OCZ Vector 150, OCZ Vertex 460, Samsung XP941 SSD support GPU details for AMD Radeon R5, R7, R9 Series GPU details for nVIDIA GeForce 700 Series
[ Press Release (English) ]

Источник

Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве

Решение проблемы „Видеодрайвер перестал отвечать и был успешно восстановлен”

Решение проблемы „Видеодрайвер перестал отвечать и был успешно восстановлен” (“Display driver has stopped working and has recovered”)

Знаю, что многие пользователи Vista и Windows7 x86/x64 сталкивались с подобным сообщением. Проблема переползла и в Windows8, не потеряв актуальности.
Обычно это происходит во время игры, работы какого-то 3д приложения или просмотре видео, но бывает, что и буквально “на пустом месте”, просто во время набора текста или серфинга по интернету. Я предлагаю решение этой проблемы, которое неоднократно помогало мне и другим. Заодно – тут собраны и другие варианты решений, пожалуй, полнее не видел нигде.(Обновление статьи 20 декабря 2012).

После такого зависания вы увидите в трее сообщение “Atikmdag has stopped responding and has successfully recovered” для ATI, “nvlddmkm has stopped responding and has successfully recovered” для nVidia или “igfx has stopped responding and has successfully recovered” для intel (на руссом – “Atikmdag (или nvlddmkm, или igfx) перестал отвечать и был успешно восстановлен”).

Понятно, что перезапуск видеодрайвера вызывается каким-то событием, но проблема плавающая, единой причины срабатывания триггера остановки не известно, подобное сообщение может быть вызвано целой кучей причин, любая из которых приводит к увеличению задержки ответа драйвера. Зато прекрасно известно, какой механизм отвечает за такое поведение системы. Имя механизму- Timeout Detection and Recovery (TDR). Вкратце, это система восстановления после программных ошибок, избавляющая от необходимости перезагрузки компьютера в случае такой ошибки. Завязана она на драйверную модель, введённую в Vista и успешно использующуюся в Windows 7 и 8, и она действительно помогает избежать ситуаций, которые в случае с более ранними версиями Windows практически однозначно приводили к зависанию компьютера или BSOD и необходимости перезагрузки, с потерей всех несохранённых данных. В абсолютном большинстве случаев работа TDR пользователю не заметна, но в некоторых случаях получается такая вот „несостыковочка”. Это не проблема только лишь Windows (ведь как раз со стороны операционки «всё честно отработало»), это проблема также и производителей драйверов. И nvidia, и ati неоднократно заявляли, что «работают над следующей версией драйвера, в которой эта проблема будет устранена», но воз и ныне там, ситуация с момента выхода windows 7 и до сегодняшнего дня не изменилась. Скорее всего, кардинальных изменений они уже и не внесут – это может только нарушить сам принцип работы такого механизма.

Ниже я собрал возможные решения этой проблемы, среди которых есть и редко встречающиеся или описываемые.

В некоторых случаях ошибка „Видеодрайвер перестал отвечать и был успешно восстановлен” (“Display driver has stopped working and has recovered”) может проявляться и после применения всех вышеуказанных фиксов, и после переустановки системы по-новой, и вообще всегда. Это может указывать на уже физические проблемы- перегрев видеокарты, либо выход видеокарты из строя. Конечно, это самая нежелательная ситуация, но такое бывает. Проверить, кроме как установив точно такую же видеокарту, больше никак не получится.

Источник

Timeout detection and recovery (TDR)

This page describes timeout detection and recovery (TDR) for driver developers. See also TDR in Windows 8 and later for additional implementation details.

Overview

One of the most common stability problems in graphics occurs when a computer «hangs», or when it appears to be completely «frozen» while, in reality, it is processing an end-user command or operation. The user typically waits a few seconds and then decides to reboot the computer. The frozen appearance of the computer typically occurs because the GPU is busy processing intensive graphical operations, typically during game play, and hence does not update the display screen. TDRs enable the operating system to detect that the UI is not responsive.

The figure below shows the TDR process.

The operating system (OS) attempts to detect situations in which computers appear to be «frozen». The OS then attempts to dynamically recover from the frozen situations so that desktops are responsive again, alleviating the situation where end users needlessly reboot their systems.

If the OS detects that six (6) or more GPU hangs and subsequent recoveries occur within one (1) minute, the OS bug-checks the computer on the next GPU hang.

Timeout detection in WDDM

The GPU scheduler, which is part of the DirectX graphics kernel subsystem (Dxgkrnl.sys), detects that the GPU is taking more than the permitted amount of time to execute a particular task. The GPU scheduler then tries to preempt this particular task. The preempt operation has a «wait» timeout, which is the actual TDR timeout. The default timeout period in Windows Vista and later operating systems is 2 seconds. If the GPU cannot complete or preempt the current task within the TDR timeout period, the OS diagnoses that the GPU is frozen.

To prevent timeout detection from occurring, hardware vendors should ensure that graphics operations (that is, direct memory access (DMA) buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and game play.

Preparation for recovery

The GPU scheduler calls the display miniport driver’s DxgkDdiResetFromTimeout function to inform the driver that the OS detected a timeout. The driver must then reinitialize itself and reset the GPU. In addition, the driver must stop accessing memory and should not access hardware. The OS and the driver collect hardware and other state information that can be useful for post-recovery diagnosis.

See TDR in Windows 8 and later for additional implementation details.

Desktop recovery

The OS resets the appropriate state of the graphics stack. The video memory manager, which is also part of Dxgkrnl.sys, purges all allocations from video memory. The display miniport driver resets the GPU hardware state. The graphics stack takes the final actions and restores the desktop to the responsive state.

The only visible artifact from the hang detection to the recovery is a screen flicker. This flicker results when the OS resets some portions of the graphics stack, which causes a screen redraw. It is eliminated if the display miniport driver complies with WDDM 1.2 and later (see Providing seamless state transitions in WDDM 1.2 and later).

When the OS has successfully recovered the desktop, it does the following:

Some legacy DirectX applications might just render black at the end of this recovery, which requires the end user to restart these applications. Well-written DirectX 9Ex and DirectX 10 and later applications that handle Device Remove technology continue to work correctly. An application must release and then re-create its Microsoft Direct3D device and all of the device’s objects.

Источник