Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство — это скрипт автоматизации отладчика ядра под названием kdfe. Kdfe расшифровывается как Kernel Debugger Front End, то есть интерфейс или надстройка для взаимодействия пользователя с ядерным отладчиком kd.exe (Kernel Debugger) на достаточно простом и понятном уровне. Фактически, kdfe представляет собой скрипт, автоматизирующий определенные действия пользователя и позволяющий в достаточно сжатый промежуток времени получить анализ аварийного дампа памяти системы, либо полностью автоматизировать действия по получению результата анализа и использовать их в более развитых и глобальных автоматизированных системах (правда в этом случае скрипт придется слегка доработать). В стандартном режиме kdfe перенаправляет вывод отладчика ядра kd.exe, что позволяет использовать только необходимые выходные данные отладчика. Понятное дело что kdfe не является панацеей, в его отсутствии нам просто пришлось бы анализировать аварийный дамп памяти системы вручную, непосредственно в консоли при помощи отладчика ядра kd с определенными входными параметрами, что, согласитесь, менее удобно и более времязатратно. Автор скрипта, Александр Суховей (Alexander Suhovey), несомненно создал хороший инструментарий, за что хотелось бы сказать ему отдельное спасибо и за весомый вклад в науку отладки и сэкономленное время.
Подготовка к анализу
Как было уже сказано ранее, скрипт kdfe требует наличия в системе отладчика ядра kd.exe, входящего в состав комплекта Debugging Tools for Windows. Из этого следует, что нам требуется сперва установить Debugging Tools for Windows.
На следующем этапе нам необходимо получить в свое распоряжение сам скрипт kdfe. В сети мне удалось найти сайт, носящий название abandoned blog, который оказался домашней страницей автора. Могу предположить, что сайт давно не обновляется, поэтому я решил, на всякий случай, продублировать скрипт и на своем ресурсе.
Скачать: kdfe
Исходный код скрипта приводить не вижу особого смысла, во избежание разночтений. После того, как вы скачали скрипт на свою машину, его можно распаковать (как вариант) во временную папку (системная переменная %TEMP%
), лично у меня она ссылается, по старой-доброй традиции, на C:\TEMP.
Настройка пути к средствам отладки
Дело в том, что в некоторых версиях скрипта присутствует не совсем корректный алгоритм задания пути к исполняемым файлам дистрибутива инструментов отладки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
. . . ::Kernel debugger path. Default is: ::For version 6.8.4.0 — October 18, 2007 and older IF EXIST «%PROGRAMFILES%\Debugging Tools for Windows\kd.exe» ( set dbgpath=«%PROGRAMFILES%\Debugging Tools for Windows» ) ELSE ( rem For version 6.9.3.113 — April 29, 2008 and newer rem 32 bit IF EXIST «%PROGRAMFILES%\Debugging Tools for Windows (x86)\kd.exe» ( set dbgpath=«%PROGRAMFILES%\Debugging Tools for Windows (x86)» ) ELSE ( rem 64 bit IF EXIST «%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)\kd.exe» ( set dbgpath=«%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)» ) ELSE ( IF EXIST «%PROGRAMW6432%\Debugging Tools for Windows (x64)\kd.exe» ( set dbgpath=«%PROGRAMW6432%\Debugging Tools for Windows (x64)» ) ELSE ( echo ERROR: Debugging Tools for Windows not found^^! pause exit /b 1 ) ) ) ) :: Or set the path to Debugging Tools below :: set dbgpath=«<path>» . . . |
Скрипт писался давно, и попросту «не знал» о существовании новых путей установки средств отладки Microsoft. С определенной версии путь установки изменился на:
- %PROGRAMFILES(X86)%\Windows Kits\10\Debuggers\x86;
- %PROGRAMFILES(X86)%\Windows Kits\10\Debuggers\x64;
Поэтому можно модифицировать значение переменной dbgpath на путь к отладчику, актуальный для вашей системы.
Настройка символов
Еще один немаловажный момент у нас заключается в использовании символов. В принципе, определение символов у нас дано в других статьях, однако освежим свои знания:
Для анализа дампа памяти отладчику требуются символьные файлы компонентов системы.
У нас есть два варианта решения данной проблемы:
- Скачать символы самостоятельно. Символы можно загрузить с сайта Microsoft, по ссылке пакеты символов Windows. Однако, последнее время вручную символы мало кто скачивает, потому что полный пакет довольно внушителен по размеру и качаться он будет долго, в добавок ко всему есть шанс ошибиться при выборе.
- Скачивать символы автоматически. Современные отладочные средства умеют получать информацию о символах самостоятельно из сети интернет, для этого их необходимо предварительно на это настроить. Причем плюс данного подхода заключается в том, что отладчик скачает необходимые символы, то есть символы именно той системы, на которой создавался дамп, а не той, на которой происходит анализ.
Вам необходимы символы для той системы, которая создала дамп памяти, но не для той системы, на который Вы этот дамп анализируете!
Скрипт kdfe написан таким образом, чтобы указывать отладчику kd скачивать с сервера символов Microsoft только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. Задается это в скрипте при помощи переменной smbpath
, которая указывает каталог, в который kd.exe будет сохранять необходимые файлы. По-умолчанию это %SYSTEMDRIVE%\symbols, соответственно, в большинстве случаев это C:\symbols. Надо ли вручную создавать эту директорию, либо kd создаст её сам?
Запуск скрипта
Если дамп для анализа у Вас располагается в стандартных директориях расположения дампов, то можно просто вызвать скрипт без параметров:
kdfe
Если же дамп у Вас расположен в местоположении, отличном от классических директорий, то можно вызвать скрипт с параметром полного пути к исследуемому дампу:
kdfe d:\junk\memory.dmp
Непосредственно после запуска скрипт kdfe определяет рабочую директорию средств отладки (Debugging Tools for Windows). Среди возможных вариантов перебираются все возможные пути установки средств отладки. Необходимо это для того, чтобы адресно запускать отладчик ядра kd.exe с указанием полного пути до исполняемого файла.
Если при запуске скрипта вы наблюдаете ошибки нахождения средств отладки, то скрипт придется слегка самостоятельно подправить, изменив значение параметра
dbgpath
.
Если скрипт kdfe без параметров командной строки, то он анализирует параметры ветки реестра HKLM\SYSTEM\CurrentControlSet\Control\CrashControl и использует сконфигурированные в параметрах DumpFile
и MinidumpDir
места расположения дампов в системе. После этого сканирует директории и выводит все обнаруженные файлы дампов в виде меню выбора, предлагая пользователю указать требуемый файл дампа для анализа:
Соответственно, после того, как пользователь выбирает дамп для анализа, скрипт kdfe запускает отладчик kd.exe с определенными параметрами командной строки, дожидается результатов, фильтрует вывод отладчика и перенаправляет его на консоль.
Анализ некоторых дампов может занимать продолжительное время. Наберитесь терпения.
Анализ результатов
Теперь пришло время проанализировать вывод, предоставленный нам скриптом kdfe.
Параметр | Описание |
---|---|
Crash date | Дата и время произошедшего сбоя. |
Stop error code | Код СТОП-ошибки (BugCheck). В нашем случае это STOP 0x00000124. |
Process name | Сообщает имя процесса, в контексте которого произошел сбой. |
Probably caused by | Выводится возможный источник проблемы. |
Прежде всего, нас интересует главный и самый важный параметр, который выводится после строки probably caused by. В нем обозначается источник проблемы, то есть причина синего экрана смерти BSOD. По выводу мы можем понять, что в данном конкретном случае присутствует исключительно аппаратная проблема (ключевое слово hardware). Забегая вперед скажу, что виновником оказался процессор. Да, да, да, сам был чрезвычайно удивлен, потому как столкнулся с подобным впервые, но после долгой диагностики всего железа с последующей заменой частей, последним вариантом оказался именно процессор. Итогом всего этого стала замена процессора, и вот только после этого синие экраны прекратились.
Однако, по статистике, в большинстве случаев виновниками синих экранов являются драйвера устройств сторонних производителей, в подобном случае в строке probably caused by мы можем увидеть нечто вроде igxpdv32.dll. После чего необходимо понять, что именно это за драйвер и скачать+установить более новую (либо более старую) стабильную версию.
Довольно часто рекомендуется обращать внимание так же и на строку Process name, поскольку проблема бывает многосоставная и в этом параметре указывается контекст процесса, то есть (вероятный) виновник более общего, высокого уровня. Например, исполняемый .exe-файл какой-либо программы, библиотека .dll, и зачастую проблема может быть связана с указанной программой, а не с драйвером/компонентом. Дополнительно, имейте эту информацию в виду, и если проблема не устранилась непосредственной работой с источником, указанным в строке probably caused by.
I’m trying to install the Windows Debugging Tools via the Windows SDK and after two attempts I am at a loss for what to do. I start the installation and receive no errors at all but the debugging tools (windbg and kd) are nowhere to be found… The log is next to useless:
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_End: Product: Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_Begin: Product: Redistributable Components for Application Verifier and Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState: Product: Redistributable Components for Application Verifier and Windows Debugging Tools; Installed: Unknown;
Does anyone have any suggestions as to where to start debugging why I am unable to install the debugging tools? Oh, the irony!
jv42
8,5215 gold badges40 silver badges64 bronze badges
asked Jul 19, 2011 at 1:36
Robert KaucherRobert Kaucher
1,8413 gold badges22 silver badges44 bronze badges
If you’re running Windows 7 AND Visual Studio 2010 SP1:
(The previous answer is out of date.)
Here’s the problem according to microsoft: http://support.microsoft.com/kb/2717426
In a nutshell, uninstall these two:
- Microsoft Visual C++ 2010 x86 Redistributable
- Microsoft Visual C++ 2010 x64 Redistributable
Now you should be able to install Windows Debugging Tools via the Windows 7.1 SDK.
Afterward, you may reinstall the Visual c++ 2010 redistributables if you want.
answered Aug 29, 2013 at 21:19
3
If you’re running Windows 7 AND Visual Studio 2010 SP1:
Your installation of the SDK won’t complete properly, due to missing compiler packages that were removed when VS 2010 SP1 was installed. MS has since patched this, so here is your new installation order:
- Install the Windows 7.1 SDK.
- Your installation will only be partially complete after the compiler error. Install the Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1.
- Re-run your Windows SDK web installer. Choose the first option to add features to the existing installation.
- Re-choose (either under redistributables or common) the desired features, including the Debugger Tools.
answered Oct 3, 2011 at 14:53
CasanovaCasanova
1211 silver badge3 bronze badges
You can find the installer packages at (Windows SDK x86 or x64 DVD root)\Setup\WinSDKDebuggingTools and WinSDKDebuggingTools_amd64. Please use them to install the Debugging Tools.
Note that due to Microsoft’s favourite game of messing up download links and files, you will have to use a search engine to locate the latest download link for the ISO images. I would not track that always in this answer.
answered Jul 19, 2011 at 8:56
Lex LiLex Li
60.8k9 gold badges117 silver badges148 bronze badges
3
After spending hours finding out none of the above works, and only seconds away from smashing my stupid machine to bits, I stumbled upon the solution in SO.
It basically says that for 64-bit Window 7, installing the «Standalone Debugging Tools for Windows 8.1» found here should work.
Unbelievably, it actually did
BTW, the target folder changed to «C:\Program Files (x86)\Windows Kits\8.1»
answered Feb 27, 2014 at 18:36
bavazabavaza
10.4k10 gold badges65 silver badges104 bronze badges
I faced the same issue and debug message was «Debug Policy is set to 0». After reading the above comments what I did was came up with the minimal package needed for WinDBG install, just by trial and error. The following three packages did the trick.
Debugging Tools for Windows
Windows App Certification
MSI tools
I had a successful install and it worked fine too. I am using Windows 7 64 bit
answered Aug 31, 2016 at 12:28
Santhosh KumarSanthosh Kumar
3811 gold badge5 silver badges14 bronze badges
I’m trying to install the Windows Debugging Tools via the Windows SDK and after two attempts I am at a loss for what to do. I start the installation and receive no errors at all but the debugging tools (windbg and kd) are nowhere to be found… The log is next to useless:
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_End: Product: Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_Begin: Product: Redistributable Components for Application Verifier and Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState: Product: Redistributable Components for Application Verifier and Windows Debugging Tools; Installed: Unknown;
Does anyone have any suggestions as to where to start debugging why I am unable to install the debugging tools? Oh, the irony!
jv42
8,5015 gold badges40 silver badges64 bronze badges
asked Jul 19, 2011 at 1:36
Robert KaucherRobert Kaucher
1,8413 gold badges21 silver badges44 bronze badges
If you’re running Windows 7 AND Visual Studio 2010 SP1:
(The previous answer is out of date.)
Here’s the problem according to microsoft: http://support.microsoft.com/kb/2717426
In a nutshell, uninstall these two:
- Microsoft Visual C++ 2010 x86 Redistributable
- Microsoft Visual C++ 2010 x64 Redistributable
Now you should be able to install Windows Debugging Tools via the Windows 7.1 SDK.
Afterward, you may reinstall the Visual c++ 2010 redistributables if you want.
answered Aug 29, 2013 at 21:19
3
If you’re running Windows 7 AND Visual Studio 2010 SP1:
Your installation of the SDK won’t complete properly, due to missing compiler packages that were removed when VS 2010 SP1 was installed. MS has since patched this, so here is your new installation order:
- Install the Windows 7.1 SDK.
- Your installation will only be partially complete after the compiler error. Install the Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1.
- Re-run your Windows SDK web installer. Choose the first option to add features to the existing installation.
- Re-choose (either under redistributables or common) the desired features, including the Debugger Tools.
answered Oct 3, 2011 at 14:53
CasanovaCasanova
1211 silver badge3 bronze badges
You can find the installer packages at (Windows SDK x86 or x64 DVD root)SetupWinSDKDebuggingTools and WinSDKDebuggingTools_amd64. Please use them to install the Debugging Tools.
Note that due to Microsoft’s favourite game of messing up download links and files, you will have to use a search engine to locate the latest download link for the ISO images. I would not track that always in this answer.
answered Jul 19, 2011 at 8:56
Lex LiLex Li
59.4k9 gold badges118 silver badges143 bronze badges
3
After spending hours finding out none of the above works, and only seconds away from smashing my stupid machine to bits, I stumbled upon the solution in SO.
It basically says that for 64-bit Window 7, installing the «Standalone Debugging Tools for Windows 8.1» found here should work.
Unbelievably, it actually did
BTW, the target folder changed to «C:Program Files (x86)Windows Kits8.1»
answered Feb 27, 2014 at 18:36
bavazabavaza
10k10 gold badges63 silver badges100 bronze badges
I faced the same issue and debug message was «Debug Policy is set to 0». After reading the above comments what I did was came up with the minimal package needed for WinDBG install, just by trial and error. The following three packages did the trick.
Debugging Tools for Windows
Windows App Certification
MSI tools
I had a successful install and it worked fine too. I am using Windows 7 64 bit
answered Aug 31, 2016 at 12:28
Santhosh KumarSanthosh Kumar
3591 gold badge5 silver badges12 bronze badges
-
DesignerMix
- Администратор
- Сообщения: 7019
- Зарегистрирован: 25 апр 2014, 10:51
- Откуда: Белгород
- Контактная информация:
![](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3C/svg%3E)
Исправляем синий экран смерти (BSOD). Windows Debugging Tool
Я показал процесс анализа дампов памяти которые создаются при появлении синего экрана смерти (Blue screen of death) при помощи инструментов Windows Debugging Tool и скрипта KDFE (kdfe.cmd). Этот способ помогает выявить именно то устройство, драйвер либо другую проблему которая вызвала BSOD. Надеюсь это видео было вам полезным.
- Windows Debugging Tool — http://msdn.microsoft.com/ru-RU/windows … e/hh852363
- Отредактированный скрипт KDFE (должен работать сразу) — http://goo.gl/WiEPBY
- Оригинальный скрипт KDFE — http://tools.oszone.net/Vadikan/files/kdfe.zip
- Справочник BSOD — http://soft.oszone.net/program/809/Spravka_po_BSOD/
- Утилита BlueScreenView — http://www.nirsoft.net/utils/blue_screen_view.html
Если у вас есть проблема с анализом дампов памяти, предлагаю заархивировать файлы дампов и прикрепить архив к вашему сообщению в качестве вложения. Я со своей стороны буду их анализировать и указывать вероятную причину появления синего экрана смерти а также то как ее можно исправить.
PS:Напомню что дампы памяти по умолчанию находятся в папке C:WindowsMinidump
Отредактированный мной скрипт KDFE:
Код: Выделить всё
::=====================================================================
:: Name: KDFE.CMD
::
:: Purpose: Kernel debugger Front End.
::
:: Usage: kdfe.cmd [dump_file] [-v]
::
:: Version: 1.1
::
:: Technology: Windows Command Script
::
:: Requirements: Windows 2000+
:: Debugging Tools for Windows
:: reg.exe:
:: Windows XP: built-in
:: Windows 2000: install Windows Support Tools
::
:: Authors: Alexander Suhovey (asuhovey@gmail.com)
::=====================================================================
@echo off
setlocal ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
if "%~1"=="-debug" (echo on&set debug=1&shift /1)
set sver=1.1
echo.
::==========================
:: Variables
::==========================
::Kernel debugger path. Default is:
::For version 6.8.4.0 - October 18, 2007 and older
IF EXIST "%PROGRAMFILES(x86)%Windows Kits8.0Debuggersx64kd.exe" (
set dbgpath="%PROGRAMFILES(x86)%Windows Kits8.0Debuggersx64"
) ELSE (
rem For version 6.9.3.113 - April 29, 2008 and newer
rem 32 bit
IF EXIST "%PROGRAMFILES%Windows Kits8.0Debuggersx32kd.exe" (
set dbgpath="%PROGRAMFILES%Windows Kits8.0Debuggersx32"
) ELSE (
rem 64 bit
IF EXIST "%PROGRAMFILES(x86)%Windows Kits8.0Debuggersx32kd.exe" (
set dbgpath="%PROGRAMFILES(x86)%Windows Kits8.0Debuggersx32"
) ELSE (
IF EXIST "%PROGRAMFILES%Windows Kits8.0Debuggersx64kd.exe" (
set dbgpath="%PROGRAMFILES%Windows Kits8.0Debuggersx64kd.exe"
) ELSE (
echo ERROR: Debugging Tools for Windows not found^^!
pause
exit /b 1
)
)
)
)
:: Or set the path to Debugging Tools below
:: set dbgpath="<path>"
::Symbols and executable images folders. If folders do not contain
:: required files, kd.exe will download them from Microsoft Symbols
:: Server as needed.
set smbpath=%SYSTEMDRIVE%symbols
set imgpath=%smbpath%
::Microsoft Symbols Server URL.
set smburl=http://msdl.microsoft.com/download/symbols
set imgurl=%smburl%
::Windows Crash Control registry settings path.
set ccregpath="HKLMSYSTEMCurrentControlSetControlCrashControl"
::Debugger parameters.
set dbgparams=-y srv*"%smbpath:"=%"*%smburl% -i srv*"%imgpath:"=%"*%imgurl% -c
if "%debug%"=="1" (
set dbgparams=%dbgparams% "^^^!sym noisy; .reload; ^^^!analyze -v; q"
) else (
set dbgparams=%dbgparams% "^^^!analyze -v; q"
)
::==========================
:: Parse arguments
::==========================
set dumpfile=&set v=&
:PARSE
set arg=%~1&
shift /1
if not defined arg goto NEXT
if defined v (if defined dumpfile goto NEXT)
if "%arg%"=="/?" (goto SYNTAX) else (if "%arg%"=="-?" goto SYNTAX)
if "%arg%"=="-v" (set verbose=1&goto PARSE)
if not defined dumpfile (set dumpfile="%arg%"&goto PARSE)
:NEXT
::==========================
:: Checks
::==========================
set dbgpath=%dbgpath:"=%
for %%i in (reg.exe,"%dbgpath%kd.exe") do (
if "%%~$PATH:i"=="" (
if not exist %%i (
echo ERROR: Cannot find required file '%%~i'
pause
goto :EOF
)
)
)
::==========================
:: Main section
::==========================
set /a n=0
if defined dumpfile (
if exist !dumpfile! (
for %%z in (!dumpfile!) do (set dumpfile="%%~dpnxz")
call :ANALYZE !dumpfile! %verbose%
) else (
echo ERROR: Cannot find dump file !dumpfile!
)
) else (
for /f "tokens=2*" %%i in ('reg query %ccregpath% /v DumpFile 2^>^&1 ^| find "DumpFile"') do set kdump=%%j
for /f "tokens=2*" %%k in ('reg query %ccregpath% /v MinidumpDir 2^>^&1 ^| find "MinidumpDir"') do set minidir=%%l
if "!kdump!!minidir!"=="" echo ERROR: Cannot find required registry information^^!&pause&goto :EOF
call :ENUMD "!kdump!" "!minidir!"
if !n!==0 (
echo No crash dump files found with following search filter:
echo !kdump!
echo !minidir!*.dmp
) else (
echo Following crash dump files found:
echo.
for /l %%n in (1,1,!n!) do (call :GETD %%n& echo %%n. !dumpfile!)
echo.
set /p foo="Which one would you like to analyze?[1-!n!] "
for /l %%s in (1,1,!n!) do (
if !foo!==%%s (
call :GETD %%s
call :ANALYZE !dumpfile! %verbose%
pause
goto :EOF
)
)
echo.
echo What was that? Have some coffee and try again.
)
)
pause
goto :EOF
::==========================
:: Subroutines
::==========================
:ANALYZE
pushd "%dbgpath%"
if "%2"=="1" (kd.exe -z %1 %dbgparams% 2>&1) else (
echo.
set /p bar="Analyzing %1, please wait..."<nul
for /f "delims=" %%r in ('kd.exe -z %1 %dbgparams% 2^>^&1') do (
set out=%%r
if not "!out:PROCESS_NAME:=!"=="!out!" (set process=!out:PROCESS_NAME: =!)
if not "!out:BUGCHECK_STR:=!"=="!out!" (set crashcode=!out:BUGCHECK_STR: =!)
if not "!out:Debug session=!"=="!out!" (set crashdate=!out:Debug session time: =!)
if "!out:~0,18!"=="Probably caused by" (set guess=%%r)
)
echo Done.&echo.
if defined guess (
echo.
echo Crash date: !crashdate!
echo Stop error code: !crashcode!
if defined process echo Process name: !process!
echo !guess: :=:!
) else (
echo Didn't find the answer. Try again with '-v' switch.
)
)
popd
goto :EOF
:ENUMD
if exist %1 (set /a n+=1&set !n!=%1)
for %%m in ("%~2*.dmp") do (set /a n+=1&set !n!="%%m")
goto :EOF
:GETD
for /f "tokens=2 delims==" %%o in ('set %1 ^| find "%1="') do (set dumpfile=%%o&goto :EOF)
goto :EOF
:SYNTAX
echo.
echo Kernel Debugger Front End v%sver%
echo.
echo SYNTAX:
echo.
echo %~nx0 [dump_file] [-v]
echo.
echo dump_file - Crash dump file. If omitted, KDFE will search for crash
echo dump files in locations configured on your computer and
echo let you select a file to analyze.
echo -v - Verbose output. By default KDFE shows only basic crash
echo information and debugger's guess about crash cause.
echo This switch will show full debugger session output.
echo.
echo EXAMPLES:
echo.
echo %~nx0 "c:my dumpsmemory.dmp" -v
echo.
echo REQUIREMENTS:
echo.
echo Debugging Tools for Windows
echo.
echo REFERENCES:
echo.
echo Debugging Tools for Windows:
echo http://www.microsoft.com/whdc/devtools/debugging/default.mspx
echo.
echo Windows Hang and Crash Dump Analysis webcast by Mark Russinovich:
echo http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032298075
echo.
echo How to read small memory dump files:
echo http://support.microsoft.com/kb/315263
echo.
echo How to Use Driver Verifier to Troubleshoot Windows Drivers:
echo http://support.microsoft.com/Default.aspx?kbid=244617
goto :EOF
::==========================
:: End of script
::==========================
- Вложения
-
kdfe_edit_by_DesignerMix.rar
- Отредактированный скрипт KDFE (должен работать сразу)
- (2.6 КБ) 1768 скачиваний
- Правила форума
- История изменений форума
- Мой YouTube-канал
-
Belyj
- Постоянный пользователь
- Сообщения: 112
- Зарегистрирован: 09 июн 2014, 21:16
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
Belyj » 09 июн 2014, 22:28
Весьма смелое название темы. А между тем сия тема очень обширна. Лучше взять за правило в таких ситуациях при любом раскладе всегда проверять память и винт, причём сначала непосредственно сами разъёмы/шлейфы а уж потом и тесты. Ибо ни одна софтинка никогда не покажет, что окислен контакт или пылинка в разъём попала. А покажет она в любом случае на какой либо файл/процесс/драйвер и придётся долгий и тернистый путь
-
DesignerMix
- Администратор
- Сообщения: 7019
- Зарегистрирован: 25 апр 2014, 10:51
- Откуда: Белгород
- Контактная информация:
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
DesignerMix » 09 июн 2014, 22:45
Belyj, если грамотно проводить диагностику программно, при этом анализируя дампы памяти, заглядывая в журнал событий Windows и делая правильные выводы, то можно довольно быстро понять в чем именно проблема.
С тем что на опере часто окисляются контакты согласен, но вы-же сами сказали что тема обширна и поэтому сразу бросаться в поиск аппаратных неисправностей наверное не стоит. Тем более те люди которые смотрели это видео в большинстве своем не имеют опыта в разборе компьютера не говоря уже о извлечении отдельных его частей и было-бы опрометчиво им это советовать т.к. если они не исправят проблему, а сделают только хуже будет не очень хорошо.
- Правила форума
- История изменений форума
- Мой YouTube-канал
-
Belyj
- Постоянный пользователь
- Сообщения: 112
- Зарегистрирован: 09 июн 2014, 21:16
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
Belyj » 11 июн 2014, 00:03
Согласен. Но далеко не всё можно починить программными методами. Синие экраны в большинстве своём как раз таки возникают из-за неполадок с памятью и жестким диском. А если не лазить внутрь компьютера, то как же тогда учиться ремонту. Не думаю что требуются какие-то особые навыки, чтоб достать планочку и поводить по ней ластиком, народ нынче продвинутый пошел.
Сам в таких случаях предпочитаю сперва исключать такие вот проблемы, чем по пять раз гонять тесты, это же всё уйму времени отнимает. Анализ дампов штука,конечно хорошая, сам предпочитаю упомянутую выше bluescreen view, но на практике до анализа дампа почти никогда не доходит.
-
DesignerMix
- Администратор
- Сообщения: 7019
- Зарегистрирован: 25 апр 2014, 10:51
- Откуда: Белгород
- Контактная информация:
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
DesignerMix » 12 июн 2014, 23:01
banzay_man писал(а):Всем привет. У меня стоит ОС Windows 8.1 и появляется синий экран при загрузке. Я сделал все как описано чтоб информация об ошибке сохранилась в .dmp файле для следующего анализа, но C:WindowsMinidump папка пуста. Как сделать чтоб информация сохранилась в Minidump папке?
Нажмите комбинацию клавиш Win+Pause Break в открывшемся окне выберите «Дополнительные параметры системы», далее в пункте «Загрузка и восстановление» нажмите кнопку «Параметры» и проверьте чтобы в пункте «Отказ системы» были такие параметры:
- Правила форума
- История изменений форума
- Мой YouTube-канал
-
DesignerMix
- Администратор
- Сообщения: 7019
- Зарегистрирован: 25 апр 2014, 10:51
- Откуда: Белгород
- Контактная информация:
![](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3C/svg%3E)
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
DesignerMix » 13 июн 2014, 10:26
banzay_man писал(а):я все делаю как показано но система не сохраняет в minidump папке ничего
Ладно, тогда проверьте что-бы был включен файл подкачки: Нажмите комбинацию клавиш Win+Pause Break в открывшемся окне выберите «Дополнительные параметры системы» далее как на картинке:
Если файл подкачки у вас тоже был включен, попробуйте вручную создать папку Minidump (путь в итоге должен быть таким «Имя_диска_с_ОС:WindowsMinidump»).
Если ничего не поможет и после появления синего экрана дамп так и не появиться сделайте следующее:
Если вы уже вошли в систему:
- Прокрутите от правой границы экрана и затем последовательно коснитесь элементов Параметры и Изменить параметры компьютера. (Если вы используете мышь, переместите указатель в верхний правый угол экрана, затем вниз и последовательно щелкните Параметры и Изменить параметры компьютера.)
- В разделе Параметры компьютера выберите Обновление и восстановление.
- Теперь выберете Восстановление
- В разделе Особые варианты загрузки выберете Перезагрузить сейчас
- Далее последовательно зайдите — Диагностика -> Дополнительные параметры -> Параметры загрузки -> Перезагрузить -> При запросе нажмите клавишу F9, таким образом вы отключите автоматическую перезагрузку при отказе системы.
И когда синий экран появится снова компьютер не перезагрузится, таким образом вы сможете переписать код ошибки. Напишите его сюда и будем думать в чем проблема.
- Правила форума
- История изменений форума
- Мой YouTube-канал
-
DesignerMix
- Администратор
- Сообщения: 7019
- Зарегистрирован: 25 апр 2014, 10:51
- Откуда: Белгород
- Контактная информация:
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
DesignerMix » 15 июн 2014, 12:24
banzay_man писал(а):он так и не создается. когда виндоус питается загружаться зависает и показывает синий экран с грустным смайликом и там написано SYSTEM_THREAD_EXCEPTION_NOT_HANDLED, но код ошибки не написанно.
Вам выше задавали вопрос, но вы так и не ответили… У вас ноутбук или стационарный компьютер? Если ноут, напишите его модель.
По поводу ошибки SYSTEM_THREAD_EXCEPTION_NOT_HANDLED:
— Попробуйте отключить все USB-устройства из портов (кроме клавиатуры и мышки , если они USB);
— Если не помогло, попробуйте восстановить BIOS на значения по умолчанию. Для этого зайдите в BIOS и в пункте «Exit» выберите «load optimal defaults» и затем нажмите F10, таким образом будут восстановлены значения по умолчанию для BIOS материнской платы:
Инструкция по входу в BIOS
— Если ничего из вышеперечисленного не помогло, попробуйте переключить режим работы жесткого диска в BIOS — на «Compateble IDE» если он стоит на «AHCI», либо наоборот на «AHCI» если он стоял на «Compateble IDE». Если это не изменит ситуацию верните значение на то, которое было изначально.
— Ну и наконец если все вышеперечисленное не принесет результата, нужно проверить жесткий диск на ошибки. К примеру воспользовавшись утилитой HDD Regenerator
- Правила форума
- История изменений форума
- Мой YouTube-канал
-
Belyj
- Постоянный пользователь
- Сообщения: 112
- Зарегистрирован: 09 июн 2014, 21:16
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
Belyj » 16 июн 2014, 22:15
Как в хр сделать не получится.
Смею предположить что проблема возникла после установки драйвера, либо обновления. Пока вы нам не расскажите подробно, мы не сможем вам помочь. Заданные мной вопросы вы проигнорировали. Система хоть иногда загружается? Безопасный режим работает? Может получится, удерживая shift, нажать кнопочку перезагрузка и откатить системку?
-
DesignerMix
- Администратор
- Сообщения: 7019
- Зарегистрирован: 25 апр 2014, 10:51
- Откуда: Белгород
- Контактная информация:
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
DesignerMix » 17 июн 2014, 08:07
banzay_man писал(а):ни кто ничего не игнорировал, не ваши вопросы и не предложенные вами варианты. потому задаю новый вопрос что, делаю как пишите но все ровно не помогает, иначе написал бы что решено. проблема появилось после обновления и в безопасный режим загружается нормально.
Тогда вам необходимо просто выполнить откат на предыдущую точку восстановления. Точки восстановления автоматически создаются перед установкой обновлений Windows.
Чтобы это сделать загрузитесь в безопасном режиме и сделайте следующее:
— Нажмите комбинацию клавиш Win+R и в открывшемся окне введите rstrui затем нажмите Enter.
— В открывшемся окне просто следуя инструкциям мастера восстановления системы выберите контрольную точку ориентируйтесь по дате создания точки и описанию. Что-бы узнать какие программы будут затронуты при откате нажмите соответствующую кнопку в мастере.
После восстановления, если проблема была только в установке обновления, система должна загрузиться корректно.
- Правила форума
- История изменений форума
- Мой YouTube-канал
-
banzay_man
- Новичок
- Сообщения: 6
- Зарегистрирован: 12 июн 2014, 07:37
-
Vladiclavgj
- Новичок
- Сообщения: 1
- Зарегистрирован: 23 авг 2014, 14:20
Re: Исправляем синий экран смерти (BSOD). Windows Debugging
Сообщение
Vladiclavgj » 23 авг 2014, 14:25
Здраствуйте. Я посмотрел ваше видео по поводу Синего экрана смерти.Сделал все как в видео вплоть до kdfe и переделал его.Но когда я выбираю dump file(он у меня 1)он не выдает ничего. Не подскажете что делать? Экран появляется при просмотре видео в вк и (т.п).Win 8.1,ошибка DPC_Watchdog_Violation. Архив прикреплен всей папкой.
- Вложения
-
Minidump.rar
- Minidump
- (70.21 КБ) 260 скачиваний
Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство — это скрипт автоматизации отладчика ядра под названием kdfe. Kdfe расшифровывается как Kernel Debugger Front End, то есть интерфейс или надстройка для взаимодействия пользователя с ядерным отладчиком kd.exe (Kernel Debugger) на достаточно простом и понятном уровне. Фактически, kdfe представляет собой скрипт, автоматизирующий определенные действия пользователя и позволяющий в достаточно сжатый промежуток времени получить анализ аварийного дампа памяти системы, либо полностью автоматизировать действия по получению результата анализа и использовать их в более развитых и глобальных автоматизированных системах (правда в этом случае скрипт придется слегка доработать). В стандартном режиме kdfe перенаправляет вывод отладчика ядра kd.exe, что позволяет использовать только необходимые выходные данные отладчика. Понятное дело что kdfe не является панацеей, в его отсутствии нам просто пришлось бы анализировать аварийный дамп памяти системы вручную, непосредственно в консоли при помощи отладчика ядра kd с определенными входными параметрами, что, согласитесь, менее удобно и более времязатратно. Автор скрипта, Александр Суховей (Alexander Suhovey), несомненно создал хороший инструментарий, за что хотелось бы сказать ему отдельное спасибо и за весомый вклад в науку отладки и сэкономленное время.
Подготовка к анализу
Как было уже сказано ранее, скрипт kdfe требует наличия в системе отладчика ядра kd.exe, входящего в состав комплекта Debugging Tools for Windows. Из этого следует, что нам требуется сперва установить Debugging Tools for Windows.
На следующем этапе нам необходимо получить в свое распоряжение сам скрипт kdfe. В сети мне удалось найти сайт, носящий название abandoned blog, который оказался домашней страницей автора. Могу предположить, что сайт давно не обновляется, поэтому я решил, на всякий случай, продублировать скрипт и на своем ресурсе.
Скачать: kdfe
Исходный код скрипта приводить не вижу особого смысла, во избежание разночтений. После того, как вы скачали скрипт на свою машину, его можно распаковать (как вариант) во временную папку (системная переменная %TEMP%
), лично у меня она ссылается, по старой-доброй традиции, на C:TEMP.
Настройка пути к средствам отладки
Дело в том, что в некоторых версиях скрипта присутствует не совсем корректный алгоритм задания пути к исполняемым файлам дистрибутива инструментов отладки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
. . . ::Kernel debugger path. Default is: ::For version 6.8.4.0 — October 18, 2007 and older IF EXIST «%PROGRAMFILES%Debugging Tools for Windowskd.exe» ( set dbgpath=«%PROGRAMFILES%Debugging Tools for Windows» ) ELSE ( rem For version 6.9.3.113 — April 29, 2008 and newer rem 32 bit IF EXIST «%PROGRAMFILES%Debugging Tools for Windows (x86)kd.exe» ( set dbgpath=«%PROGRAMFILES%Debugging Tools for Windows (x86)» ) ELSE ( rem 64 bit IF EXIST «%PROGRAMFILES(x86)%Debugging Tools for Windows (x86)kd.exe» ( set dbgpath=«%PROGRAMFILES(x86)%Debugging Tools for Windows (x86)» ) ELSE ( IF EXIST «%PROGRAMW6432%Debugging Tools for Windows (x64)kd.exe» ( set dbgpath=«%PROGRAMW6432%Debugging Tools for Windows (x64)» ) ELSE ( echo ERROR: Debugging Tools for Windows not found^^! pause exit /b 1 ) ) ) ) :: Or set the path to Debugging Tools below :: set dbgpath=«<path>» . . . |
Скрипт писался давно, и попросту «не знал» о существовании новых путей установки средств отладки Microsoft. С определенной версии путь установки изменился на:
- %PROGRAMFILES(X86)%Windows Kits10Debuggersx86;
- %PROGRAMFILES(X86)%Windows Kits10Debuggersx64;
Поэтому можно модифицировать значение переменной dbgpath на путь к отладчику, актуальный для вашей системы.
Настройка символов
Еще один немаловажный момент у нас заключается в использовании символов. В принципе, определение символов у нас дано в других статьях, однако освежим свои знания:
Для анализа дампа памяти отладчику требуются символьные файлы компонентов системы.
У нас есть два варианта решения данной проблемы:
- Скачать символы самостоятельно. Символы можно загрузить с сайта Microsoft, по ссылке пакеты символов Windows. Однако, последнее время вручную символы мало кто скачивает, потому что полный пакет довольно внушителен по размеру и качаться он будет долго, в добавок ко всему есть шанс ошибиться при выборе.
- Скачивать символы автоматически. Современные отладочные средства умеют получать информацию о символах самостоятельно из сети интернет, для этого их необходимо предварительно на это настроить. Причем плюс данного подхода заключается в том, что отладчик скачает необходимые символы, то есть символы именно той системы, на которой создавался дамп, а не той, на которой происходит анализ.
Вам необходимы символы для той системы, которая создала дамп памяти, но не для той системы, на который Вы этот дамп анализируете!
Скрипт kdfe написан таким образом, чтобы указывать отладчику kd скачивать с сервера символов Microsoft только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. Задается это в скрипте при помощи переменной smbpath
, которая указывает каталог, в который kd.exe будет сохранять необходимые файлы. По-умолчанию это %SYSTEMDRIVE%symbols, соответственно, в большинстве случаев это C:symbols. Надо ли вручную создавать эту директорию, либо kd создаст её сам?
Запуск скрипта
Если дамп для анализа у Вас располагается в стандартных директориях расположения дампов, то можно просто вызвать скрипт без параметров:
kdfe
Если же дамп у Вас расположен в местоположении, отличном от классических директорий, то можно вызвать скрипт с параметром полного пути к исследуемому дампу:
kdfe d:junkmemory.dmp
Непосредственно после запуска скрипт kdfe определяет рабочую директорию средств отладки (Debugging Tools for Windows). Среди возможных вариантов перебираются все возможные пути установки средств отладки. Необходимо это для того, чтобы адресно запускать отладчик ядра kd.exe с указанием полного пути до исполняемого файла.
Если при запуске скрипта вы наблюдаете ошибки нахождения средств отладки, то скрипт придется слегка самостоятельно подправить, изменив значение параметра
dbgpath
.
Если скрипт kdfe без параметров командной строки, то он анализирует параметры ветки реестра HKLMSYSTEMCurrentControlSetControlCrashControl и использует сконфигурированные в параметрах DumpFile
и MinidumpDir
места расположения дампов в системе. После этого сканирует директории и выводит все обнаруженные файлы дампов в виде меню выбора, предлагая пользователю указать требуемый файл дампа для анализа:
Соответственно, после того, как пользователь выбирает дамп для анализа, скрипт kdfe запускает отладчик kd.exe с определенными параметрами командной строки, дожидается результатов, фильтрует вывод отладчика и перенаправляет его на консоль.
Анализ некоторых дампов может занимать продолжительное время. Наберитесь терпения.
Анализ результатов
Теперь пришло время проанализировать вывод, предоставленный нам скриптом kdfe.
Параметр | Описание |
---|---|
Crash date | Дата и время произошедшего сбоя. |
Stop error code | Код СТОП-ошибки (BugCheck). В нашем случае это STOP 0x00000124. |
Process name | Сообщает имя процесса, в контексте которого произошел сбой. |
Probably caused by | Выводится возможный источник проблемы. |
Прежде всего, нас интересует главный и самый важный параметр, который выводится после строки probably caused by. В нем обозначается источник проблемы, то есть причина синего экрана смерти BSOD. По выводу мы можем понять, что в данном конкретном случае присутствует исключительно аппаратная проблема (ключевое слово hardware). Забегая вперед скажу, что виновником оказался процессор. Да, да, да, сам был чрезвычайно удивлен, потому как столкнулся с подобным впервые, но после долгой диагностики всего железа с последующей заменой частей, последним вариантом оказался именно процессор. Итогом всего этого стала замена процессора, и вот только после этого синие экраны прекратились.
Однако, по статистике, в большинстве случаев виновниками синих экранов являются драйвера устройств сторонних производителей, в подобном случае в строке probably caused by мы можем увидеть нечто вроде igxpdv32.dll. После чего необходимо понять, что именно это за драйвер и скачать+установить более новую (либо более старую) стабильную версию.
Довольно часто рекомендуется обращать внимание так же и на строку Process name, поскольку проблема бывает многосоставная и в этом параметре указывается контекст процесса, то есть (вероятный) виновник более общего, высокого уровня. Например, исполняемый .exe-файл какой-либо программы, библиотека .dll, и зачастую проблема может быть связана с указанной программой, а не с драйвером/компонентом. Дополнительно, имейте эту информацию в виду, и если проблема не устранилась непосредственной работой с источником, указанным в строке probably caused by.
I’m trying to install the Windows Debugging Tools via the Windows SDK and after two attempts I am at a loss for what to do. I start the installation and receive no errors at all but the debugging tools (windbg and kd) are nowhere to be found… The log is next to useless:
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_End: Product: Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_Begin: Product: Redistributable Components for Application Verifier and Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState: Product: Redistributable Components for Application Verifier and Windows Debugging Tools; Installed: Unknown;
Does anyone have any suggestions as to where to start debugging why I am unable to install the debugging tools? Oh, the irony!
jv42
8,5015 gold badges40 silver badges64 bronze badges
asked Jul 19, 2011 at 1:36
Robert KaucherRobert Kaucher
1,8413 gold badges21 silver badges44 bronze badges
If you’re running Windows 7 AND Visual Studio 2010 SP1:
(The previous answer is out of date.)
Here’s the problem according to microsoft: http://support.microsoft.com/kb/2717426
In a nutshell, uninstall these two:
- Microsoft Visual C++ 2010 x86 Redistributable
- Microsoft Visual C++ 2010 x64 Redistributable
Now you should be able to install Windows Debugging Tools via the Windows 7.1 SDK.
Afterward, you may reinstall the Visual c++ 2010 redistributables if you want.
answered Aug 29, 2013 at 21:19
3
If you’re running Windows 7 AND Visual Studio 2010 SP1:
Your installation of the SDK won’t complete properly, due to missing compiler packages that were removed when VS 2010 SP1 was installed. MS has since patched this, so here is your new installation order:
- Install the Windows 7.1 SDK.
- Your installation will only be partially complete after the compiler error. Install the Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1.
- Re-run your Windows SDK web installer. Choose the first option to add features to the existing installation.
- Re-choose (either under redistributables or common) the desired features, including the Debugger Tools.
answered Oct 3, 2011 at 14:53
CasanovaCasanova
1211 silver badge3 bronze badges
You can find the installer packages at (Windows SDK x86 or x64 DVD root)SetupWinSDKDebuggingTools and WinSDKDebuggingTools_amd64. Please use them to install the Debugging Tools.
Note that due to Microsoft’s favourite game of messing up download links and files, you will have to use a search engine to locate the latest download link for the ISO images. I would not track that always in this answer.
answered Jul 19, 2011 at 8:56
Lex LiLex Li
59.4k9 gold badges118 silver badges143 bronze badges
3
After spending hours finding out none of the above works, and only seconds away from smashing my stupid machine to bits, I stumbled upon the solution in SO.
It basically says that for 64-bit Window 7, installing the «Standalone Debugging Tools for Windows 8.1» found here should work.
Unbelievably, it actually did
BTW, the target folder changed to «C:Program Files (x86)Windows Kits8.1»
answered Feb 27, 2014 at 18:36
bavazabavaza
10k10 gold badges63 silver badges100 bronze badges
I faced the same issue and debug message was «Debug Policy is set to 0». After reading the above comments what I did was came up with the minimal package needed for WinDBG install, just by trial and error. The following three packages did the trick.
Debugging Tools for Windows
Windows App Certification
MSI tools
I had a successful install and it worked fine too. I am using Windows 7 64 bit
answered Aug 31, 2016 at 12:28
Santhosh KumarSanthosh Kumar
3591 gold badge5 silver badges12 bronze badges
I’m trying to install the Windows Debugging Tools via the Windows SDK and after two attempts I am at a loss for what to do. I start the installation and receive no errors at all but the debugging tools (windbg and kd) are nowhere to be found… The log is next to useless:
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_End: Product: Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState_Begin: Product: Redistributable Components for Application Verifier and Windows Debugging Tools
9:16:59 PM Monday, July 18, 2011: [SDKSetup:Info] Config_Products_DetermineProductState: Product: Redistributable Components for Application Verifier and Windows Debugging Tools; Installed: Unknown;
Does anyone have any suggestions as to where to start debugging why I am unable to install the debugging tools? Oh, the irony!
- Remove From My Forums
-
Question
-
Hi all,
I am trying to create a dart recovery image with the Crash Analyzer. However when i try to browse to the debugger tools it cannot find it.
I have downloaded the debugging tools as standalone components from http://msdn.microsoft.com/en-us/windows/hardware/hh852363
I now have the following folder: C:Program Files (x86)Windows Kits8.0Debuggers with a x86 folder and a x64
If i browse there during install, it errors
—————————
DaRT Recovery Image Wizard
—————————
Debugging tools are not found in «C:Program Files (x86)Windows Kits8.0Debuggers»
—————————
OK
—————————or
—————————
DaRT Recovery Image Wizard
—————————
Debugging tools are not found in «C:Program Files (x86)Windows Kits8.0Debuggersx64»
—————————
OK
—————————
Answers
-
My guess is that the tools located C:Program Files (x86)Windows Kits8.0Debuggers are not supported with
this version of DART as they are the Windows 8 and below debugging tools and DART is looking for the debugging tools that can be downloaded here http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8442There should be a new version of DART coming out (8.0 I think) that will most likely work with the new debugging tools.
Compro Computers LLC
http://www.eccompro.com-
Marked as answer by
Tuesday, May 27, 2014 10:22 AM
-
Marked as answer by
On the assumption that the installation is actually failing silently, you don’t see Windbg in the Windows Kits program group, and it doesn’t show up when you type «windbg» into the Search Bar:
Turn on Windows Installer Logging
http://support.microsoft.com/kb/223300
To enable Windows Installer logging
To enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys:
HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsInstaller
Reg_SZ: Logging
Value: voicewarmupx
The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:
v - Verbose output
o - Out-of-disk-space messages
i - Status messages
c - Initial UI parameters
e - All error messages
w - Non-fatal warnings
a - Start up of actions
r - Action-specific records
m - Out-of-memory or fatal exit information
u - User requests
p - Terminal properties
+ - Append to existing file
! - Flush each line to the log
x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
"*" - Wildcard, log all information except for the v and the x option. To include the v and the x option, specify "/l*vx".
Note This should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space. Each time you use the Add/Remove Programs tool in Control Panel, a new Msi*.log file is created.
Then install.
You’ll get an option to view the logs at the end.
The best method would be to install the Debugging Tools Redistributables via the SDK, then enable logging and install from the redists, rather than dealing with the multiple logs that will be generated by the SDK Installer.
(You may also want to check %ProgramFiles(x86)%Windows Kits8.1DebuggersRedist and see if you accidentally installed the redistributables instead of the applications.)
- Remove From My Forums
-
Question
-
Okay,
So I am done running in circles. Where is this «Windows Debugging Tools»? I have a rather critical Memory Leak that is crashing at one of our customers. I have found several applications that may or may not help me find this leak but they
are all dependent on this Windows Debugging Tools. I go to the site and there is nothing to download from microsoft. I then see a link to down load it via the Windows SDK. So I download winsdk_web.exe and run it. IN the listing it seems
that the SDK is already partially installed on my system from VS2010. So, I click «Change/Modify» and then select the option «Windows Debugging Tools» and the damn thing crashes saying:A problem occurred while installing selected Windows SDK components.
Setup could not find the file WinSDKNetFxTools\WinSDK_nfxtoolsm_x86.msi at any of the specified source locations http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup
Please attempt to resolve the problem and then start Windows SDK setup again. If you continue to have problems with this issue, please visit the SDK team support page at http://go.microsoft.com/fwlink/?LinkId=130245.
Click the View Log button to review the installation log.
To exit, click Finish.So that first link that it supposedly has for the «NetFXTools» doesn’t exist, there is nothing there.
There is quite a advertisement and description following for these apparently phantom Debugging Tools that apparently never existed in the first place. Where the <Bleep> are they! I have wasted so much time trying to use sos.dll and other
avenues because I don’t have these tools and can’t find them anywhere. If they exist they should be readily available to developers, and if they don’t exist or have been discontinued than the website information darn well ought to be updated instead
of leading develpers like me on thinking there may be a suite of tool that help me resolve tricky situations.(And when i say readily available I mean one file that I can download, not 27 different packages in different locations to get the whole suite)
Extremely Frustrated
Jaeden «Sifo Dyas» al’Raec Ruiner
«Never Trust a computer. Your brain is smarter than any micro-chip.»
PS — Don’t mark answers on other people’s questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it
correct for them often stops other people from even reading the question and possibly providing the real «correct» answer.
Answers
-
This is why I use the ISO version of the SDK. Also, make sure the version you install matches your copy of Windows. So if your copy of Windows is a 32 bit version, install the 32 bit version of the SDK, if it is a 64 bit version then install the x64 version.
If you have an Itanium version of Windows Server, then get the Itanium version, but this is one of the cases where if you don’t know what the Itanium version is, then you don’t have it.
If you want the direct link to the debugging tools themselves, then they are
here.
This is a signature
Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts
is to aid in the learning process.-
Marked as answer by
Monday, February 6, 2012 10:31 PM
-
Marked as answer by
On the assumption that the installation is actually failing silently, you don’t see Windbg in the Windows Kits program group, and it doesn’t show up when you type «windbg» into the Search Bar:
Turn on Windows Installer Logging
http://support.microsoft.com/kb/223300
To enable Windows Installer logging
To enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Value: voicewarmupx
The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:
v - Verbose output
o - Out-of-disk-space messages
i - Status messages
c - Initial UI parameters
e - All error messages
w - Non-fatal warnings
a - Start up of actions
r - Action-specific records
m - Out-of-memory or fatal exit information
u - User requests
p - Terminal properties
+ - Append to existing file
! - Flush each line to the log
x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
"*" - Wildcard, log all information except for the v and the x option. To include the v and the x option, specify "/l*vx".
Note This should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space. Each time you use the Add/Remove Programs tool in Control Panel, a new Msi*.log file is created.
Then install.
You’ll get an option to view the logs at the end.
The best method would be to install the Debugging Tools Redistributables via the SDK, then enable logging and install from the redists, rather than dealing with the multiple logs that will be generated by the SDK Installer.
(You may also want to check %ProgramFiles(x86)%\Windows Kits\8.1\Debuggers\Redist and see if you accidentally installed the redistributables instead of the applications.)