Debugging tools for windows 10 как использовать

Debugging Tools for Windows обновляются и выкладываются в публичный доступ достаточно часто и процесс этот никак не зависит от выпуска операционных систем. Поэтому, периодически проверяйте наличие новых версий.

Давайте теперь посмотрим, что же, в частности, позволяют нам средства Debugging Tools for Microsoft Windows:

Доступны следующие версии Debugging Tools for Windows: 32-bit x86, Intel Itanium, 64-bit x64. Нам потребуются две из них: x86 либо x64.

Доступны несколько способов установки Debugging Tools for Windows, в данной же статье мы будем рассматривать лишь основные из них:

Остается неясен еще во какой момент, зачем мне инсталлировать отладочный инструментарий на компьютер? Зачастую ведь сталкиваешься с ситуацией, когда вмешательство в рабочую среду крайне нежелательно! И уж тем более что инсталляция нового продукта, то есть внесение изменений в реестр/файлы системы, может быть совершенно недопустима. Примерами могут служить критически-важные сервера. Почему бы разработчикам не продумать вариант с портабельными (portable) версиями приложений, не требующих установки?
От версии к версии процесс установки пакета Debugging Tools for Windows претерпевает некоторые изменения. Давайте теперь перейдем непосредственно к процессу установки и рассмотрим способы, которыми можно установить инструментарий.

Переходим на страницу Архив Windows SDK и находим раздел под названием Windows 10 и ниже пункт «Windows 10 SDK (10586) и эмулятор устройства с Windows 10 Mobile (Майкрософт) (версия 10586.11)».

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

После завершения инсталляции Debugging Tools for Windows расположение файлов отладки при данном методе инсталляции у нас будет следующим:

Огромным плюсом данного способа установки Debigging Tools for Windows является установка версий отладочных средств сразу всех архитектур.

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

При работе с сайтом msdn.microsoft.com советую воспользоваться браузером Internet Explorer, поскольку были замечены случаи неработоспособности конкурирующих продуктов!

Далее у нас имеется выбор между тремя вариантами образа:

Имя	Назначение
GRMSDK_EN_DVD.iso	Образ SDK для систем с архитектурой x86 (32-битных).
GRMSDKIAI_EN_DVD.iso	Образ SDK для систем с архитектурой ia64.
GRMSDKX_EN_DVD.iso	Образ SDK для систем с архитектурой x64 (64-битных).

Уже затем двойным щелчком активирую автозагрузку и запускаю инсталляцию Windows SDK:

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

Все именно так, на скриншоте отмечено две опции: «Windows Performance Toolkit» и «Debugging Tools for Windows». Выбирайте обе, потому как Windows Performance Toolkit Вам непременно пригодится в работе! Далее, после нажатия кнопки «Next» инсталляция продолжается в обычном режиме. И в конце вы увидите надпись «Installation Complete».
По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

На этом установку Debugging Tools for Windows можно считать оконченной.

После открытия образа нам необходимо пройти в каталог «Setup», находящийся в корне и далее выбрать одну из директорий:

По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

На этом установку Debugging Tools for Windows можно считать выполненной.

Дополнительные сведения

Не знаю с чем это связано, быть может с моей невнимательностью, но после инсталляции Отладочных средств для Windows, инсталлятор не прописывает в системную переменную пути Path путь к каталогу с отладчиком. Это накладывает определенные ограничения на запуск различных отладочных задач напрямую из консоли. Поэтому, в случае отсутствия пути, я самостоятельно прописываю в окне Переменные среды путь к отладочным средствам:

* В вашем случае пути могут отличаться как по причине использования ОС другой разрядности, так и по причине использования SDK другой версии.

Утилиты пакета Debugging Tools for Windows могут работать в качестве переносных приложений, достаточно просто скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии на рабочем сервере. Но не забывайте учитывать разрядность системы!! Если Вы даже произвели полную инсталляцию пакета на критически-важную систему, то работать можно начинать прямо после инсталляции, перезагрузка не требуется.

И теперь напоследок приведем состав Debugging Tools for Windows:

Источник

Анализ дампов после BSOD с помощью Debugging Tools for Windows

Debugging Tools for Windows – это набор утилит от Microsoft, предназначенный для разработчиков и администраторов. Установщик можно бесплатно скачать по ссылке — http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx. Перед этим, вам нужно выбрать версию ОС, в которой вы будете использовать утилиты.

Если вы разработчик драйверов и используете DDK то Debugging Tools for Windows входит туда, и его установку можно выбрать при установке DDK.

После перехода по ссылке, будет загружен веб установщик, который предложит установить Windows SDK (Software Development Kit), в который входит и Debugging Tools.

В ходе установки, вы можете выбрать только Debugging Tools

После того, как установка завершится, вам нужно найти один из файлов установки Debugging Tools. В моей Windows XP SP3 (x86) файлы установки находятся по пути — C:Program FilesMicrosoft SDKsWindowsv7.1RedistDebugging Tools for Windows. Запускаем файл dbg_x86.msi и выполняем установку.

В моей системе набор программ для отладки Debugging Tools по-умолчанию установился в каталог «C:Program FilesDebugging Tools for Windows (x86)»

Теперь нам необходим фал дампа. О том, где его взять вы можете почитать на главной странице – здесь. Если его нет, вы можете его создать с помощью утилиты NotMyFault. Давайте так и поступим, при этом, в качестве ошибки в драйвере, мы выберем DRIVER_IRQL_NOT_LESS_OR_EQUAL. Запускаем программу, выбираем “Hihg IRQL fault (Kernel-mode)” и нажимаем “Crash”. Поскольку в Windows XP, которую я использую, по-умолчанию тип дампа – малый дамп (смотрите здесь — о типах дампов), файл дампа можно найти в каталоге %Systemroot%minidump (c:windowsminidump).

Среди утилит, которые входят в Debugging Tools есть несколько, с помощью которых можно анализировать файлы дампов:

Одной из самых простых программ является dumpchk.exe. Давайте запустим ее и перенаправим вывод в файл. Мы получим приблизительно следующий результат (см. вложенный файл ниже)

По результатам анализа можно обратить внимание на следующую важную информацию.

1. Код ошибки (стоп-код) и его параметры, в файле — BugCheck 100000D1, .

2. Строку с названием драйвера, который по мнению утилиты, привел к BSOD — Probably caused by : myfault.sys ( myfault+5ab )

3. Драйвера, которые использовались в системе на момент краха, строки вида:

804d7000 806e4000 nt Sun Apr 13 21:31:06 2008 (4802516A)
806e4000 80704d00 hal Sun Apr 13 21:31:27 2008 (4802517F)
b0b90000 b0ba8b00 bthpan Sun Apr 13 21:51:32 2008 (48025634)
b0ba9000 b0beba80 bthport Sun Apr 13 21:46:29 2008 (48025505)

В простейших случаях, уже этого достаточно для того, чтобы сделать выводы относительно причин BSOD – драйвер myfault.sys как раз и используется утилитой NotMyFault, то есть, мы нашли виновника.

Вы должны были также обратить внимание на наличие в отчете строк вида:

Symbol search path is: *** Invalid ***

Your debugger is not using the correct symbols

Symbols can not be loaded because symbol path is not initialized.

Давайте запустим dumpchk.exe с параметром — “y”, который позволяет указать путь к файлам символов.

Если в каталоге c:symbols будут отсутствовать необходимые символы, они будут загружены с сайта Microsoft. Это может занять некоторое время.

Вложенный файл ниже – это результат работы dumpchk.exe с включенной опцией местонахождения символов.

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

analyze –v

Выбираем “File / Open Crash Dump” открываем наш файла малого дампа.

Мы также увидим сообщение о ошибке — “ERROR: Module load completed but symbols could not be loaded for myfault.sys”. Так и должно быть поскольку для этого драйвера файлы символы не представлены. Теперь в строке ввода команд давайте введем:

Мы получи намного больше информации, чем в случае использования dumpchk.exe (см. вложенный файл)

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e2ee9008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: badbc5ab, address which referenced memory

FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]

LAST_CONTROL_TRANSFER: from badbc9db to badbc5ab

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4

FOLLOWUP_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]

Давайте рассмотрим полученную информацию.

1. DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) – это символическое описание ошибки

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

Arg1: e2ee9008, memory referenced (адрес памяти по которому происходило обращение)
Arg2: 00000002, IRQL (уровень IRQL на момент обращения)
Arg3: 00000000, value 0 = read operation, 1 = write operation (тип операции, в нашем случае, это операция чтения)
Arg4: badbc5ab, address which referenced memory (адрес в памяти инструкции, которая выполняла операцию чтения)

FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]
Здесь показана непосредственно инструкция которая выполнялась – операция записи в регистр ecx содержимого по адресу указанному в eax. Эта инструкция находится по адресу myfault+5ab и относится к драйверу myfault.sys (myfault – это имя драйвера).

Это имя процесса пользовательского режима, который выполнялся во время краха.

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4

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

С Ntdll.dll была вызвана функция KiFastCallEntry, которая затем вызвала NtDeviceIoControlFile и т.д., пока при выполнении инструкции по адресу myfault+0x5ab не произошел крах системы.

Анализ данных говорит нам о том, что виновником BSOD был драйвер myfault (myfault.sys)

Если бы мы не использовали символы, у нас была бы следующая информация о стеке

b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c64 805807f7 89668958 898ae698 8936b740 nt+0x1818f
b08f6d00 80579274 00000094 00000000 00000000 nt+0xa97f7
b08f6d34 8054161c 00000094 00000000 00000000 nt+0xa2274
b08f6d64 7c90e4f4 badb0d00 0006f888 b11b2d98 nt+0x6a61c
b08f6d68 badb0d00 0006f888 b11b2d98 b11b2dcc 0x7c90e4f4
b08f6d6c 0006f888 b11b2d98 b11b2dcc 00000000 vmscsi+0xd00
b08f6d70 b11b2d98 b11b2dcc 00000000 00000000 0x6f888
b08f6d74 b11b2dcc 00000000 00000000 00000000 0xb11b2d98
b08f6d78 00000000 00000000 00000000 00000000 0xb11b2dcc

Что менее информативно.

Вообще анализ дампов, кроме самых простых случаев (таких как рассмотренный) требует значительной подготовки и хорошего понимания как работы ОС и драйверов так и владение знанием ассемблера. В открытом доступе можно найти некоторые книги Дмитрия Востокова «Memory Dump Analysis Antology». Если вы их найдете, вы сможете приблизительно оценить уровень автора и приблизительно понять нетривиальность анализа дампов.

Источник

Getting Started with Windows Debugging

This article covers how to get started with Windows Debugging. If your goal is to use the debugger to analyze a crash dump, see Analyze crash dump files by using WinDbg.

To get started with Windows Debugging, complete the tasks that are described in this article.

1. Determine the host and the target

The debugger runs on the host system, and the code that you want to debug runs on the target system.

Host Target

2. Determine the type: kernel-mode or user-mode

Next, you need to determine whether you will do kernel-mode or user-mode debugging.

Kernel mode is the processor-access mode in which the operating system and privileged programs run. Kernel-mode code has permission to access any part of the system, and it is not restricted like user-mode code. Kernel-mode code can gain access to any part of any other process running in either user mode or kernel mode. Much of the core OS functionality and many hardware device drivers run in kernel mode.

User mode is the mode that applications and subsystems on the computer run in. Processes that run in user mode do so within their own virtual address spaces. They are restricted from gaining direct access to many parts of the system, including system hardware, memory that was not allocated for their use, and other portions of the system that might compromise system integrity. Because processes that run in user mode are effectively isolated from the system and other user-mode processes, they cannot interfere with these resources.

If your goal is to debug a driver, determine if the driver is a kernel-mode driver or a user-mode driver. Windows Driver Model (WDM) drivers and Kernel-Mode Driver Framework (KMDF) are both kernel-mode drivers. As the name sugests, User-Mode Driver Framework (UMDF) drivers are user-mode drivers.

For some issues, it can be difficult to determine which mode the code executes in. In that case, you may need to pick one mode and look to see what information is available in that mode. Some issues require using the debugger in both user mode and kernel mode.

Depending on what mode you decide to debug in, you will need to configure and use the debuggers in different ways. Some debugging commands operate the same in both modes, and some commands operate differently in different modes.

For information about using the debugger in kernel mode, see the following articles:

For information about using the debugger in user mode, see Getting started with WinDbg (user-mode).

3. Choose your debugger environment

WinDbg works well in most situations, but there are times when you may want to use another debugger, such as console debuggers for automation or Visual Studio. For more information, see Debugging environments.

4. Determine how to connect the target and host

Typically, target and host systems are connected by an Ethernet network. If you are doing early bring-up work, or you don’t have an Ethernet connection on a device, other network connection options are available. For more information, see these articles:

5. Choose either the 32-bit or 64-bit debugging tools

Which debugging tools to choose—32-bit or 64-bit—depends on the version of Windows that is running on the target and host systems and on whether you are debugging 32-bit or 64-bit code. For more information, see Choosing the 32-Bit or 64-Bit debugging tools.

6. Configure symbols

To use all of the advanced functionality that WinDbg provides, you must load the proper symbols. If you do not have symbols properly configured, you will receive messages indicating that symbols are not available when you attempt to use functionality that is dependent on symbols. For more information, see Symbols for Windows debugging (WinDbg, KD, CDB, NTSD).

7. Configure source code

If your goal is to debug your own source code, you will need to configure a path to your source code. For more information, see Source path.

8. Become familiar with debugger operation

The Debugger operation section of this documentation describes debugger operation for various tasks. For example, Loading debugger extension DLLs explains how to load debugger extensions. To learn more about working with WinDbg, see Debugging using WinDbg.

9. Become familiar with debugging techniques

Standard debugging techniques apply to most debugging scenarios, and examples include setting breakpoints, inspecting the call stack, and finding a memory leak. Specialized debugging techniques apply to particular technologies or types of code. Examples include Plug and Play debugging, KMDF debugging, and RPC debugging.

10. Use the debugger reference commands

Over time, you will use different debugging commands as you work in the debugger. Use the .hh (open HTML help file) command in the debugger to display help information about any debugging command. For more information about the available commands, see Debugger reference.

11. Use debugging extensions for specific technologies

There are multiple debugging extensions that provide parsing of domain-specific data structures. For more information, see Specialized extensions.

This documentation assumes a knowledge of Windows internals. To learn more about Windows internals (including memory usage, context, threads, and processes), review additional resources, such as Windows Internals by Mark Russinovich, David Solomon, and Alex Ionescu.

13. Review additional debugging resources

Additional resources include the following books and videos:

Источник

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

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

Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

• Мини дамп памяти (Small memory dump) (256 КБ). Этот тип файла включает минимальный объем информации. Он содержит только сообщение об ошибке BSOD, информацию о драйверах, процессах, которые были активны в момент сбоя, а также какой процесс или поток ядра вызвал сбой.
• Дамп памяти ядра (Kernel memory dump). Как правило, небольшой по размеру — одна треть объема физической памяти. Дамп памяти ядра является более подробным, чем мини дамп. Он содержит информацию о драйверах и программах в режиме ядра, включает память, выделенную ядру Windows и аппаратному уровню абстракции (HAL), а также память, выделенную драйверам и другим программам в режиме ядра.
• Полный дамп памяти (Complete memory dump). Самый большой по объему и требует памяти, равной оперативной памяти вашей системы плюс 1MB, необходимый Windows для создания этого файла.
• Автоматический дамп памяти (Automatic memory dump). Соответствует дампу памяти ядра с точки зрения информации. Отличается только тем, сколько места он использует для создания файла дампа. Этот тип файлов не существовал в Windows 7. Он был добавлен в Windows 8.
• Активный дамп памяти (Active memory dump). Этот тип отсеивает элементы, которые не могут определить причину сбоя системы. Это было добавлено в Windows 10 и особенно полезно, если вы используете виртуальную машину, или если ваша система является хостом Hyper-V.

Как включить создание дампа памяти в Windows?

С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы» (Advanced system settings). Во вкладке «Дополнительно» (Advanced), раздел «Загрузка и восстановление» (Startup and Recovery) нажмите кнопку «Параметры» (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал» (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа» (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).

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

Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger).

Установка WinDBG в Windows

Утилита WinDBG входит в «Пакет SDK для Windows 10» (Windows 10 SDK). Скачать можно здесь.

Файл называется winsdksetup.exe, размер 1,3 МБ.

WinDBG для Windows7 и более ранних систем включен в состав пакета «Microsoft Windows SDK for Windows 7 and .NET Framework 4». Скачать можно здесь.

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

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации .dmp файлов с WinDBG

Для того, чтобы открывать файлы дампов простым кликом, сопоставьте расширение .dmp с утилитой WinDBG.

1. Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы:
   cd C:Program Files (x86)Windows Kits10Debuggersx64
windbg.exe –IA
   
   для 32-разрядной системы:
   C:Program Files (x86)Windows Kits10Debuggersx86
windbg.exe –IA
2. В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.

Настройка сервера отладочных символов в WinDBG

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

• Откройте WinDBG;
• Перейдите в меню File –> Symbol File Path;
• Пропишите строку, содержащую URL для загрузки символов отладки с сайта Microsoft и папку для сохранения кэша:
  SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols
  В примере кэш загружается в папку E:Sym_WinDBG, можете указать любую.
• Не забывайте сохранить изменения в меню File –> Save WorkSpace;

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

SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:Symbols

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.

Анализ аварийного дампа памяти в WinDBG

Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.

Команды вводятся в командную строку, расположенную внизу окна.

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.

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

Отладчик предлагает выполнить команду !analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?

• Она выполняет предварительный анализ дампа памяти и предоставляет подробную информацию для начала анализа.
• Эта команда отобразит STOP-код и символическое имя ошибки.
• Она показывает стек вызовов команд, которые привели к аварийному завершению.
• Кроме того, здесь отображаются неисправности IP-адреса, процессов и регистров.
• Команда может предоставить готовые рекомендации по решению проблемы.

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !analyze –v (листинг неполный).

1: kd>
!analyze -v

*****************************************************************************
* *
* Bugcheck Analysis *
* *
*****************************************************************************

Символическое имя STOP-ошибки (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)

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

A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.

Аргументы ошибки:

Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
------------------

Счетчик показывает сколько раз система упала с аналогичной ошибкой:

CUSTOMER_CRASH_COUNT: 1

Основная категория текущего сбоя:

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Код STOP-ошибки в сокращенном формате:

BUGCHECK_STR: 0x139

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

PROCESS_NAME: sqlservr.exe

CURRENT_IRQL: 2

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9 : 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528 : nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50 : ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2 : nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482 : ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9 : nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d : 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951 : nt! ?? ::FNODOBFM::`string'+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac : 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600 : nt!IopSynchronousServiceTail+0x379
ffffd000`3a20d990 fffff804`0117d313 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380 : nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
000000ee`f25ed2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`475307da

Участок кода, где возникла ошибка:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr [rsp+20h],0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: MachineOwner

Имя модуля в таблице объектов ядра. Если анализатору удалось обнаружить проблемный драйвер, имя отображается в полях MODULE_NAME и IMAGE_NAME:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

Если кликнете по ссылке модуля (nt), то увидите подробную информацию о пути и других свойствах модуля. Находите указанный файл, и изучаете его свойства.

1: kd>
lmvm nt

Browse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C:ProgramDatadbgsymntoskrnl.exe5A9A2147787000ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Например:

Image path: SystemRootsystem32driverscmudaxp.sys
Image name: cmudaxp.sys

Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.

Анализ аварийных дампов Windows

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

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

Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).

Содержание

Анализ аварийного дампа утилитой BlueScreenView

Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.

BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.

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

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

По двойному клику отображается дополнительная информация.

Анализ аварийного дампа отладчиком WinDbg

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

Установка Debugging Tools for Windows (WinDbg)

Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки.

Для анализа аварийных дампов установка SDK не требуется. Скачать Debugging Tools for Windows (WinDbg) отдельным пакетом можно здесь.

После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%Minidump.

Настройка отладочных символов

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

При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.

Следующей строкой включаем загрузку отладочных символов из сети, задаем локальный путь для сохранения файлов и адрес для загрузки из интернета:

Анализ аварийного дампа

В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.

Указываем путь к дампу %SystemRoot%MEMORY.DMP или %SystemRoot%Minidumpфайл.dmp.

Загрузка отладочных символов из интернета может занять некоторое время.

Для получения детальной информации выполняем команду:

Дебаггер сам вам предложит ее выполнить, достаточно навести указатель мыши на ссылку и кликнуть.

В результате получаем следующий вывод:

Получение информации о проблемном драйвере

Если удалось обнаружить драйвер, в котором возникла ошибка, имя драйвера будет отображено в полях MODULE_NAME и IMAGE_NAME.

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%system32drivers.

Находим указанный файл, и изучаем его свойства.

Обновляем проблемный драйвер.

Аппаратные причины возникновения критических ошибок

Источником критических ошибок нередко бывают неисправности в дисковой подсистеме, или в подсистеме памяти.

Диагностика неисправностей диска

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

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

Проверяем параметры S.M.A.R.T жесткого диска, получить их можно, например, с помощью программы SpeedFan.

Особое внимание обращаем на параметры: «Current Pending Sector Count» и «Uncorrectable Sector Count», ненулевые значения этих параметров сигнализируют о неисправности диска.

Ненулевое значение параметра: «UltraDMA CRC Error Count», сигнализирует о проблеме с SATA-кабелем.

Подробнее о параметрах S.M.A.R.T. читаем в статье Википедии.

Диагностика неисправностей памяти

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

Выявить проблемы с памятью можно с помощью утилиты Memtest86+.

Загружаем образ по ссылке, записываем на диск, загружаемся с диска, запускается тест.

Начиная с Windows Vista, в системе имеется свой тест памяти. Для его запуска нажимаем «Пуск», в строке поиска набираем «памяти«, выбираем «Средство диагностики памяти Windows».

Проблемы с памятью в некоторых случаях могут быть устранены обновлением BIOS.

Настройка параметров сохранения аварийного дампа

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

Debugging Tools for Windows — Инструменты отладки кода операционных систем Windows. Представляют собой набор свободно распространяемых программ от Microsoft, предназначенных для отладки кода пользовательского режима и режима ядра: приложений, драйверов, служб, модулей ядра. В состав инструментария входят отладчики консольного и GUI- режимов, утилиты для работы с символами, файлами, процессами, утилиты для обеспечения удаленной отладки. Инструментарий содержит в себе утилиты, с помощью которых можно находить причины сбоев в различных компонентах системы. Debugging Tools for Windows с определенного момента недоступны для скачивания в форме автономного дистрибутива и входят в состав Windows SDK (Windows Software Development Kit). Набор инструментальных средств Windows SDK, в свою очередь, доступен в виде части программы подписки MSDN или же может быть свободно загружен в качестве отдельного дистрибутива с сайта msdn.microsoft.com. По заявлению разработчиков, последняя и самая актуальная версия Debugging Tools for Windows содержится именно в Windows SDK.

Debugging Tools for Windows обновляются и выкладываются в публичный доступ достаточно часто и процесс этот никак не зависит от выпуска операционных систем. Поэтому, периодически проверяйте наличие новых версий.

Давайте теперь посмотрим, что же, в частности, позволяют нам средства Debugging Tools for Microsoft Windows:

• Отлаживать локальные приложения, службы (сервисы), драйвера и ядро;
• Отлаживать по сети удаленные приложения, службы (сервисы), драйвера и ядро;
• Отлаживать работающие приложения в режиме реального времени;
• Анализировать файлы дампов памяти приложений, ядра и системы в целом;
• Работать с системами на базе архитектур x86/x64/Itanium;
• Отлаживать программы пользовательского режима и режима ядра;

Доступны следующие версии Debugging Tools for Windows: 32-bit x86, Intel Itanium, 64-bit x64. Нам потребуются две из них: x86 либо x64.

Доступны несколько способов установки Debugging Tools for Windows, в данной же статье мы будем рассматривать лишь основные из них:

• Установка посредством web-инсталлятора.
• Установка Debugging Tools for Windows с ISO-образа Windows SDK.
• Установка Debugging Tools for Windows непосредственно из пакетов dbg_amd64.msi / dbg_x86.msi .

Остается неясен еще во какой момент, зачем мне инсталлировать отладочный инструментарий на компьютер? Зачастую ведь сталкиваешься с ситуацией, когда вмешательство в рабочую среду крайне нежелательно! И уж тем более что инсталляция нового продукта, то есть внесение изменений в реестр/файлы системы, может быть совершенно недопустима. Примерами могут служить критически-важные сервера. Почему бы разработчикам не продумать вариант с портабельными (portable) версиями приложений, не требующих установки?
От версии к версии процесс установки пакета Debugging Tools for Windows претерпевает некоторые изменения. Давайте теперь перейдем непосредственно к процессу установки и рассмотрим способы, которыми можно установить инструментарий.

Переходим на страницу Архив Windows SDK и находим раздел под названием Windows 10 и ниже пункт «Windows 10 SDK (10586) и эмулятор устройства с Windows 10 Mobile (Майкрософт) (версия 10586.11)».

Щелкаем по пункту УСТАНОВИТЬ ПАКЕТ SDK . После щелчка скачиваем и запускаем файл sdksetup.exe , который и инициирует процесс онлайн-установки Windows SDK. На начальном этапе инсталятор проверит наличие в системе установленного пакета .NET Framework последней версии (в данный момент это 4.5). Если пакет отсутствует, что будет предложена установка и по окончании выполнена перезагрузка станции. Сразу после перезагрузки, на этапе авторизации пользователя, стартует процесс инсталляции уже непосредственно Windows SDK.

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

После завершения инсталляции Debugging Tools for Windows расположение файлов отладки при данном методе инсталляции у нас будет следующим:

• 64-битные версии: C:Program Files (x86)Windows Kitsx.xDebuggersx64
• 32-битные версии: C:Program Files (x86)Windows Kitsx.xDebuggersx86

* где x.x — определенная версия комплекта разработки;
Заметили, что версии 8 и выше, пути инсталляции заметно отличаются от классических для всех предыдущих версий средств отладки?

Огромным плюсом данного способа установки Debigging Tools for Windows является установка версий отладочных средств сразу всех архитектур.

Данный метод подразумевает установку Debugging Tools for Windows с использованием полного инсталляционного образа Windows SDK (Software Developers Kit). До определенного времени, скачать образ ISO для соответствующей системы можно было на странице Архив Windows SDK. Однако, в данный момент, получить ISO-образ SDK можно через запуск web-инсталлятора sdksetup.exe , и выбора пункта Download the Windows Software Development Kit в стартовом окне инсталлятора:

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

Соответственно, на странице необходимо подобрать требуемый дистрибутив, для меня (да и думаю для многих) в данный момент это «Пакет Windows SDK для Windows 7 и .NET Framework 4» и чуть ниже нажать на ссылку «Получить ISO-образ DVD-диска».

При работе с сайтом msdn.microsoft.com советую воспользоваться браузером Internet Explorer, поскольку были замечены случаи неработоспособности конкурирующих продуктов!

Далее у нас имеется выбор между тремя вариантами образа:

Имя	Назначение
GRMSDK_EN_DVD.iso	Образ SDK для систем с архитектурой x86 (32-битных).
GRMSDKIAI_EN_DVD.iso	Образ SDK для систем с архитектурой ia64.
GRMSDKX_EN_DVD.iso	Образ SDK для систем с архитектурой x64 (64-битных).

Соответственно, необходимо выбрать исключительно по необходимости. Обычно разрядность Debugging Tools for Windows совпадает с разрядностью системы. У меня исследуемые системы, в основном, 64-битные, поэтому я в большинстве случаев скачиваю образ для 64-битной системы GRMSDKX_EN_DVD.iso .
Затем, после скачивания образа, нам необходимо с имеющимся ISO-образом как-то работать. Традиционным способом является, конечно же, запись компакт-диска, но ведь это достаточно долгий и иногда затратный метод. Предлагаю воспользоваться бесплатными утилитами по созданию в системе виртуальных дисковых устройств. Лично я для этой цели предпочитаю пользоваться программой DEAMON Tools Lite. У кого-то могут быть и другие предпочтения, более прямые или легковесные утилиты, на вкус и цвет, как говорится.. После инсталляции DAEMON Tools Lite, я просто щелкаю два раза на файл образа GRMSDKX_EN_DVD.iso и в системе у меня появляется новый виртуальный компакт диск:

Уже затем двойным щелчком активирую автозагрузку и запускаю инсталляцию Windows SDK:

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

Все именно так, на скриншоте отмечено две опции: «Windows Performance Toolkit» и «Debugging Tools for Windows». Выбирайте обе, потому как Windows Performance Toolkit Вам непременно пригодится в работе! Далее, после нажатия кнопки «Next» инсталляция продолжается в обычном режиме. И в конце вы увидите надпись «Installation Complete».
По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

• Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
• Для версии x64: C:Program FilesDebugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать оконченной.

В случае возникновения проблем при инсталляции Debugging Tools for Windows двумя предыдущими способами, у нас в запасе остается еще один, самый надежный и проверенный временем, выручавший, так сказать, не раз. Когда-то, до интеграции в Windows SDK, Debugging Tools for Windows были доступны в виде отдельного инсталлятора .msi, который и сейчас можно найти, однако уже в недрах дистрибутива Windows SDK. Поскольку у нас на руках имеется уже ISO-образ Windows SDK, то мы можем не монтировать его в систему, а просто открыть при помощи всем уже хорошо знакомого архиватора WinRAR, ну или любого другого продукта, работающего с содержимым ISO-дисков.

После открытия образа нам необходимо пройти в каталог «Setup», находящийся в корне и далее выбрать одну из директорий:

• Для установки 64-битной версии: SetupWinSDKDebuggingTools_amd64 и распаковать из этого каталога файл dbg_amd64.msi .
• Для установка 32-битной версии: SetupWinSDKDebuggingTools и распаковать из этого каталога файл dbg_x86.msi .

Далее, запускаем распакованный только что .msi файл и стартуем установку Debugging Tools for Windows.

По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

• Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
• Для версии x64: C:Program FilesDebugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать выполненной.

Дополнительные сведения

Не знаю с чем это связано, быть может с моей невнимательностью, но после инсталляции Отладочных средств для Windows, инсталлятор не прописывает в системную переменную пути Path путь к каталогу с отладчиком. Это накладывает определенные ограничения на запуск различных отладочных задач напрямую из консоли. Поэтому, в случае отсутствия пути, я самостоятельно прописываю в окне Переменные среды путь к отладочным средствам:

• C:Program Files (x86)Windows Kits10Debuggersx86
• C:Program Files (x86)Windows Kits10Debuggersx64

* В вашем случае пути могут отличаться как по причине использования ОС другой разрядности, так и по причине использования SDK другой версии.

Утилиты пакета Debugging Tools for Windows могут работать в качестве переносных приложений, достаточно просто скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии на рабочем сервере. Но не забывайте учитывать разрядность системы!! Если Вы даже произвели полную инсталляцию пакета на критически-важную систему, то работать можно начинать прямо после инсталляции, перезагрузка не требуется.

И теперь напоследок приведем состав Debugging Tools for Windows:

Debugging Tools for Windows — Инструменты отладки кода операционных систем Windows. Представляют собой набор свободно распространяемых программ от Microsoft, предназначенных для отладки кода пользовательского режима и режима ядра: приложений, драйверов, служб, модулей ядра. В состав инструментария входят отладчики консольного и GUI- режимов, утилиты для работы с символами, файлами, процессами, утилиты для обеспечения удаленной отладки. Инструментарий содержит в себе утилиты, с помощью которых можно находить причины сбоев в различных компонентах системы. Debugging Tools for Windows с определенного момента недоступны для скачивания в форме автономного дистрибутива и входят в состав Windows SDK (Windows Software Development Kit). Набор инструментальных средств Windows SDK, в свою очередь, доступен в виде части программы подписки MSDN или же может быть свободно загружен в качестве отдельного дистрибутива с сайта msdn.microsoft.com. По заявлению разработчиков, последняя и самая актуальная версия Debugging Tools for Windows содержится именно в Windows SDK.

Debugging Tools for Windows обновляются и выкладываются в публичный доступ достаточно часто и процесс этот никак не зависит от выпуска операционных систем. Поэтому, периодически проверяйте наличие новых версий.

Давайте теперь посмотрим, что же, в частности, позволяют нам средства Debugging Tools for Microsoft Windows:

• Отлаживать локальные приложения, службы (сервисы), драйвера и ядро;
• Отлаживать по сети удаленные приложения, службы (сервисы), драйвера и ядро;
• Отлаживать работающие приложения в режиме реального времени;
• Анализировать файлы дампов памяти приложений, ядра и системы в целом;
• Работать с системами на базе архитектур x86/x64/Itanium;
• Отлаживать программы пользовательского режима и режима ядра;

Доступны следующие версии Debugging Tools for Windows: 32-bit x86, Intel Itanium, 64-bit x64. Нам потребуются две из них: x86 либо x64.

Доступны несколько способов установки Debugging Tools for Windows, в данной же статье мы будем рассматривать лишь основные из них:

• Установка посредством web-инсталлятора.
• Установка Debugging Tools for Windows с ISO-образа Windows SDK.
• Установка Debugging Tools for Windows непосредственно из пакетов dbg_amd64.msi/dbg_x86.msi.

Остается неясен еще во какой момент, зачем мне инсталлировать отладочный инструментарий на компьютер? Зачастую ведь сталкиваешься с ситуацией, когда вмешательство в рабочую среду крайне нежелательно! И уж тем более что инсталляция нового продукта, то есть внесение изменений в реестр/файлы системы, может быть совершенно недопустима. Примерами могут служить критически-важные сервера. Почему бы разработчикам не продумать вариант с портабельными (portable) версиями приложений, не требующих установки?
От версии к версии процесс установки пакета Debugging Tools for Windows претерпевает некоторые изменения. Давайте теперь перейдем непосредственно к процессу установки и рассмотрим способы, которыми можно установить инструментарий.

Установка Debugging Tools for Windows при помощи web-инсталлятора

Переходим на страницу Архив Windows SDK и находим раздел под названием Windows 10 и ниже пункт «Windows 10 SDK (10586) и эмулятор устройства с Windows 10 Mobile (Майкрософт) (версия 10586.11)».

Щелкаем по пункту УСТАНОВИТЬ ПАКЕТ SDK. После щелчка скачиваем и запускаем файл sdksetup.exe, который и инициирует процесс онлайн-установки Windows SDK. На начальном этапе инсталятор проверит наличие в системе установленного пакета .NET Framework последней версии (в данный момент это 4.5). Если пакет отсутствует, что будет предложена установка и по окончании выполнена перезагрузка станции. Сразу после перезагрузки, на этапе авторизации пользователя, стартует процесс инсталляции уже непосредственно Windows SDK.

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

После завершения инсталляции Debugging Tools for Windows расположение файлов отладки при данном методе инсталляции у нас будет следующим:

• 64-битные версии: C:Program Files (x86)Windows Kitsx.xDebuggersx64
• 32-битные версии: C:Program Files (x86)Windows Kitsx.xDebuggersx86

* где x.x — определенная версия комплекта разработки;
Заметили, что версии 8 и выше, пути инсталляции заметно отличаются от классических для всех предыдущих версий средств отладки?

Огромным плюсом данного способа установки Debigging Tools for Windows является установка версий отладочных средств сразу всех архитектур.

Установка Debugging Tools for Windows с ISO-образа Windows SDK

Данный метод подразумевает установку Debugging Tools for Windows с использованием полного инсталляционного образа Windows SDK (Software Developers Kit). До определенного времени, скачать образ ISO для соответствующей системы можно было на странице Архив Windows SDK. Однако, в данный момент, получить ISO-образ SDK можно через запуск web-инсталлятора sdksetup.exe, и выбора пункта Download the Windows Software Development Kit в стартовом окне инсталлятора:

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

Соответственно, на странице необходимо подобрать требуемый дистрибутив, для меня (да и думаю для многих) в данный момент это «Пакет Windows SDK для Windows 7 и .NET Framework 4» и чуть ниже нажать на ссылку «Получить ISO-образ DVD-диска».

При работе с сайтом msdn.microsoft.com советую воспользоваться браузером Internet Explorer, поскольку были замечены случаи неработоспособности конкурирующих продуктов!

Далее у нас имеется выбор между тремя вариантами образа:

Соответственно, необходимо выбрать исключительно по необходимости. Обычно разрядность Debugging Tools for Windows совпадает с разрядностью системы. У меня исследуемые системы, в основном, 64-битные, поэтому я в большинстве случаев скачиваю образ для 64-битной системы GRMSDKX_EN_DVD.iso.
Затем, после скачивания образа, нам необходимо с имеющимся ISO-образом как-то работать. Традиционным способом является, конечно же, запись компакт-диска, но ведь это достаточно долгий и иногда затратный метод. Предлагаю воспользоваться бесплатными утилитами по созданию в системе виртуальных дисковых устройств. Лично я для этой цели предпочитаю пользоваться программой DEAMON Tools Lite. У кого-то могут быть и другие предпочтения, более прямые или легковесные утилиты, на вкус и цвет, как говорится.. После инсталляции DAEMON Tools Lite, я просто щелкаю два раза на файл образа GRMSDKX_EN_DVD.iso и в системе у меня появляется новый виртуальный компакт диск:

Уже затем двойным щелчком активирую автозагрузку и запускаю инсталляцию Windows SDK:

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

Все именно так, на скриншоте отмечено две опции: «Windows Performance Toolkit» и «Debugging Tools for Windows». Выбирайте обе, потому как Windows Performance Toolkit Вам непременно пригодится в работе! Далее, после нажатия кнопки «Next» инсталляция продолжается в обычном режиме. И в конце вы увидите надпись «Installation Complete».
По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

• Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
• Для версии x64: C:Program FilesDebugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать оконченной.

Установка Debugging Tools for Windows через .msi файл

В случае возникновения проблем при инсталляции Debugging Tools for Windows двумя предыдущими способами, у нас в запасе остается еще один, самый надежный и проверенный временем, выручавший, так сказать, не раз. Когда-то, до интеграции в Windows SDK, Debugging Tools for Windows были доступны в виде отдельного инсталлятора .msi, который и сейчас можно найти, однако уже в недрах дистрибутива Windows SDK. Поскольку у нас на руках имеется уже ISO-образ Windows SDK, то мы можем не монтировать его в систему, а просто открыть при помощи всем уже хорошо знакомого архиватора WinRAR, ну или любого другого продукта, работающего с содержимым ISO-дисков.

После открытия образа нам необходимо пройти в каталог «Setup», находящийся в корне и далее выбрать одну из директорий:

• Для установки 64-битной версии: SetupWinSDKDebuggingTools_amd64 и распаковать из этого каталога файл dbg_amd64.msi.
• Для установка 32-битной версии: SetupWinSDKDebuggingTools и распаковать из этого каталога файл dbg_x86.msi.

Далее, запускаем распакованный только что .msi файл и стартуем установку Debugging Tools for Windows.

По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

• Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
• Для версии x64: C:Program FilesDebugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать выполненной.

Дополнительные сведения

Не знаю с чем это связано, быть может с моей невнимательностью, но после инсталляции Отладочных средств для Windows, инсталлятор не прописывает в системную переменную пути Path путь к каталогу с отладчиком. Это накладывает определенные ограничения на запуск различных отладочных задач напрямую из консоли. Поэтому, в случае отсутствия пути, я самостоятельно прописываю в окне Переменные среды путь к отладочным средствам:

• C:Program Files (x86)Windows Kits10Debuggersx86
• C:Program Files (x86)Windows Kits10Debuggersx64

* В вашем случае пути могут отличаться как по причине использования ОС другой разрядности, так и по причине использования SDK другой версии.

Утилиты пакета Debugging Tools for Windows могут работать в качестве переносных приложений, достаточно просто скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии на рабочем сервере. Но не забывайте учитывать разрядность системы!! Если Вы даже произвели полную инсталляцию пакета на критически-важную систему, то работать можно начинать прямо после инсталляции, перезагрузка не требуется.

Состав Debugging Tools for Windows

И теперь напоследок приведем состав Debugging Tools for Windows:

Где скачать и как установить Debugging Tools for Windows

Такие типы сбоев обычно связаны со сбойным драйвером, который бывает трудно вычислить. Тем не менее, улучшенная система отслеживания ошибок в Windows Vista (и не только в Vista!) нередко может привести вас к проблемному файлу. В результате чего большинство людей перестает судорожно пытаться работать на нестабильном компьютере, с параноидальной регулярностью сохраняя документы и надеясь на лучшее.

При сбоях Windows обычно создается так называемый “дамп памяти”. Последний можно исследовать с помощью бесплатного отладочного инструмента Windows Debugging Tools, который может направить вас на источник проблемы. Поэтому, все, что вам необходимо сделать, это:

Скачать себе отладочный инструмент

Скачать Windows Debugging Tools можно непосредственно с сайта Microsoft. Программа работает с множеством операционных систем, начиная с Windows NT 4 и оканчивая Windows 2008, поэтому проблем с ней у вас возникнуть не должно. Да, нельзя сказать, что она стабильна под Windows 7 RC, однако по нашим тестам все-таки работает. Поэтому даже попытка диагностирования проблемы из под Windows 7 RC может оказаться удачной.

Сконфигурировать свою систему

Необходимо, чтобы во время сбоев ваш компьютер создавал дампы памяти, которые в дальнейшей послужат источником информации для отладчика. Поэтому важно, чтобы Windows была настроена на генерацию дампов. Чтобы настроить свою операционную систему, кликните правой кнопкой мыши по Своему компьютеру (Computer) и выберите Свойства (Properties). Затем кликните по вкладке дополнительных параметров Дополнительно (Advanced System Settings), на ней найдите подраздел Загрузка и Восстановление системы (Startup and Recovery Settings) и убедитесь, что параметр Запись отладочной информации (Write debugging information) установлен в состояние Дамп памяти ядра (Kernel memory dump) или Полный дамп памяти (Complete memory dump).

Далее кликните Пуск (Start), перейдите в Программы (All Programs), выберите Debugging Tools и запустите WinDbg. В программе пройдите в меню File и выберите Symbol File Path… Затем напишите в открывшемся окне следующую строку:

SRV*c:symbols*http://msdl.microsoft.com/download/symbols

Последняя определяет путь к специальным данным — так называемым “символам” (symbols), которые могут помочь отладочному инструменту в опознании вашего сбойного файла.

После ввода строки, кликните по кнопке OK. В последствии при работе с отладчиком эта строка вызовет скачивание символов с msdl.microsoft.com и сохранение их в папку c:symbols.

Далее еще раз кликните по меню File, выберите Exit и подтвердите сохранение своей рабочей области (имеется в виду пути к символам) нажатием кнопки Yes.

Решить свою проблему

Теперь подождите очередного сбоя с синим экраном, и последующего окончания перезагрузки компьютера. Затем еще раз запустите WinDbg (пользователям Vista необходимо запускать программу от имени администратора), кликните по меню File, выберите открытие сбойного дампа Open Crash Dump, откройте файл WindowsMEMORY.DMP, и программа незамедлительно начнет его анализировать.

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

 

Впрочем, обычно результат получается уже через несколько минут. Об этом свидетельствует строка анализатора ошибки Bugcheck Analysis, сообщающая нечто вроде «Probably caused by: UACReplace.sys». В переводе на русский это означает, что проблема, возможно, вызвана файлом UACReplace.sys. Введите его в строку поиска, например, Google и вы узнаете его реальное происхождение. В частности, если он принадлежит одной из установленных вами программ или установленному драйверу, то вы можете просто попытаться обновить ее или его. Возможно, это решит возникшие у вас проблемы.

Надо сказать, что время от времени WinDbg не может назвать имени файла совсем или просто выбирает одну из DLL-библиотек Windows. Если это произошло и у вас, то просто кликните по командному окну над панелью статуса и наберите команду:

!analyze –v

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

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

Debugging tools for windows

В настройках системы

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

1. Окно «Параметры» запускается очень легко — с помощью сочетания клавиш Win I. Если вдруг комбинация не сработает на вашем устройстве, откройте панель «Пуск», через которую вы отключаете ПК, и щёлкните по шестерёнке (она ведёт как раз в это же окно).
   
2. На начальной странице окна будет несколько плиток. Обращаем внимание на конец списка. Кликаем сразу по разделу «Обновление и безопасность».
   
3. На следующей странице нам понадобится вторая с конца вкладка «Для разработчиков». Здесь необходимо уже активировать наш «Режим разработчика» с помощью одного щелчка по соответствующему значению.
   
4. Система выдаст сообщение с предупреждением. В нём нужно щёлкнуть по «Да», чтобы подтвердить намерение активировать среду для программистов.
   
5. Ждём, когда ОС загрузит все компоненты для стабильной работы режима. В результате под пунктом появится уведомление об успешной активации.
6. После этого можно сделать перезапуск ПК. Это обязательно, так как без перезагрузки не все параметры будут доступны для изменения. Об этом будет сказано в сообщении под пунктом: «Некоторые функции могут не работать до перезапуска устройства».
   

В системном окне «редактор локальной групповой политики»

Метод активации в этом редакторе довольно простой. Как добраться до нужных параметров в нём, расскажем в инструкции:

1. Вызывается окно этого редактора по аналогии с запуском «Редактора реестра», то есть через окно «Выполнить». Однако в этом случаем вставляем код gpedit.msc. Затем, жмём на Enter на клавиатуре либо на ОК в окошке, чтобы введённая команда выполнилась.
   
2. В редакторе сразу дважды щёлкаем по блоку «Конфигурация компьютера».
   
3. Теперь вам необходимо один за другим запустить три меню со следующими названиями: «Административные шаблоны» — «Компоненты Windows» — «Развёртывание пакета приложений».
   
4. Появится небольшой перечень доступных функций. Второй пункт в перечне должен нас заинтересовать в первую очередь. Двойным щелчком запускаем её.
   
5. В сером окошке, которое открылось поверх редактора, ставим круглую отметку слева от значения «Включено». Чтобы изменения начали действовать, жмём на «Применить», а потом на ОК — дополнительное окно исчезнет.
   
6. Затем переходим в ещё одну опцию, посвящённую инсталляции всех доверенных приложений. Здесь также устанавливаем значение «Включено» и применяем изменённые параметры.
   
7. Закрываем все окна и перезапускаем устройство. Компьютер загрузится в «Режиме разработчика».

Версии

Версии Microsoft Windows
Дата выхода	Название	Последняя версия	Дата прекращения поддержки	Последняя версия встроенного браузера
20 ноября 1985	Windows 1.0x	1.04 (апрель 1987)	31 декабря 2001	Нет браузеров
1 ноября 1987	Windows 2.x Windows 2.1x	2.11 (13 марта 1989)	31 декабря 2001
22 мая 1990	Windows 3.x	3.00a (31 октября 1990)	31 декабря 2001
18 марта 1992	Windows 3.1	3.1	31 декабря 2001	Internet Explorer 5
1 октября 1992	Windows для рабочих групп 3.1	3.11 (31 декабря 1993)	31 декабря 2001
27 июля 1993	Windows NT 3.1	3.10.528 SP3 (10 ноября 1994)	31 декабря 2001
21 сентября 1994	Windows NT 3.5	3.50.807 SP3 (21 июня 1995)	31 декабря 2001
30 мая 1995	Windows NT 3.51	3.51.1057 SP5 (19 сентября 1996)	31 декабря 2001
24 августа 1995	Windows 95	4.00.950C (4.03.1214) (26 ноября 1997)	31 декабря 2000 (осн.) (Retail); 31 декабря 2001 (SBL) (ext)	Internet Explorer 5.5
29 июля 1996	Windows NT 4.0	4.00.1381 / SP6a SRP (26 июля 2001)	20 июня 2002 (осн.); 30 июня 2003 (SBL); 31 декабря 2004 (ext)	Internet Explorer 6
25 июня 1998	Windows 98	4.10.2222A (SE) (5 мая 1999)	30 июня 2002 (осн.); 31 марта 2004 (SBL); 11 июля 2006 (ext)
20 апреля 2000	Windows 2000	5.0.2195 / 5.0 SP4 Rollup 1 v2 (13 сентября 2005)	31 марта 2004 (retail); 31 марта 2005 (SBL); 30 июня 2005 (осн); 13 июля 2021 (ext)
14 сентября 2000	Windows ME	4.90.3000 (14 сентября 2000)	31 декабря 2003 (осн.); 30 июня 2004 (SBL) (Retail); 11 июля 2006 (ext)
24 августа 2001 (RTM) 25 октября 2001 (продажи)	Windows XP	5.1.2600.5512 SP3 (21 апреля 2008)	30 сентября 2004 (RTM); 10 сентября 2006 (SP1/SP1a); 30 июня 2008 (retail); 14 апреля 2009 (SP2/SP3 осн.); 13 июля 2021 (SP2); 22 октября 2021 (SBL); 8 апреля 2021 (ext)	Internet Explorer 8
28 марта 2003	Windows XP 64-bit Edition	5.2.3790	25 июля 2006
24 апреля 2003	Windows Server 2003	5.2.3790.3959 SP2 (13 марта 2007)	30 июня 2009 (RTM); 13 июля 2021 (осн.); 14 июля 2021 (ext)
25 апреля 2005	Windows XP Professional x64 Edition	5.2.3790.3959 SP2 (13 марта 2007)	30 июня 2008 (retail); 31 января 2009 (SBL)
8 ноября 2006 (RTM) 30 января 2007 (продажи)	Windows Vista	6.0.6001 / SP2 Build 6002 (25 мая 2009)	13 апреля 2021 (RTM); 22 октября 2021 (retail); 12 июля 2021 (SP1); 22 октября 2021 (SBL); 10 апреля 2021 (осн.); 11 апреля 2021 (ext)	Internet Explorer 9
16 июля 2007	Windows Home Server	5.2.4500 (16 июля 2007)	8 января 2021 (ext)
27 февраля 2008	Windows Server 2008	6.0.6002 / SP2 build 6002 (25 мая 2009)	12 июля 2021 (SP1), 13 января 2021 (осн), 14 января 2020 (ext)
13 июля 2009 (RTM) 22 октября 2009 (продажи)	Windows 7	6.1.7601 / SP1 Build 7601 (22 февраля 2021)	9 апреля 2021 (RTM), 13 января 2021 (осн), 14 января 2020 (ext)	Internet Explorer 11
13 июля 2009 (RTM) 22 октября 2009 (продажи)	Windows Server 2008 R2 или Windows Server 7	6.1.7601 / SP1 Build 7601 (22 февраля 2021)	13 января 2021 (осн), 14 января 2020 (ext)
6 апреля 2021	Windows Home Server 2021	6.1.8400	12 апреля 2021 (ext)
1 августа 2021 (RTM) 4 сентября 2021 (продажи)	Windows Server 2021	6.2.9200 (26 октября 2021)	9 октября 2021 (осн), 10 октября 2023 (ext)
1 августа 2021 (RTM) 26 октября 2021 (продажи)	Windows 8	6.2.9200 (26 октября 2021)	12 января 2021 (ext)
21 августа 2021 (RTM) 17 октября 2021 (продажи)	Windows Server 2021 R2	6.3.9600 (17 октября 2021)	9 января 2021 (осн) 10 января 2023 (ext)
21 августа 2021 (RTM) 17 октября 2021 (продажи)	Windows 8.1	6.3.9600 (17 октября 2021)	9 января 2021 (осн) 10 января 2023 (ext)
15 июля 2021 (RTM) 29 июля 2021 (продажи)	Windows 10	10.0.15014 1607 (27 января 2021)	13 октября 2020 (осн.), 14 октября 2025 (ext.)	Microsoft Edge / Internet Explorer 11 (оставлен для совместимости)
29 сентября 2021 (RTM) 12 октября 2021 (продажи)	Windows Server 2021	1607 (10.0.14393) (26 сентября 2021)		Microsoft Edge
Условные обозначения:
Оболочка для MS-DOS	Windows 9x	Windows NT	Windows Server
Не поддерживается
осн. — окончание действия лицензии для первого (основного) релиза	SBL — окончание срока лицензии для производителей	retail — окончание срока лицензии для розничных покупателей	SPx — окончание срока лицензии для различных дополнений (сервис-паков) к системе	ext — полное окончание поддержки системы

Запуск локальных сценариев без подписи в powershell

В целях безопасности консоль PowerShell принимает и выполняет команды только с цифровой подписью. «Режим разработчика» предполагает тестирование различных скриптов, поэтому в нём проверка выполнения локальных скриптов отключается.

Таким образом, пользователи не будут сталкиваться с ошибкой в командной строке: The file is not digitally signed. Они смогут печатать различные скрипты, но только от надёжных создателей.

Для каждого раздела есть своя кнопка «Применить»: после изменения параметров в нём необходимо обязательно на неё нажать, чтобы все указанные значения вступили в силу. Справа от каждого пункта есть ссылка «Показать параметры». Если вдруг сам параметр некликабелен, нажмите на неё — откроется то или иное окно Windows, которому он соответствует в системе, и измените настройки там.

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

Для обычных пользователей Windows также будет полезна опция отображения полного пути к файлу в адресной строке окна «Проводника». Он выводится в заголовке после двойного клика по строке.

Недоступные пункты для портала и обнаружения устройств

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

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

1. Откройте плитку «Обновление и безопасность» в меню «Параметры». Во вкладке «Центр обновления Windows» нажмите на ссылку «Просмотреть журнал установленных обновлений».
   
2. Теперь жмём на первый пункт, чтобы избавиться от недавнего апдейта в дополнительном окне.
   
3. В новом окне кликните правой клавишей мышки по последнему обновлению (первый пункт в списке) и нажмите на «Удалить».
   
4. Подтвердите действие, нажав на «Да».
   
5. Попытайтесь снова включить «Режим разработчика».

Ошибка «некоторыми параметрами компьютера управляет организация»

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

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

1. Кликаем правой клавишей мышки по иконке «Этот компьютер» на «Рабочем столе». В сером меню жмём на пункт «Свойства».
   
2. В большом окне с информацией об «операционке» и вашем ПК ищем в левой части ссылку «Дополнительные параметры системы». Кликаем по ней.
   
3. В новом окне переключаемся на вторую вкладку «Защита системы», где щёлкаем по кнопке «Восстановить».
   
4. Запустится окно для восстановления. Выбираем пункт «Выбрать другую точку восстановления» либо «Рекомендуемое восстановление», если ошибка появилась после недавнего обновления.
   
5. В первом случае выделяем в списке нужную точку левой кнопкой. Не забудьте установить галочку рядом с пунктом для включения показа других точек. Так, вы сможете ознакомиться со всем списком.
   
6. Щёлкаем по «Далее». На следующей странице жмём на «Готово» для подтверждения.
   
7. Запустится процесс восстановления. Продолжительность процедуры зависит от количества параметров, которые необходимо изменить. После этого устройство перезапустится.

Сбой поиска или установки пакета «режима разработчика» с кодом ошибки 0x80004005

После попытки активировать среду под пунктом может выскочить красное уведомление о том, что система не смогла инсталлировать пакет «Режима разработчика» или что в «Центре обновления» не оказалось данного пакета. Обе ошибки имеют при этом код 0x80004005.

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

Если у вас установлены какие-либо сторонние утилиты, которые отключают слежку Windows 10, например, DWS или AntiSpy, деактивируйте их на время. Возможно, именно они блокируют доступ к серверам Microsoft.

Антивирус также может по ошибке блокировать доступ к официальным серверам Microsoft. Чтобы это проверить, необходимо на время его отключить. Программа-защитник всегда должна работать в фоновом режиме, чтобы вовремя обнаружить и обезвредить угрозу, поэтому её значок должен находиться в трее Windows. Рассмотрим отключение на примере Avast:

1. Отключите среду для разработчиков. Нажмите на значок в виде стрелки, направленной вверх, на «Области уведомлений» в правой части «Панели задач» (это и есть трей Windows).
2. В маленьком меню жмём на иконку Avast правой клавишей мышки. Теперь наводим курсор на пункт «Управление экранами Avast». В перечне выбираем нужное время для отключения. Достаточно будет выбрать минимальное значение 10 минут.
   
3. В течение этого времени пробуйте включать «Режим разработчика».

Если антивирус не является помехой, проверьте наличие обновлений Windows 10:

1. Запустите окно «Параметры Windows» с помощью комбинации клавиш Win I либо через панель «Пуск».
2. В списке выбираем плитку «Обновления и безопасность». Нам нужен первый раздел «Центр обновления Windows». В этой вкладке кликаем по кнопке «Проверка наличия обновлений».
3. Система ту же запустит поиск.
   
4. Если будет найден доступный апдейт, ОС сама его загрузит и установит. Ход инсталляции будет показан в процентах.
   
5. После обновления попробуйте снова включить среду для разработчиков.

Если уже установлены все актуальные обновления Windows, проверьте есть ли пакет для «Режима разработчика» в блоке с перечнем дополнительных компонентов:

1. Снова запускаем «Параметры Windows», но на этот раз кликаем по плитке «Приложения».
2. В первом блоке жмём на ссылку для открытия списка дополнительных компонентов.
   
3. В появившемся списке должен быть пункт «Режим разработчика Windows».
   
4. Если его нет, Windows не удастся найти правильный пакет для вашего ПК. Кликните по кнопке «Добавить компонент», чтобы система загрузила его.
   
5. После добавления пакета попробуйте снова активировать режим.

«Режим разработчика» полезен как для специалистов IT, так и обычным юзерам, которые хотят установить надёжное приложение без подписи Microsoft. Включить среду можно разными способами. Самый простой — в меню «Параметры Windows». Если не удаётся активировать там, воспользуйтесь редакторами реестра и групповых политик.

Семейство windows nt

Основная статья: Windows NT

Операционные системы этого семейства в настоящее время работают на процессорах с архитектурами x86, x86-64, Itanium, ARM. Ранние версии (до 4.0 включительно) также поддерживали некоторые RISC-процессоры: Alpha, MIPS и PowerPC. Все операционные системы этого семейства являются полностью 32- или 64-битными и не нуждаются в MS-DOS даже для загрузки.

Только в этом семействе представлены операционные системы для серверов. До версии Windows 2000 включительно они выпускались под тем же названием, что и аналогичная версия для рабочих станций, но с добавлением суффикса, например «Windows NT 4.0 Server» и «Windows 2000 Datacenter Server». Начиная с Windows Server 2003 серверные операционные системы называются добавлением суффикса «Server» и года выпуска.

В основу семейства Windows NT положено разделение адресных пространств между процессами. Каждый процесс имеет возможность работать с выделенной ему памятью. Однако он не имеет прав для записи в память других процессов, драйверов и системного кода.

Семейство Windows NT относится к операционным системам с вытесняющей многозадачностью. Разделение процессорного времени между потоками происходит по принципу «карусели». Ядро операционной системы выделяет квант времени (в Windows 2000 квант равен примерно 20 мс) каждому из потоков по очереди при условии, что все потоки имеют одинаковый приоритет.

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

Через «редактор реестра»

Редактирование реестра Windows — не самая простая задача, с которой могут не справиться начинающие пользователи ПК. Тем не менее о способе необходимо знать и по возможности научиться его применять, так как он работает для всех версий «десятки», включая «Домашнюю». Чтобы немного облегчить задачу, подробно и доступно опишем все действия:

1. Самый быстрый способ запустить редактор — через окошко «Выполнить». Вызываем его двумя клавишами Win R: одновременно зажимаем их. В строке «Открыть» пишем или вставляем предварительно скопированный код regedit.
   
2. В следующем окне, которое откроет ОС, разрешаем редактору вносить изменения на вашем устройстве: кликаем по кнопке «Да».
   
3. В левой колонке редактора нас интересует третья ветка HKEY_LOCAL_MACHINE. Запускаем её двойным кликом.
   
4. Далее, необходимо переходить по очереди в следующий разделы в той же левой части окна: SOFTWARE — Microsoft — Windows — CurrentVersion — AppModelUnlock.
   
5. В последней запущенной папке будет две записи. Кликаем дважды по первой с названием AllowAllTrustedApps и ставим в маленьком сером окошке цифру 1 в качестве значения (это активирует запись). Для сохранения всех изменений щёлкаем по ОК.
   
6. Повторяем то же действие для другой записи.
7. Теперь закрываем все окна, запущенные на ПК, и перезагружаем устройство.

Поменять значение тех же параметров реестра можно и с помощью консоли «Командная строка». Как её запустить и какие коды в ней вводить?

1. Консоль открываем через панель «Поиск». Кликаем по иконке в виде лупы, а в строке внизу пишем запрос «Командная строка» или cmd.
   
2. В результатах поиска жмём на пункт правой клавишей мышки и в сером меню выбираем «Запуск от имени администратора».
   
3. В чёрном редакторе вставляем команду reg add ″HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionAppModelUnlock″ /t REG_DWORD /f /v ″AllowAllTrustedApps″ /d ″1″ и нажимаем на Enter.
   
4. После её выполнения вставляем другой код: reg add ″HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionAppModelUnlock″ /t REG_DWORD /f /v ″AllowDevelopmentWithoutDevLicense″ /d ″1″. Также, жмём на Enter.
5. Закрываем все окна и перезапускаем ПК.

Эксперимент: отображение информации о типах для структур ядра.

Чтобы вывести список структур ядра, чей тип информации включен в символы ядра, наберите в отладчике ядра команду dt nt!_*. Частичный образец вывода имеет следующий вид:

lkd> dt nt!_*

nt!_LIST_ENTRY

nt!_LIST_ENTRY

nt!_IMAGE_NT_HEADERS

nt!_IMAGE_FILE_HEADER

nt!_IMAGE_OPTIONAL_HEADER

nt!_IMAGE_NT_HEADERS

nt!_LARGE_INTEGER

Командой dt можно также воспользоваться для поиска определенных структур, используя заложенную в эту команду возможность применения символов-заместителей. Например, если ведется поиск имени структуры для объекта interrupt, нужно набрать команду dt nt!_*interrupt*:

lkd> dt nt!_*interrupt*

nt!_KINTERRUPT

nt!_KINTERRUPT_MODE

nt!_KINTERRUPT_POLARITY

nt!_UNEXPECTED_INTERRUPT

Затем, как показано в следующем примере, команду dt можно использовать для форматирования определенной структуры:

lkd> dt nt!_kinterrupt

nt!_KINTERRUPT

0x000 Type : Int2B

0x002 Size : Int2B

0x008 InterruptListEntry : _LIST_ENTRY

0x018 ServiceRoutine : Ptr64 unsigned char

0x020 MessageServiceRoutine : Ptr64 unsigned char

0x028 MessageIndex : Uint4B

0x030 ServiceContext : Ptr64 Void

0x038 SpinLock : Uint8B

0x040 TickCount : Uint4B

0x048 ActualLock : Ptr64 Uint8B

0x050 DispatchAddress : Ptr64 void

0x058 Vector : Uint4B

0x05c Irql : UChar

0x05d SynchronizeIrql : UChar

0x05e FloatingSave : UChar

0x05f Connected : UChar

0x060 Number : Uint4B

0x064 ShareVector : UChar

0x065 Pad : [3] Char

0x068 Mode : _KINTERRUPT_MODE

0x06c Polarity : _KINTERRUPT_POLARITY

0x070 ServiceCount : Uint4B

0x074 DispatchCount : Uint4B

0x078 Rsvd1 : Uint8B

0x080 TrapFrame : Ptr64 _KTRAP_FRAME

0x088 Reserved : Ptr64 Void

0x090 DispatchCode : [4] Uint4B

Следует заметить, что при выполнении команды dt подструктуры (структуры внутри структур) по умолчанию не показываются. Для выполнения рекурсии подструктур нужно воспользоваться ключом –r. Например, воспользоваться этим ключом для вывода объекта прерывания ядра с показом формата структуры _LIST_ENTRY, хранящейся в поле InterruptListEntry:

lkd> dt nt!_kinterrupt -r

nt!_KINTERRUPT

0x000 Type : Int2B

0x002 Size : Int2B

0x008 InterruptListEntry : _LIST_ENTRY

0x000 Flink : Ptr64 _LIST_ENTRY

0x000 Flink : Ptr64 _LIST_ENTRY

0x008 Blink : Ptr64 _LIST_ENTRY

0x008 Blink : Ptr64 _LIST_ENTRY

0x000 Flink : Ptr64 _LIST_ENTRY

0x008 Blink : Ptr64 _LIST_ENTRY

В файле справки Debugging Tools for Windows также объясняется, как настраиваются и используются отладчики ядра. Дополнительные подробности использования отладчиков ядра, предназначенные непосредственно для создателей драйверов устройств, могут быть найдены в документации по набору Windows Driver Kit.