Код ошибки 0x0000014f

PDC_WATCHDOG_TIMEOUT Ошибка остановки синего экрана имеет значение проверки ошибки 0x0000014F и возникает, когда системный компонент не отвечает в течение выделенного периода времени, не позволяя системе выйти из подключенного режима ожидания. Если вы сталкиваетесь с этим BSOD, то некоторые предложения в этом посте могут вам помочь.

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

PDC_WATCHDOG_TIMEOUT

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

1. Обновление или откат драйверов.
2. Запустите средство диагностики памяти Windows.
3. Отключите новое оборудование.
4. Обновите BIOS.

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

1] Обновление или откат драйверов, связанных с

Используемый драйвер устройства относится к категории контроллеров IDE ATA/ATAPI и ко всем записям, таким как стандартный контроллер SATA AHCI. Эти драйверы должны быть обновлены – обновите эти драйверы.

Если вы недавно обновили этот драйвер, возможно, вам нужно откатить драйвер.

2] Запустите средство диагностики памяти Windows

Запустите проверку памяти на вашем компьютере. Начните с нажатия комбинации клавиш WINKEY + R , чтобы запустить утилиту Выполнить . Затем введите mdsched.exe и нажмите Enter . . Он запустит средство диагностики памяти Windows и выдаст две опции:

1. Перезагрузите сейчас и проверьте наличие проблем (рекомендуется)
2. Проверьте наличие проблем при следующем запуске компьютера

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

3] Отключите новое оборудование

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

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

4] Обновите BIOS

BIOS является чувствительной частью компьютера. Хотя это программный компонент, от него во многом зависит функционирование аппаратного обеспечения. Следовательно, вы должны быть очень осторожны при изменении чего-либо в BIOS. Я бы порекомендовал вам пропустить этот метод, если вы не знаете, что делаете, или не знаете, как это сделать.

Чтобы обновить BIOS, сначала нажмите комбинацию кнопок WINKEY + R, чтобы запустить поле Выполнить , введите msinfo32 и, наконец, нажмите Enter.

Откроется информация о системе. внизу вы найдете поле поиска; там вы должны найти версию BIOS и нажать Enter.

Там вы сможете увидеть версию и версию BIOS, установленную на вашем компьютере.

Теперь вы заходите на веб-сайт производителя и загружаете на свой компьютер последнюю версию BIOS.

Если вы используете ноутбук, убедитесь, что он подключен к сети до тех пор, пока не будет установлено это обновление BIOS.

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

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

Если вы не видите правильного имени производителя в окне «Информация о системе», вам придется проверить веб-сайт производителя вашей материнской платы. Как только вы посетите веб-сайт, перейдите в раздел загрузок веб-сайта, чтобы получить последнюю версию BIOS для вашего компьютера. Обычно американские мегатенденции используются для сборки компьютеров, но в любом случае вы даже можете проверить наличие обновлений Windows для любой новой версии BIOS, доступной для вашего компьютера.

This another rare bugcheck which I’ve only seen on a handful of occasions, which makes it even important that we explore it and create some documentation. I’ll continuing from earlier analysis which Patrick made here.

PDC_WATCHDOG_TIMEOUT (14f)
A system component failed to respond within the allocated time period,
preventing the system from exiting connected standby.
Arguments:
Arg1: 0000000000000004, Client ID of the hung component.
Arg2: 0000000000000001, A notification client failed to respond.
Arg3: ffffc001079315c0, Pointer to the notification client (pdc!_PDC_NOTIFICATION_CLIENT).
Arg4: ffffd00021701b50, Pointer to a pdc!PDC_14F_TRIAGE structure.

As previously mentioned by Patrick, this bugcheck is caused when a system process has been unable to respond in a timely fashion when waking from standby mode, and therefore the system ends up in a bugcheck as shown above.

Fortunately, both of the data structures mentioned in the bugcheck parameters can be dumped using a Minidump, however, before we do that, we’ll need to familiarise ourselves with what the bugcheck is about.

This bugcheck is fairly uncommon and is typically found with devices such as tablets like the Surface Pro. PDC is an acronym for Power Dependency Coordinator and is a component of Modern Standby. This power policy was introduced with Windows 8 and developed further with the introduction of Windows 10. Essentially, its purpose was to allow devices to ‘instantly’ wake from sleep. It was primarily introduced as Microsoft began to shift its focus to portable devices such as tablets.

Modern Standby is directly analogous to how if you press the power button on your smartphone, it won’t be powered off, but rather go into a very low powered idle state and respond to certain events such as app notifications, etc.

It is very important to note that not all systems will support Modern Standby and to support it, the firmware must meet these requirements:

1. x86-x64 processor architecture must have the ability to support hibernation.
2. The processor must provide a power engine plugin (PEP) driver. Windows 8.1+ provides this for Intel processors natively.
3. The ACPI table must support the following flag – ACPI_S0_LOW_POWER_IDLE_FADT.

As a side note, I believe that the ACPI specification refers to the FADT flag as LOW_POWER_S0_IDLE_CAPABLE instead (please see Section 5.2.9 of the ACPI Specification).

To check if a system supports Modern Standby, then open a Command Prompt window and enter the following command:

powercfg /availablesleepstates

You should see output which similar to the below:

The following sleep states are available on this system:
Standby (S3)
Hibernate
Hybrid Sleep
Fast Startup

The following sleep states are not available on this system:
Standby (S1)
The system firmware does not support this standby state.

Standby (S2)
The system firmware does not support this standby state.

Standby (S0 Low Power Idle) << Modern Standby
The system firmware does not support this standby state.

Notice how my system doesn’t support Modern Standby? S0 is the power state which is used to represent modern standby. We’ll discuss this in greater depth later on in this article, but for now, let’s look at the difference between Connected and Disconnected Modern Standby.

There is very little difference between connected and disconnected standby. The main difference being that with connected standby, network traffic still continues and the device is able to be woken by certain network notifications with connected standby. Disconnected standby was introduced with the advent of Windows 10 and therefore you can safely assume that Windows 8+ devices will be using connected standby if the system firmware supports it.

For S3 systems, a device is either in the active powered on state or is in the S3 sleep state. With modern standby devices, devices slowly reduce their power consumption gradually, which enables them to wake faster from sleep states.

Modern Standby Phases:

There is a number of phases associated with modern standby, and this bugcheck can occur within any stage, therefore it is important to understand what each stage does and where the system is as it is transitioning to S0. The following table illustrates all these phases and what they do.

Now, we have a greater understanding of Modern Standby, it’s much easier to understand the meaning of the bugcheck parameters. We’ll begin exploring each one in the preceding section.

Bugcheck Parameters:

The first parameter refers to the client ID which corresponds to an enumeration type called PDCCLIENTID, this uniquely identifies the PDC client which the client type corresponds to. Please refer to an omitted version of the enumeration below:

4: kd> dt PDCCLIENTID
nt!PDCCLIENTID
   PDC_INVALID_CLIENT = 0n0
   PDC_PLM_CLIENT = 0n1
   PDC_NQM_CLIENT = 0n2
   PDC_WNS_CLIENT = 0n3
   PDC_DAM_CLIENT = 0n4
   PDC_WCM_CLIENT = 0n5
   PDC_NCSI_CLIENT = 0n7
   PDC_DHCP_CLIENT = 0n8
   PDC_TCPIP_CLIENT = 0n9
   PDC_WU_CLIENT = 0n11
   PDC_GP_CLIENT = 0n12
   PDC_NCA_CLIENT = 0n14
   PDC_BI_CLIENT = 0n15
   PDC_MSCHED_CLIENT = 0n16
[...]

Now, Parameter 2 decides the meaning of other the parameters and therefore we’ll look into each one individually. It’s interesting to note that all the values for the second parameter are stored within an enumeration type called PDC_CLIENT_TYPE.

3: kd> dt PDC_CLIENT_TYPE
PdcNotificationClient = 0n0
PdcResiliencyClient = 0n1
PdcActivator = 0n2
PdcSuspendResumeClient = 0n3
PdcTaskClient = 0n4
PdcSignalClient = 0n5
PdcPpmProfileClient = 0n6
PdcInvalidType = 0n7

Parameter 2 = 0x1

This indicates that the notification client has failed to respond. The notification client can be a number of different types; these can be found in an enumeration called PDC_NOTIFICATION_TYPE.

3: kd> dt PDC_NOTIFICATION_TYPE
PdcLowPowerNotification = 0n0
PdcPlmNotification = 0n1
PdcDamNotification = 0n2
PdcResiliencyNotification = 0n3
PdcShellNotification = 0n4
PdcInvalidNotification = 0n5
PdcMaxNotification = 0n5

The third parameter will contain the address of the _PDC_NOTIFICATION_CLIENT which has failed to respond.

3: kd> dt _PDC_NOTIFICATION_CLIENT ffffc001079315c0
pdc!_PDC_NOTIFICATION_CLIENT
+0x000 Context : _PDC_COMMON_CONTEXT
+0x020 ClientId : 4
+0x024 ReplyReceived : 0 ''
+0x028 Control : 0xfffff800`f0be7f80 _PDC_NOTIFICATION_CONTROL

Notice how the ReplyReceived field is 0? This means that no response has been received and therefore the notification client will not respond. The Client ID indicates the process which has failed. In this case, it was the System process.

Now, to find out which type of notification client has failed to respond, we can dump the PDC_NOTIFICATION_CONTROL structure.

3: kd> dt _PDC_NOTIFICATION_CONTROL 0xfffff800`f0be7f80
pdc!_PDC_NOTIFICATION_CONTROL
+0x000 NotificationType : 2 ( PdcDamNotification )
+0x008 ClientContext : (null)
+0x010 PdcSequence : 0x66
+0x018 Callback : 0xfffff800`f0bee9e0 long pdc!PdcpCommonNotificationCompleteCallback+0
+0x020 Armed : 0x1 ''
+0x021 AllClientsResponded : 0 ''
+0x022 WaitTimerExpired : 0x1 '' << The wait timer has expired since no response was provided
+0x023 CatchupReplyPending : 0 ''
+0x024 CatchupRepliesBlockingTransition : 0 ''
+0x028 PendingActivation : _PDC_ACTIVATE_NOTIFICATION_PARAMETERS
+0x058 CurrentValue : 0x79315c0
+0x05c ClientStatus : 0n-16383
+0x060 ClientList : _LIST_ENTRY [ 0xffffc001`079315c0 - 0x00000068`f145fcb8 ]
+0x070 WatchdogTimeout : 3

The NotificationType field provides the type of notification which was were waiting for. Now, looking back at the PDC phases, we can see that we were waiting for a response from the Desktop Activity Monitor component.

Parameter 2 = 0x2

This indicates that a resiliency client has failed to respond. The type of resiliency client can be found within the PDC_RESILIENCY_TYPE structure which is part of the PDC_RESILIENCY_CLIENT structure. The address of the client object can be found within the third parameter.

3: kd> dt _PDC_RESILIENCY_CLIENT
pdc!_PDC_RESILIENCY_CLIENT
+0x000 Context : _PDC_COMMON_CONTEXT
+0x020 ResiliencyType : PDC_RESILIENCY_TYPE
+0x028 ClientReferences : Uint8B
+0x030 PoResiliencyClient : UChar
+0x034 CurrentTransactionId : Uint4B
+0x038 OneTimeTransaction : UChar
+0x03c CurrentState : PDC_CLIENT_STATE
+0x040 NextState : PDC_CLIENT_STATE
+0x044 ClientId : Uint4B

The enumeration contains the following values:

3: kd> dt PDC_RESILIENCY_TYPE
PdcIdleResiliency = 0n0
PdcHostResiliency = 0n1
PdcIoResiliency = 0n2
PdcDamResiliency = 0n3
PdcNqmResiliency = 0n4
PdcWcmResiliency = 0n5
PdcInvalidResiliency = 0n6
PdcMaxResiliency = 0n6
PdcLightestResiliency = 0n5

Parameter 2 = 0x3

This indicates that an activator client held a reference for too long and therefore has led to a timeout condition. Again, the third parameter will contain the address of the appropriate structure, which in this case, is the PDC_ACTIVICATOR_CLIENT.

3: kd> dt _PDC_ACTIVATOR_CLIENT
pdc!_PDC_ACTIVATOR_CLIENT
+0x000 Context : _PDC_COMMON_CONTEXT
+0x020 ClientId : Uint4B
+0x028 ResiliencyContexts : [6] _RESILIENCY_CONTEXT
+0x088 CompletionStatus : Int4B
+0x08c CurrentActivity : PDC_ACTIVITY_TYPE
+0x090 PendingResiliency : PDC_RESILIENCY_TYPE
+0x098 ReplyMessage : _PDC_MESSAGE
+0x188 ActivationStats : Ptr64 _PDC_ACTIVATION_STATS
+0x190 WatchdogContext : Ptr64 _PDC_WATCHDOG_CONTEXT
+0x198 ContinuouslyBlockingDrips : Uint8B

Activators are special system services that are able to block a device from leaving the active power state and transitioning into the low powered idle state. These services can be a number of different system components including Windows Update and the Group Policy manager. Each activator will hold an activation reference will is activated under certain conditions, these conditions vary for each activator.

For example, with the Windows Update service activator, the reference flag will be enabled when the service is scanning for any critical updates; while this reference is held, the device will held in the active power state. Once, the Windows Update service has finished scanning for any critical updates, then the reference flag will be cleared and the device will able to transition into a low powered idle state.

Going back to the PDC_ACTIVATOR_CLIENT structure, there is a number of useful fields that can provide greater context to the type of activator and why it has timed out. The CompletionStatus indicates the status of the activator and if it is still active, whereas, the CurrentActivity provides an index into the PDC_ACTIVITY_TYPE enumeration.

3: kd> dt PDC_ACTIVITY_TYPE
PdcNetwork = 0n0
PdcSystem = 0n1
PdcTimer = 0n2
PdcAllNetworks = 0n3
PdcInvalidActivity = 0n4
PdcMaxActivity = 0n4

The ActivationStats field contains a pointer to the PDC_ACTIVATION_STATS structure which provides some useful statistics about the activator including its maximum duration and activation count.

3: kd> dt _PDC_ACTIVATION_STATS
pdc!_PDC_ACTIVATION_STATS
+0x000 Link : _LIST_ENTRY
+0x010 ClientId : Uint4B
+0x014 ActiveActivations : Uint4B
+0x018 ActivationCount : Uint4B
+0x020 ActivationTime : Uint8B
+0x028 ActivatedTime : Uint8B
+0x030 MaxActivationDuration : Uint8B

Parameter 2 – 0x100

This parameter value shows that the Win32k.sys (Windows subsystem) wasn’t able to respond to a monitor-on power request within the specified timeout limit. Effectively, a power IRP was pending for too long and therefore lead to the bugcheck. It is important to note that the monitor-on power requests come from a variety of wake sources. These wake sources are any inputs which are able to ‘wake’ the system from the idle power state. It should be noted that the wake source operation is the same for both x86-x64 and ARM architectures.

One such wake source is the power button, if this is pressed, then a request will be sent to ensure that the monitor is powered on. Similarly, if you were to open the lid of a laptop, then a monitor on power request will also be sent. Other wake sources include the keyboard and mouse. The complete list of wake sources can be found here – Modern Standby wake sources

The third parameter of this bugcheck indicates the reason why a monitor-on power request was sent. The number of available reasons are stored within an enumerator called POWER_MONITOR_REQUEST_REASON. Please refer to the documentation here – POWER_MONITOR_REQUEST_REASON (ntpoapi.h) – Windows drivers

Parameter 4

3: kd> dt _PDC_14F_TRIAGE
pdc!_PDC_14F_TRIAGE
+0x000 ClientProcess : Ptr64 _EPROCESS
+0x008 CallbackThread : Ptr64 _ETHREAD

The fourth parameter is a pointer to the _PDC_14F_TRIAGE structure for most scenarios. This structure simply wraps up the client process and call back thread of the crashed process in one neat location.

Debugging Methodology:

There are two primary methods of debugging this issue: obtaining a sleep study report and WPA trace or examining the crash dump. A sleep study report can be obtained using the following command from an elevated command prompt:

powercfg.exe /sleepstudy

If the command has run successfully, then you should see the following output which indicates where the report has been saved.

C:WINDOWSsystem32>powercfg.exe /sleepstudy
Sleep Study report saved to file path C:WINDOWSsystem32sleepstudy-report.html.

Since this article will primarily be focusing on crash dump analysis, I highly recommend reading the following articles for WPA traces and sleep study reports:

• Capture and view a WPA trace for modern standby diagnostics
• Modern standby SleepStudy common problem examples

In terms of crash dump debugging, I would recommend examining the parameters and then checking for any power IRPs which may be pending. I have written about a very similar bugcheck here which provides further clarification on this – Debugging Stop 0x17C – PDC_LOCK_WATCHDOG

This article is a guide on using bug check analysis to investigate why a Microsoft® Windows® server
crashed. A server crash, also known as Blue Screen of Death or BSOD, displays an error screen and can cause
the server to shut down or restart unexpectedly. The following terms are common when discussing server
crashes.

• Blue screen: When certain hardware problems occurs, a blue error screen displays.
• Crash dump file: This file, stored on the hard drive, contains information collected when the system
  generates a STOP code. The memory.dmp file contains information that the debugger needs to analyze.
• Debugger: Use this program to analyze the dump file
• STOP code: This error code identifies what stopped the system kernel from running.

Analyzing a bug check code

Microsoft provides WinDbg to debug the crash dump. You can
download the debugger.

The system creates a memory.dmp file at the time of the crash. Use WinDbg to analyze the file and determine
the cause of the crash.

Run WinDbg

To use WinDbg, you need do the following tasks.

Add the symbol path

After you install WinDbg, perform the following steps to add the symbol file path for debugging:

1. Open WinDBG > File > Symbol File Path… and enter the following:

   SRV*C:Windowssymbol_cache*https://msdl.microsoft.com/download/symbols
   

2. Click OK.

Windows might store the dump file in the following locations:

Open the memory.dmp file

To open the dump file, perform the following steps:

1. Go to File > Open Crash Dump… > Open the MEMORY.DMP file.

2. Click or type “!analyze -v to get the detailed debugging information.

3. Wait for the analysis to complete.

Read the crash dump

After the analysis completes, review the output to determine the cause of the crash. For example, driver issues
or memory corruption might have caused the crash. The output of the analysis provides you with the details.

Example causes include the following possibilities:

FAILURE_BUCKET_ID:  X64_0xA_termdd!IcaDereferenceChannel+8c
The cause of the error was due to termdd.sys.

FAILURE_BUCKET_ID: 0xd1_e1k6232+16171
The cause was the Intel network adapter(e1k6232.sys) drivers

Use Driver Verifier, if necessary

If faulty drivers caused the crash, you can use Driver Verifier to examine the system’s drivers.
Use the Windows-native Driver Verifier utility to test system drivers to find any improper behaviors.

To use Driver Verifier, perform the following steps:

1. Open a command prompt as the administrator.

2. Type verifier to open the Driver Verifier Manager.

3. Select the task you want and click Next. The default is Create standard settings.

4. Select which drivers to verify and click Next.

5. Depending on the options selected, you might need to restart the server. In that case, the system notifies
   you before the verifier executes your options.

6. After the verifier finishes, review the output of the verifier.

Bug check codes

The following table lists some of the bug check codes you might encounter:

Многие технические специалисты в своей работе сталкиваются с ошибками, возникающими на различных стадиях загрузки операционной системы Windows. Случился и в моем практике не так давно достаточно нетипичный сбой этапа загрузки, в котором мне, к моему огромному недовольству, затруднительно было сходу разобраться. Смысл проблемы заключался в том, что вышедшая из строя по достаточно нетривиальной цепочке причин, система Windows 7 (Профессиональная) отказывалась грузиться во всех, без исключения, режимах загрузки. Процесс загрузки просто «вис» на черном экране на этапе, следующем за графическим экраном заставки (splash screen). Код работы с видеоадаптером устанавливал разрешение в родное для монитора, а далее загрузка просто-напросто останавливалась, при этом отчетливо был виден графический курсор мыши, сам манипулятор функционировал. Я так полагаю, что у профессионалов подобное явление обозначается термином черный экран смерти (Black Screen of Death, KSOD), наиболее распространенными причинами которого являются: повреждение различных частей реестра, невозможность запуска критически важных служб и кривая установка разрешений на системные каталоги (все эти вещи зачастую вызваны обновлениями). Большая просьба не путать термин «черный экран смерти» с общеизвестным синим экраном смерти (Blue Screen of Death, BSOD). Как я уже упоминал, загрузка в безопасном режиме останавливалась на том же самом месте, то есть я вообще никак, ни в каком из режимов не мог загрузить ОС!! С грустью вспомнил обо всех хваленых средствах диагностики загрузки вида xbootmgr и прочих трассировщиках, которые оказывались абсолютно бесполезными в подобной ситуации. Потом пришла мысль, что хорошо было бы подключиться каким-нибудь отладчиком удаленно и просто протрассировать код до ошибки, но подобным опытом я пока не обладаю, а проблему надо было решать в сжатые сроки.

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

Однако, сама ситуация навела меня на размышления о том, что на дворе уже далеко ведь не первая версия операционной системы, да и эра технологий, так сказать, в полном разгаре :), а пользователи Windows продолжают наблюдать «неопределенные состояния», в которых операционная система не в силах хотя бы на простом уровне вычислить причину сбоя и сообщить об этом оператору!! С другой стороны для меня лично очевидно, насколько сложно создать код, который отслеживал бы все возможные внутренние состояния. Как же быть? Ведь я совершенно не могу понять, на каком именно этапе загрузка остановилась. Поизучав материалы, которые имеются в Сети по теме этапов загрузки, понял, что большинстве своем они не дают представления о характерах и причинах возникновения ошибок, а содержат лишь общие рекомендации по устранению. Поэтому у меня возникло желание углубиться в материал и сделать себе небольшую карту ошибок этапов загрузки, да и для дальнейшего изучения он был бы неплохой отправной точкой. Так родилась идея начать серию статей по описанию стадий загрузки Windows с уклоном в сторону диагностики ошибок. Затем захотелось посмотреть на проблему ошибок загрузки Windows не с точки зрения последовательности «описание — снимок экрана — а попробуйте во это решение», а именно со стороны изучения всех возможных причины возникновения той или иной ошибки непосредственно с изучением кода. Да и вообще, мне лично всегда было интересно погрузиться до глубин кода, заглянуть «в файл» и прикоснуться к граням алгоритмов загрузки Windows, понять больше, познакомиться с ошибками, которые никогда не встречались мне на практике и не были освещены в информационном пространстве Сети, понять происходящее «изнутри».

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

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

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

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

В данной версии статьи будет описана классическая схема разбиения и загрузки (legacy boot), основанная на использовании PC/AT BIOS и MBR.

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

Об ошибках в модулях загрузки

Непосредственно перед тем как начать описание процесса загрузки и возникающих в процессе проблем, я бы хотел сделать небольшое отступление на тему ошибок Bootmgr, Winload и ntoskrnl, возникающих в ходе работы кода одноименных модулей. Многие критичные процедуры кода, реагируя на те или иные условия, генерируют числовые идентификаторы ошибок и возвращают их через произвольный регистр (чаще всего это eax). Поскольку регистр, хранящий код ошибки, часто сохраняется либо умышленно не используется, ошибки в «сквозном» режиме передаются на верхний уровень иерархии вложенных подпрограмм, то есть просто при множественном возврате из них по команде ret. Таким образом ошибки регистрируются до тех пор, пока в коде не встречается логика обработки ошибки. Подобных участков обработки ошибок Bootmgr у нас несколько:

• Блок кода в процедуре BmMain, выдающий ошибку BlInitializeLibrary failed …;
• Блок кода в процедуре BmMain, выдающий ошибку BlResourceFindMessage failed …;
• Блок кода в процедуре BmMain, выдающий ошибку BlXmiInitialize failed …;
• Процедура BmFatalErrorEx, которая является глобальным обработчиком ошибок на все остальные случаи;
• Процедура BlStatusError, которая вызывается из процедур MmHapReportHeapCorruption и BmFatalErrorEx в аварийной ситуации, проверяет наличие активного отладчика и случае наличия выдает специальную ошибку *** Fatal error …;

Некоторые обработчики незамедлительно выдают сообщение о возникшей проблеме на консоль, а вот глобальный кейс-обработчик BmFatalErrorEx содержит более витиеватую логику обработки поступившего кода с выдачей уже развернутого текста ошибки. Другая особенность обработки ошибок Bootmgr/Winload заключается в том, что, насколько я смог разобраться, менее значимые ошибки замещаются более значимыми. А это означает, что если ошибка возникла в какой-то процедуре как реакция на определенное условие, то другая ошибка, возникшая позже и являющаяся более приоритетной, может в процессе дальнейшего исполнения кода просто «затереть» первичную ошибку. Из этого следует, что на консоли пользователь видит лишь один результирующий статус, имеющий самый высокий приоритет, хотя, вероятно, имелся и менее приоритетный статус (или серия статусов), который был потерян.
Все ошибки, возникающие на этапах загрузки операционной системы Windows можно подразделить на две общие категории:

• Ошибка NT_ERROR (NTSTATUS). Хорошо знакомый разработчикам статус, использующийся для передачи результатов ошибок между разными компонентами ОС. Используется в ошибках Bootmgr/Winload, то есть сразу начиная с этапа Bootmgr.
• Ошибка BSOD BugCheck (STOP). Фатальная ошибка, хорошо знакомый всем нам синий экран смерти. Может возникать на поздних стадиях загрузки ОС, после того как подгружается логика обработки критических ошибок на этапе Ntoskrnl.

Код NTSTATUS — это 32-битное числовое значение, описывающее статус выполнения (результат завершения) кода подпрограммы/функции.

NTSTATUS частично описан в заголовочном файле ntstatus.h комплекта Windows WDK. Значения подразделяются на четыре категории:

• NT_SUCCESS (0 − 0x3FFFFFFF);
• NT_INFORMATION (0x40000000 − 0x7FFFFFFF);
• NT_WARNING (0x80000000 − 0xBFFFFFFF);
• NT_ERROR (0xC0000000 — 0xFFFFFFFF);

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

Некоторые особенности ошибок

У ошибок в коде Bottmgr я выделил несколько особенностей:

• В коде Bootmgr присутствуют так называемых «перекодирующих процедур», которые на входе проверяют значения некоторых ошибок NT_ERROR (диапазон 0xC0000000-0xFFFFFFFF) и, в зависимости от неких условий, преобразуют их в предупреждения NT_WARNING (диапазон 0x80000000-0xBFFFFFFF). По этой причине некоторые ошибки пользователь вообще никогда не будет наблюдать на результирующем ошибочном экране, выводимом Bootmgr. Однако, я этот факт в своей работе не учитывал и описывал все без исключения ошибки.
• Следующий немаловажный момент в логике обработки ошибок заключается вот в чем: Информационные сообщения об ошибках BootMgr/Winload, выводимые кодом модулей, вовсе не обязательно будут однозначно соответствовать уникальному значению NTSTATUS! Вот вам простой пример, наверняка многие видели на практике вот такую вот ошибку:

  Не удалось запустить Windows. Возможно, это произошло из-за недавнего изменения конфигурации оборудования или программного обеспечения. Чтобы устранить ошибку: 1. Вставьте установочный диск Windows и перезагрузите компьютер. 2. Выберите параметры языка,  затем нажмите кнопку «Далее». 3. Выберите пункт «Восстановить компьютер». Если этот диск отсутствует, обратитесь за помощью к системному администратору или изготовителю компьютера. Состояние: 0xc000000f Сведения: Сбой меню загрузки, поскольку требуемое устройство недоступно.

  А вот теперь та же самая ошибка, но с другим состоянием:

  Не удалось запустить Windows. Возможно, это произошло из-за недавнего изменения конфигурации оборудования или программного обеспечения. Чтобы устранить ошибку: 1. Вставьте установочный диск Windows и перезагрузите компьютер. 2. Выберите параметры языка,  затем нажмите кнопку «Далее». 3. Выберите пункт «Восстановить компьютер». Если этот диск отсутствует, обратитесь за помощью к системному администратору или изготовителю компьютера. Состояние: 0xc000000e Сведения: Сбой меню загрузки, поскольку требуемое устройство недоступно.

  Описание идентично, а коды разные!! Из этого следует, что одно текстовое сообщение об ошибке (сведения) может группировать сразу несколько родственных состояний (кодов ошибок). Если я нигде не ошибся, то для меня это, честно говоря, открытие! Получается, что разработчики решили особо не заморачиваться и не описывать в коде реакции на все возможные варианты ошибок, а ограничиться лишь конечным списком пояснений с выдачей конкретизирующего кода состояния (по которому и можно определить детали). И удивляться тут нечему, ведь данный факт опирается на бессмысленность генерации в коде реакции на все возможные состояния, поскольку код Bootmgr генерирует более 70 (!) уникальных ошибок, при том что многие неявны и по ним очень сложно работать, да и многие коды ошибок Bootmgr действительно одинаковы на разные события. Не думаю, что разработчик будет сидеть и корпеть над уникальным описанием для каждой ошибки.

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

Учитывая все вышеописанные обстоятельства, мы примем на вооружение следующую логику:

При возникновении ошибки сначала обращаем внимание на код состояния (NTSTATUS), как на наиболее информативный, а уж затем, при необходимости, руководствуемся сведениями об ошибке.

Собственно, этот постулат и будет у нас основополагающим, мы будем изучать ошибки Bootmgr, а не их описания. Это позволит нам более детально локализовать, конкретизировать проблему, то есть сделать её более определенной в причине собственного возникновения.

BmFatalErrorEx

Хотелось бы еще отдельно упомянуть основную процедуру для вывода сообщений об ошибках на консоль, именуемую BmFatalErrorEx. Она вызывается примерно из 9 мест на протяжении всего кода Bootmgr. Сама процедура предназначена для группировки ошибок по классам и вывода ограниченного количества сообщений об ошибках. Я думаю практически всем специалистам приведенный ниже шаблон достаточно хорошо знаком:

Указанная самой последней строка «Сведения» может содержать одну из нижеследующих текстовых строк:

Как можно заметить, не все ошибки имеют свою локализацию на русскому языке. Не знаю с чем это может быть связано, однако имеются две вероятных причины: я неправильно распарсил ресурсы главного модуля bootmgr.exe, либо пропустил какие-то записи в файле локализации bootmgr.exe.mui.
Ну и наконец то давайте уже переходит к анализу ошибок Bootmgr. Хотелось бы заметить, что вступление у нас было бы неполным, если бы сразу перешли к этапу Bootmgr и не осветили, хотя бы даже и поверхностно, стадии, которые ему предшествуют и относятся к процессу работы кода BIOS, MBR, PBR (VBR), ибо без них сюжетная линия повествования не была бы цельной.

Стадия BIOS

На IBM PC/AT-совместимой машине с классическим BIOS, код прошивки (firmware) на финальной стадии своего функционирования, по очереди перебирает устройства загрузки, заданные пользователем через меню настройки (Setup), и пытается считать с каждого из этих устройств загрузочный сектор. Сектор этот носит название Главной Загрузочной Записи (Master Boot Record, MBR). После загрузки с носителя загрузочного сектора, код BIOS проверяет наличие в последних двух байтах сигнатуры AA55h, и если сигнатура не обнаружена, то будет предпринята попытка перехода к другому устройству, если это устройство последнее в списке загрузки, то выдается одна из следующих ошибок (зависит от вендора оборудования):

Как Вы видите, с точки зрения ошибок финальная стадия BIOS достаточно проста, поскольку характеризуется всего-лишь невозможность нахождения кода MBR, а именно 512-байтного физического сектора с предопределенной сигнатурой AA55h.

Стадия MBR

Если коду BIOS удалось успешно считать первый физический сектор носителя в память и успешно проверить его сигнатуру, то он передает считанным данным управление. Начинает выполняться непосредственно сам код MBR. Поскольку в этом миниатюрном участке кода сложно выделить данные, то мы просто будем говорить о блоке кода и данных, который содержит всего три ошибки, детектируемые на стадии выполнения кода главной загрузочной записи. ASCII-строки ошибок располагаются во второй половине 512-байтного сектора и выглядят следующим образом:

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

Ошибка	Error loading operating system
Описание	Код не смог считать сектор с носителя при помощи функций прерывания int 13h. Ошибку возвращает код BIOS, который взаимодействует с портами контроллера. Проблема в BIOS? Это слишком старая материнская плата, у которой имеются проблемы с обработкой int 13h? Или физическая проблема контроллера/носителя?
Решение	Обновить/сбросить BIOS. Поменять материнскую плату на совместимую Проверить шлейф; Проверить накопитель на предмет аппаратных неисправностей.

Стадия PBR (VBR)

MBR нашел раздел, помеченный активным, загрузил с него первый физический сектор NTFS-раздела (партиции, тома) PBR (VBR), проверил его сигнатуру и передал ему управление. Как мы помним, основной целью кода PBR является загрузка Менеджера загрузки Windows (Windows Boot Manager, BootMgr) и передача ему управления.

Ошибка	A disk read error occurred
Описание	Универсальная комплексная ошибка, используемая кодом PBR сразу на нескольких стадиях: код PBR в попытке проверить самого себя (!) сравнивает начальные байты сектора с ASCII-значением NTFS (сигнатура, которая предваряет Boot Parameter Block, BPB) код не смог определить наличие расширений int 13h код пытается получить расширенный блок параметров диска при помощи int 13h код сравнивает значение из BPB, расположенного в начале сектора со значением, возвращенным функцией 48h прерывания int 13h.
Решение	Ваш BIOS не поддерживает расширения прерывания работы с диском 13h? Такие ситуации у нас полностью должны быть исключены, ну конечно если Вы не откопали совсем уж старую материнскую плату Во всех остальных случаях остается вариант с поврежденным блоком BPB в загрузочном секторе раздела. Его можно восстановить целиком со всем PBR, загрузившись в консоль восстановления и выполнив команду: bootrec /fixboot

Стадия Boot Manager (BOOTMGR)

Вот тут то у нас и начинается самое интересное, собственно то, ради чего данная статья и задумывалась. Код PBR(VBR) находит зарезервированный загрузочный раздел (System Reserved), находит в корне раздела файл Bootmgr и загружает его в память, затем передает ему управление. Стоит обратить отдельное внимание на оригинальный файл Bootmgr, располагающийся в корне зарезервированного раздела. Если Вы заметили он не имеет расширения, поскольку это не исполняемый PE-файл в привычном нам понимании, а составной файл, содержащий в начале 16-битную «заглушку» реального режима и «запакованный» 32-битный PE-файл bootmgr.exe. После загрузки в память управление получает именно 16-битная «заглушка», которая и занимается переводом процессора в 32-битный защищенный режим, использующий плоскую модель памяти, распаковкой оригинального .exe-файла и передачей ему управления.

Инициализация

Bootmgr.exe стартует с основной процедуры BmMain, которая сразу же начинает выполнять инициализацию внутренних структур и ключевых аппаратных компонентов системы при помощи процедуры: BlInitializeLibrary. Эта процедура включает в себя такие подпрограммы как InitializeLibrary, ReinitializeLibrary. Код которых, в свою очередь, друг за другом вызывает следующие процедуры:

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

Текст вывода намекает нам на то, что произошел сбой в какой-то из перечисленных выше подпрограмм. Поскольку данная ошибка охватывает достаточно большой диапазон кода и не имеет текстового описателя, то оператору будет довольно сложно понять в какой именно подпрограмме она возникла. Из этого следует, что единственный способ выявить причину, это попытаться вычислить её по коду ошибки. А что, в свою очередь, представляет из себя код 0xXXXXXXXX? Так ведь это же описанный выше NTSTATUS. Коды ошибок и их описания смотри в разделе ниже. Ну а мы двигаемся дальше.

Открытие BCD

После первичной инициализации логика bootmgr выполняет открытие файла данных конфигурации загрузки (BCD), который размещается:

• Для традиционной PC/AT (MBR) загрузки — на активном разделе по пути BootBCD;
• Для современной UEFI загрузки — на разделе EFI по пути EFIMicrosoftBootBCD;

Для достижения этой цели используется процедура под названием BmOpenDataStore.

Файл данных конфигурации загрузки (Boot Configuration Data, BCD) — база данных, содержащая конфигурацию отдельных аспектов этапа загрузки. По структуре идентична файлу реестра Windows, после загрузки монтируется в куст HKLMBCD00000000.

Как Вы уже поняли, BCD является одной из ключевых структур процесса загрузки, содержащей пункты меню загрузки, описывающие пути и настройки определенных элементов конфигурации. Естественно, что любые проблемы с этой базой сразу же выливаются в критические ошибки Bootmgr и невозможность продолжения процесса загрузки операционной системы.
Далее проверяются настройки журналирования этапов загрузки и если логгирование включено, то статус записывается в файл %SystemDrive%Bootbootstat.dat процедурой BmpInitializeBootStatusDatalog.
Затем процедура BlResourceFindHtml используется для поиска ресурсного файла bootmgr.xsl внутри ресурсной секции (.rsrc) образа файла bootmgr.exe.

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

Затем предпринимается попытка найти файл bootmgr.exe.mui, содержащий локализованные версии сообщений. На этапе поиска ресурсов, в случае возникновения проблем с нахождением/открытием оных, мы можем наблюдать ошибку:

Тут у нас ситуация, похожая ту, которая описывалась на этапе инициализации. Текст данной ошибки Bootmgr говорит о том, что в процедуре возникла проблема с нахождением ключевых ресурсов, которые потребуются в дальнейшей работе. Поскольку процедура многосоставная, то и источников проблемы может быть множество. Одной из причин данной ошибки могут быть проблемы с файлом bootmgr.xsl, поскольку без параметров, в нем описанных, дальнейшее выполнение невозможно. Коды ошибок у нас опять же сгруппированы в разделе под названием «Возникающие ошибки» ниже по тексту.
Далее ссылка на данные, загруженные из файла bootmgr.xsl передается процедуре BlXmiInitialize, которая предназначена для разбора содержимого файла и вывода на консоль меню загрузки на основе обнаруженных настроек. В случае, когда инсталлировано несколько операционных систем, либо присутствует несколько пунктов выбора, процедура отображает текстовое меню загрузки и ожидает пользовательского выбора.
при неудачном окончании процедуры выдается ошибка:

Ошибка говорит нам о том, что на этот раз уже с содержимым файла bootmgr.xsl что-то не так. Вероятно, присутствуют ошибки в операндах, структуре. Возможно, пользователь пытался изменить внешнее представление меню при помощи какой-то редактора и допустил ошибку.
Далее происходит проверка собственной цифровой подписи при помощи процедуры BmFwVerifySelfIntegrity. На этом этапе мы можем видеть ошибку C0000428.
Отдельно происходит проверка на наличии файла гибернации hiberfil.sys при помощи процедуры BmResumeFromHibernate, и в случае необходимости, код вызывает winresume.exe и начинает восстановление системы из режима гибернации.

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

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

Загрузка пункта и передача управления OSLoader

Этот этап у нас является финальным в логике работы модуля Bootmgr. Когда пункт загрузки выбран пользователем, либо назначен автоматически, процедура под названием BmpLaunchBootEntry начинает загружать выбранный пункт загрузки. Процедура BlImgStartBootApplication через подмножество вложенных процедур передает параметры и управление загрузчику операционной системы следующего этапа под названием winload.exe (OSLoader), располагающемуся на выбранном разделе по пути ?:WindowsSystem32winload.exe либо ?:WindowsSystem32bootwinload.exe.

Возникающие ошибки

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

Выводы

Изучение внутренней структуры ошибок Bootmgr достаточно трудоемкое и кропотливое занятие, требующее огромного количества времени, а самое главное, недюжих знаний, каковыми я пока что не обладаю. Следствием этого, как Вы могли уже заметить, является тот факт, что далеко не все ошибки Bootmgr освещены достаточно подробно. В отсутствии вменяемой логики анализа исходного кода приходится изучать ошибки Bootmgr по ассемблерному листингу в отладчике. Вероятно, кто-то из профессионалов реверсинга может посоветовать восстанавливать исходные тексты на языке C/C++ для упрощения восприятия, но и данными, казалось бы, необходимыми знаниями я пока не наделен. Поэтому, статья находится в статусе альфа как не до конца проработанная, тем не менее, надеюсь, что даже в таком сыром виде будет полезна кому-либо в качестве плацдарма для изучения специфических, возникающих на начальной стадии Bootmgr, ошибок. Какие выводы можно сделать по данному материалу? Я думаю, основной вывод, который напрашивается: невозможно точно характеризовать возникающую ошибку Bootmgr и определенно сказать об причине её возникновения даже по числовому идентификатору NTSTATUS, поскольку многие статусы имеют различные причины в различных функциях. Единственное что можно сделать, это попытаться по перебору возможных причин ошибки дойти до настоящего виновника сбоя, затем уже воспользовавшись для ошибки рекомендациями по устранению. Можно воспользоваться и общими алгоритмами, которые на каждом шагу можно встретить в Сети, однако не все из них действенны. Возможно, большинство ошибок, которые приведены в результирующей таблице, на практике никогда никому не встречались и скорее всего, в живой природе можно наблюдать значительно меньший диапазон ошибок, которые уже более-менее изучены и по которым написаны развернутые мануалы по устранению. Однако, судя по некоторым темам конференций, можно сказать, что раритетные ошибки всё же имеют место быть, поэтому в качестве отправной точки материал всё же пригодится.