15 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Boot Parameters to Enable Debugging

Загрузка

Меню Advanced Options (Меню дополнительных вариантов загрузки)

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

Если появится какое-либо меню , обратите внимание, что внизу экрана появится строка “For troubleshooting and advanced startup Options for Windows 2000 , press F8” (Для устранения проблем и дополнительных вариантов загрузки нажмите клавишу F8).

Если не появляется никакого меню (потому что компьютер выполняет автоматическую загрузку Windows Server 2003), вы можете нажать F8 по окончании этапа POST ( самотестирование при включении питания).

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

  • Safe Mode (Безопасный режим)
  • Safe Mode With Networking (Безопасный режим с сетевой поддержкой)
  • Safe Mode With Command Prompt (Безопасный режим с поддержкой командной строки)
  • Enable Boot Logging (Активизировать журнал загрузки)
  • Enable VGA Mode (Включить режим VGA )
  • Last Known Good Configuration (Загрузка последней удачной конфигурации)
  • Directory Services Restore Mode (Режим восстановления служб каталога – только для контроллеров доменов )
  • Debugging Mode (Отладочный режим)
  • Start Windows Normally (Обычная загрузка Windows)
  • Reboot (Перезагрузка)
  • Return to OS Choises Menu (Возврат в меню выбора операционных систем)

Используйте клавиши со стрелками для выбора нужного варианта в этом меню и нажмите клавишу Enter .

Safe Mode (Безопасный режим)

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

  • Safe Mode. Загрузка только базовых файлов и драйверов, необходимых только для запуска операционной системы: мышь, монитор , клавиатура, ЗУ, базовые средства видео и используемые по умолчанию системные службы .
  • Safe Mode With Networking. Добавляет сетевую поддержку ( драйверы сетевых адаптеров ), хотя это не подходит в случае сетевых адаптеров PCMCIA .
  • Safe Mode With Command Prompt. Переводит систему в текстовый режим вместо обычного графического режима ( GUI ). Используйте этот вариант в случае проблемы explorer .exe (но не Windows Explorer [Проводник] – графической оболочки, которая запускается программой explorer .exe). Вы можете выполнять из командной строки всевозможные задачи, включая открытие окна GUI (если вы знаете имя файла , открывающего это окно). Если оболочка explorer .exe работает правильно (или вы заменяете ее, работая в текстовом режиме), то вы можете открыть ее и использовать последовательность Start | Shut Down, чтобы перезагрузить компьютер. В противном случае для перезагрузки компьютер введите команду shutdown или нажмите CTL+ ALT + DEL , чтобы открыть диалоговое окно Windows Security и выбрать вариант Shut Down.

Enable Boot Logging (Активизировать журнал загрузки)

При выборе этого варианта Windows Server 2003 создает файл журнала ( %SystemRoot%Ntbtlog.txt ). В этом файле выводится список всех драйверов – загруженных и не загруженных. Ниже приводится небольшая часть типичного файла журнала Ntbtlog.txt (кстати, это файл в кодировке Unicode ).

  • Loaded driver WINDOWSsystem32ntoskrnl.exe
  • Loaded driver WINDOWSsystem32 hal . dll
  • Loaded driver WINDOWSsystem32KDCOM. DLL
  • Loaded driver WINDOWSsystem32BOOTVID. DLL
  • Loaded driver ACPI .sys
  • Loaded driver WINDOWSsystem32DRIVERSWMILIB.SYS
  • Loaded driver pci .sys
  • Loaded driver isapnp.sys
  • Loaded driver viaide.sys
  • Loaded driver WINDOWSsystem32DRIVERSPCIIDEX.SYS
  • Loaded driver MountMgr.sys
  • Loaded driver ftdisk.sys
  • Loaded driver dmload.sys
  • Loaded driver dmio.sys
  • Loaded driver PartMgr.sys
  • Loaded driver VolSnap.sys
  • Loaded driver atapi .sys
  • Loaded driver disk .sys
  • Loaded driver Ntfs .sys
  • Did not load driver SystemRootSystem32DriversChanger.SYS

Enable VGA Mode (Включить режим VGA)

Это вариант, знакомый пользователям Windows NT 4, используется для запуска Windows Server 2003 с использованием базового драйвера VGA . Используйте этот вариант, если вы установили новый видеодрайвер для своей видеокарты, и этот драйвер не работает (что становится очевидным при следующей загрузке, когда операционная система пытается войти в графический режим ). Базовый видеодрайвер – этот тот же драйвер, который используется при запуске Windows Server 2003 в одном из вариантов Safe Mode . Замените драйвер и затем перезагрузите компьютер.

Last Known Good Configuration (Загрузка последней удачной конфигурации)

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

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

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

Подраздел System в HKEY_LOCAL_MACHINE содержит три управляющих набора, доступных системе Windows Server 2003 во время загрузки: ControlSet001, ControlSet002 и CurrentControlSet. Каждый из этих разделов имеет одинаковую структуру подразделов.

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

Информация в подразделе Select показывает, что ControlSet001 и CurrentControlSet идентичны: все значения совпадают. CurrentControlSet – это дубликат ControlSet001, чтобы приложениям не нужно было определять, какой из нумерованных ControlSet используется для загрузки.

  • Элемент данных Current представляет управляющий набор, который был использован системой Windows Server 2003 во время загрузки для текущего сеанса .
  • Элемент данных Default представляет управляющий набор, который будет использоваться системой Windows Server 2003 при ее следующей загрузке, и это тот же набор, который используется на данный момент.
  • Элемент данных LastKnownGood представляет управляющий набор, который будет использоваться системой Windows Server 2003, если вы выберете вариант загрузки Last Known Good Configuration .
  • Элемент данных Failed указывает управляющий набор, в котором Windows Server 2003 сохраняет данные из неудачной загрузки. Этот управляющий набор не существует, пока пользователь не обратится к варианту загрузки Last Known Good Configuration .

После каждой успешной загрузки операционная система копирует данные из CurrentControlSet и ControlSet001 в ControlSet002. Затем, когда вы вносите изменения в конфигурацию, они записываются в CurrentControlSet и ControlSet001. Если не удается выполнить следующую загрузку, то при использовании варианта Last Known Good Configuration Windows Server 2003 использует данные из ControlSet002, представляющие состояние вашей системы на момент последней успешной загрузки.

Изменения в реестре после использования варианта Last Known Good Configuration

Если вы посмотрите подразделы System после использования варианта Last Known Good Configuration , то увидите, каким образом Windows Server 2003 работает с измененными управляющими наборами.

Появится новый подраздел с управляющим набором, ControlSet003, – на тот случай, если вы должны снова использовать Last Known Good Configuration . Windows Server 2003 перемещает устойчивый работающий управляющий набор “последней успешной загрузки” на одну ступень ниже. Если вы вносите изменения в конфигурацию, надеясь на этот раз установить все правильно (в отличие от предыдущего раза) и новые изменения тоже не позволяют выполнить загрузку, то у вас есть в запасе этот устойчивый управляющий набор. Если вы продолжаете использовать вариант Last Known Good Configuration и вносить изменения в конфигурацию, которые не позволяют устранить проблему, то система Windows Server 2003 создает нужное количество управляющих наборов, чтобы вам всегда был доступен набор с последней удачной конфигурацией.

Directory Services Restore Mode (Режим восстановления служб каталога)

Этот вариант доступен только для контроллеров домена, и он восстанавливает состояние системы для контроллера домена, включая папку %SystemRoot%Sysvol (где хранятся открытые файлы домена, которые реплицируются между контроллерами домена) и Active Directory .

Debugging Mode (Отладочный режим)

Используйте этот вариант для запуска Windows Server 2003 и передачи отладочной информации на другой компьютер через последовательный кабель . Это полезно при необходимости слежения за процессом загрузки с другого компьютера.

Создание загрузочной дискеты

Если один из файлов, который загружался раньше в процессе загрузки операционной системы (Ntldr, Ntdetect. com или Boot .ini), отсутствует или поврежден, вы не можете вывести меню Advanced Options , чтобы устранить проблемы своей системы. Чтобы справиться с этой ситуацией, вы можете использовать загрузочную дискету, созданную специально для вашего экземпляра Windows Server 2003.

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

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

  1. Поместите гибкий диск в дисковод.
  2. Откройте My Computer или Windows Explorer и щелкните правой кнопкой на обозначении гибкого диска.
  3. Выберите в контекстном меню пункт Format и отформатируйте гибкий диск, используя параметры по умолчанию.
  4. Скопируйте следующие файлы из корневой папки вашего жесткого диска на дискету.
    • Ntdetect.com
    • Ntldr
    • Boot .ini
    • Ntbootdd.sys (если он существует)

Проверьте дискету путем перезагрузки операционной системы.

Создание загрузочной дискеты на другом компьютере Windows Server 2003

Если у вас нет загрузочной дискеты, и не проходит загрузка, то вы можете создать такую дискету на другом компьютере, работающем под управлением Windows Server 2003 и имеющем такую же файловую систему ( NTFS , FAT или FAT32 ).

  1. Выполните описанные выше шаги для создания загрузочной дискеты.
  2. Откройте файл Boot .ini и убедитесь, что его содержимое соответствует конфигурации вашего компьютера. Если нет, то используйте информацию раздела “О файле Boot .ini” (см. выше), чтобы внести соответствующие изменения.
  3. Если у вас другой контроллер SCSI , найдите файл с подходящим драйвером и скопируйте его на дискету. Удалите файл Ntbootdd.sys, скопированный с компьютера, на котором вы создали эту дискету, и затем переименуйте этот драйвер SCSI в Ntbootdd.sys.
  4. Если на исходном компьютере используется контроллер IDE , а на вашем компьютере – контроллер SCSI , используйте Notepad (Блокнот), чтобы изменить соответствующие данные в файле Boot .ini, и затем скопируйте нужный драйвер SCSI на дискету и переименуйте его в Ntbootdd.sys.
  5. Если на исходном компьютере используется контроллер SCSI , а на вашем компьютере – контроллер IDE , используйте Notepad, чтобы изменить соответствующие данные в файле Boot .ini, и удалите файл Ntbootdd.sys, если скопировали его с исходного компьютера.

Проверьте эту загрузочную дискету на своем компьютере.

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

Если вы не можете найти другой компьютер, работающий с той же версией Windows Server 2003, то можете создать загрузочную дискету на другом компьютере, работающем под управлением Windows NT 4 или более поздней версии (включая клиентские версии Windows). Вам потребуется компакт-диск Windows Server 2003 или доступ к разделяемой точке сети, где содержатся установочные файлы Windows Server 2003. Затем выполните следующие шаги.

  1. Отформатируйте гибкий диск, используя параметры по умолчанию.
  2. На CD или в разделяемой сетевой папке выделите Ntldr и Ntdetect.com.
  3. Щелкните правой кнопкой и выберите Send To | 3 1/2 Floppy (A) [Отправить | Диск 3,5 (A)]
  4. Если ваш компьютер имеет контроллер SCSI , скопируйте соответствующий драйвер на дискету и переименуйте этот файл в Ntbootdd.sys.
  5. Используйте как модель файл Boot .ini и измените его содержимое в соответствии с конфигурацией вашего компьютера. Помните, что вы должны заменить ссылку WINNT на Windows, поскольку Windows Server 2003 использует Windows как имя папки для системных файлов.

Создание “быстрого” файла Boot.ini

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

Читать еще:  Где в телефоне находится архив сообщений. Как посмотреть историю уведомлений в Android

Если ваш компьютер загружается с жесткого диска IDE , замените scsi (0) на multi(0).

Enable Debugging Mode with and without Login on Windows 10

Some users would like to know how to enable debugging after logging in Windows 10 computer, while others may wonder how to enable it if failed to log on the computer. Therefore, this article respectively illustrates how to enable debugging mode with and without login.

Part 1: Enable debugging mode with login on Windows 10

Step 2: Choose Update and recovery.

Step 3: Select Recovery and tap Restart now under Advanced startup.

Step 4: Choose Troubleshoot to continue.

Step 5: Open Advanced options.

Step 6: Enter Startup Settings.

Step 7: Click Restart.

Step 8: Press 1 or F1 to select Enable debugging.

Part 2: Enable debugging mode without login on Windows 10

Step 1: Restart the computer from the login screen.

Tap the bottom-right Power button, and then simultaneously press Shift key and click Restart on the menu.

Step 2: Select Troubleshoot.

Step 3: Choose Advanced options.

Step 4: Open Startup Settings.

Step 5: Tap Restart.

Step 6: After restarting, hit 1 or F1 to choose Enable debugging.

Tip: For illustration of the operation from the 2nd step to the 6th step, please refer to the corresponding screenshots in Part 1.

Related Articles:

iSunshare is dedicated to providing the best service for Windows, Mac, Android users who are in demand for password recovery and data recovery.

Copyright В© 2020 iSunshare Studio All Rights Reserved.

Diagnosing Boot Problems

If your machine gets stuck during boot, first check if the hang happens before or after control passes to systemd.

Try to boot without rhgb and quiet on the kernel command line. If you see some messages like these:

then systemd is running. (See an actual screenshot.)

Debugging always gets easier if you can get a shell. If you do not get a login prompt, try switching to a different virtual terminal using CTRL+ALT+F_ _. Problems with a display server startup may manifest themselves as a missing login on tty1, but other VTs working.

If the boot stops without presenting you with a login on any virtual console, let it retry for up to 5 minutes before declaring it definitely stuck. There is a chance that a service that has trouble starting will be killed after this timeout and the boot will continue normally. Another possibility is that a device for an important mountpoint will fail to appear and you will be presented with emergency mode.

If You Get No Shell

If you get neither a normal login nor the emergency mode shell, you will need to do additional steps to get debugging information out of the machine.

  • Try CTRL+ALT+DEL to reboot.
    • If it does not reboot, mention it in your bugreport. Meanwhile force the reboot with SysRq or hard reset.
  • When booting the next time, you will have to add some kernel command line arguments depending on which of the debugging strategies you choose from the following options.

Debug Logging to a Serial Console

If you have a hardware serial console available or if you are debugging in a virtual machine (e.g. using virt-manager you can switch your view to a serial console in the menu View -> Text Consoles or connect from the terminal using virsh console MACHINE ), you can ask systemd to log lots of useful debugging information to it by booting with:

The above is useful if pid 1 is failing, but if a later but critical boot service is broken (such as networking), you can configure journald to forward to the console by using:

console= can be specified multiple times, systemd will output to all of them.

Booting into Rescue or Emergency Targets

To boot directly into rescue target add systemd.unit=rescue.target or just 1 to the kernel command line. This target is useful if the problem occurs somewhere after the basic system is brought up, during the starting of “normal” services. If this is the case, you should be able to disable the bad service from here. If the rescue target will not boot either, the more minimal emergency target might.

To boot directly into emergency shell add systemd.unit=emergency.target or emergency to the kernel command line. Note that in the emergency shell you will have to remount the root filesystem read-write by yourself before editing any files:

Common issues that can be resolved in the emergency shell are bad lines in /etc/fstab. After fixing /etc/fstab, run systemctl daemon-reload to let systemd refresh its view of it.

If not even the emergency target works, you can boot directly into a shell with init=/bin/sh . This may be necessary in case systemd itself or some libraries it depends on are damaged by filesystem corruption. You may need to reinstall working versions of the affected packages.

If init=/bin/sh does not work, you must boot from another medium.

Early Debug Shell

You can enable shell access to be available very early in the startup process to fall back on and diagnose systemd related boot up issues with various systemctl commands. Enable it using:

or by specifying

on the kernel command line.

Tip: If you find yourself in a situation where you cannot use systemctl to communicate with a running systemd (e.g. when setting this up from a different booted system), you can avoid communication with the manager by specifying –root= :

Once enabled, the next time you boot you will be able to switch to tty9 using CTRL+ALT+F9 and have a root shell there available from an early point in the booting process. You can use the shell for checking the status of services, reading logs, looking for stuck jobs with systemctl list-jobs , etc.

Warning: Use this shell only for debugging! Do not forget to disable systemd-debug-shell.service after you’ve finished debugging your boot problems. Leaving the root shell always available would be a security risk.

It is also possible to alias kbrequest.target to debug-shell.service to start the debug shell on demand. This has the same security implications, but avoids running the shell always.

verify prerequisites

A (at least partly) populated /dev is required. Depending on your setup (e.g. on embedded systems), check that the Linux kernel config options CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT are set. Also support for cgroups and fanotify is recommended for a flawless operation, so check that the Linux kernel config options CONFIG_CGROUPS and CONFIG_FANOTIFY are set. The message “Failed to get D-Bus connection: No connection to service manager.” during various systemctl operations is an indicator that these are missing.

If You Can Get a Shell

When you have systemd running to the extent that it can provide you with a shell, please use it to extract useful information for debugging. Boot with these parameters on the kernel command line:

in order to increase the verbosity of systemd, to let systemd write its logs to the kernel log buffer, to increase the size of the kernel log buffer, and to prevent the kernel from discarding messages. After reaching the shell, look at the log:

When reporting a bug, pipe that to a file and attach it to the bug report.

To check for possibly stuck jobs use:

The jobs that are listed as “running” are the ones that must complete before the “waiting” ones will be allowed to start executing.

Diagnosing Shutdown Problems

Just like with boot problems, when you encounter a hang during shutting down, make sure you wait at least 5 minutes to distinguish a permanent hang from a broken service that’s just timing out. Then it’s worth testing whether the system reacts to CTRL+ALT+DEL in any way.

If shutdown (whether it be to reboot or power-off) of your system gets stuck, first test if the kernel itself is able to reboot or power-off the machine forcedly using one of these commands:

If either one of the commands does not work, it’s more likely to be a kernel, not systemd bug.

Shutdown Completes Eventually

If normal reboot or poweroff work, but take a suspiciously long time, then

boot with the debug options:

save the following script as /usr/lib/systemd/system-shutdown/debug.sh and make it executable:

Look for timeouts logged in the resulting file shutdown-log.txt and/or attach it to a bugreport.

Shutdown Never Finishes

If normal reboot or poweroff never finish even after waiting a few minutes, the above method to create the shutdown log will not help and the log must be obtained using other methods. Two options that are useful for debugging boot problems can be used also for shutdown problems:

  • use a serial console
  • use a debug shell – not only is it available from early boot, it also stays active until late shutdown.

Status and Logs of Services

When the start of a service fails, systemctl will give you a generic error message:

The service may have printed its own error message, but you do not see it, because services run by systemd are not related to your login session and their outputs are not connected to your terminal. That does not mean the output is lost though. By default the stdout, stderr of services are directed to the systemd journal and the logs that services produce via syslog(3) go there too. systemd also stores the exit code of failed services. Let’s check:

In this example the service ran as a process with PID 1329 and exited with error code 1. If you run systemctl status as root or as a user from the adm group, you will get a few lines from the journal that the service wrote. In the example the service produced just one error message.

To list the journal, use the journalctl command.

If you have a syslog service (such as rsyslog) running, the journal will also forward the messages to it, so you’ll find them in /var/log/messages (depending on rsyslog’s configuration).

Reporting systemd Bugs

Be prepared to include some information (logs) about your system as well. These should be complete (no snippets please), not in an archive, uncompressed.

Please report bugs to your distribution’s bug tracker first. If you are sure that you are encountering an upstream bug, then first check for existing bug reports, and if your issue is not listed file a new bug.

Information to Attach to a Bug Report

Whenever possible, the following should be mentioned and attached to your bug report:

The kernel’s command-line parametersВ¶

The following is a consolidated list of the kernel parameters as implemented by the __setup(), core_param() and module_param() macros and sorted into English Dictionary order (defined as ignoring all punctuation and sorting digits before letters in a case insensitive manner), and with descriptions where known.

The kernel parses parameters from the kernel command line up to “–”; if it doesn’t recognize a parameter and it doesn’t contain a ‘.’, the parameter gets passed to init: parameters with ‘=’ go into init’s environment, others are passed as command line arguments to init. Everything after “–” is passed as an argument to init.

Module parameters can be specified in two ways: via the kernel command line with a module name prefix, or via modprobe, e.g.:

Parameters for modules which are built into the kernel need to be specified on the kernel command line. modprobe looks through the kernel command line (/proc/cmdline) and collects module parameters when it loads a module, so the kernel command line can be used for loadable modules too.

Читать еще:  9 приложений, которые нужны любому гитаристу

Hyphens (dashes) and underscores are equivalent in parameter names, so:

can also be entered as:

Double-quotes can be used to protect spaces in values, e.g.:

cpu lists:В¶

Some kernel parameters take a list of CPUs as a value, e.g. isolcpus, nohz_full, irqaffinity, rcu_nocbs. The format of this list is:

Note that for the special case of a range one can split the range into equal sized groups and for each group use some amount from the beginning of that group:

For example one can add to the command line following parameter:

where the final item represents CPUs 100,101,125,126,150,151.

This document may not be entirely up to date and comprehensive. The command “modinfo -p $” shows a current list of all parameters of a loadable module. Loadable modules, after being loaded into the running kernel, also reveal their parameters in /sys/module/$/parameters/. Some of these parameters may be changed at runtime by the command echo -n $ > /sys/module/$/parameters/$ .

The parameters listed below are only valid if certain kernel build options were enabled and if respective hardware is present. The text in square brackets at the beginning of each description states the restrictions within which a parameter is applicable:

In addition, the following text indicates that the option:

Parameters denoted with BOOT are actually interpreted by the boot loader, and have no meaning to the kernel directly. Do not modify the syntax of boot loader parameters without extreme need or coordination with .

There are also arch-specific kernel-parameters not documented here. See for example .

Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up.

The number of kernel parameters is not limited, but the length of the complete command line (parameters including spaces etc.) is limited to a fixed number of characters. This limit depends on the architecture and is between 256 and 4096 characters. It is defined in the file ./include/asm/setup.h as COMMAND_LINE_SIZE.

Finally, the [KMG] suffix is commonly described after a number of kernel parameter values. These ‘K’, ‘M’, and ‘G’ letters represent the _binary_ multipliers ‘Kilo’, ‘Mega’, and ‘Giga’, equaling 2^10, 2^20, and 2^30 bytes respectively. Such letter suffixes can also be entirely omitted:

Troubleshooting Windows 10

  • Getting to know your troubleshooting toolkit
  • Event Viewer
  • Dealing with Stop errors
  • Troubleshooting with alternative boot options

As they say, stuff happens. That might not be exactly how the famous quote goes, but it’s certainly true whenever hardware and software are involved.

Although Windows has generally become more stable and reliable over time, it will never be perfect. Apps hang (stop responding) or crash (shut down unexpectedly). Once in a while, a feature of Windows walks off the job without warning. And on rare occasions, the grim BSOD (“blue screen of death,” more formally known as a Stop error or bugcheck) arrives, bringing your whole system to a halt.

In a fully debugged, perfect world, such occurrences would never darken your computer screen. But you don’t live there, and neither do we. So the prudent course is to prepare for the unexpected. That starts with making regular backups, of course, along with system restore points. But it also entails learning to use the many tools that Windows provides for diagnosing errors and recovering from problems. Those tools are the subject of this chapter.

  • For information about creating regular backups and image backups as well as information about system restore points, see Chapter 16, “Backup, restore, and recovery.”

Getting to know your troubleshooting toolkit

As any detective will tell you, solving a mystery requires evidence. If your mystery involves inexplicably slow performance or crashes, you have several places to look for clues.

Built-in troubleshooters

The most obvious first step on the road to resolving performance issues is the aptly named Troubleshooting section in the classic Control Panel. By default, it displays a list of the most commonly used troubleshooters included with Windows 10, as shown in Figure 17-1.

Figure 17-1 Each of the troubleshooters included with Windows 10 launches an interactive problem-solving tool that steps you through diagnosis and resolution of common problems.

Click the View All link on the left of the Troubleshooting page to see an expanded list that includes modules for fixing more esoteric problems, such as issues with search and indexing or with the Background Intelligent Transfer Service.

There’s nothing magical about any of these troubleshooters. Their purpose is to ensure that you check the most common causes of problems, including some that might seem obvious (Is the network cable plugged in? Is the printer turned on?). Running a troubleshooter can result in easy fixes for some issues; more importantly, it establishes a baseline for further troubleshooting.

A troubleshooter might lead you through several steps and ask you to check settings or connections. At the end, it displays its results, which include a View Detailed Information link that displays a troubleshooting report similar to the one shown in Figure 17-2.

Figure 17-2 The troubleshooting report lists issues and indicates whether they were fixed. Click the Detection Details link to see more granular information about that item.

Inside OUT: Microsoft Fix It provides another self-repair option

Using technology similar to the troubleshooting packs, Microsoft Fix It provides online configuration settings and solutions to a variety of problems. Typically, a Fix It solution allows you to automatically apply a system setting that would otherwise require manual work, such as editing the registry. You can find a full listing of existing Fix It solutions at support2.microsoft.com/fixit, although many of the entries there apply only to earlier Windows versions. It’s more common to find a new Fix It associated with a Knowledge Base article that identifies a workaround or mitigation for a security or reliability issue before an update is available.

Windows Error Reporting

Often an early indication that something is amiss is an error message informing you that an application is “not responding”—as if you hadn’t figured that out already. If the application doesn’t come back to life, you kill the process with Task Manager and move on, ideally without losing any data.

While all that’s happening, the Windows Error Reporting (WER) service runs continuously in the background, keeping track of software and driver installations (successful and otherwise) as well as crashes, hangs, and other system events that indicate a possible problem with Windows. (In fact, although the service and programs that enable the feature are called Windows Error Reporting, the term you’re more likely to see in Windows is problem reporting.) Microsoft provides this diagnostic information to the developers of the program that caused the error (including Microsoft developers when the issue occurs with a feature in Windows, Office, or another Microsoft program). The goal, of course, is to improve quality by identifying problems and delivering fixes through Windows Update.

In previous versions, Windows was downright chatty about reporting crashes, successful updates, and minor speed bumps. In Windows 10, most of these problem reports (including diagnostic reports sent after successful upgrades) are completely silent, but each report is logged. You can use the history of problem reports on a system to review events and to see whether any patterns demand additional troubleshooting.

To open the Problem Reports log, type problem reports in the search box and then click View All Problem Reports. Figure 17-3 shows a portion of the error history for a computer that was upgraded to Windows 10 in the first month after it was available.

Figure 17-3 The list of saved problem reports displays only the two most recent reports in each group; click More to see earlier reports.

If the words Solution Available appear in the Status column for an item, right-click that item and then click View Solution. Note also that the shortcut menu includes commands to group the entries in the list of problem reports by source (the default view, shown in Figure 17-3), summary, date, or status—or you can choose Ungroup to see the entire, uncategorized list. With the list grouped or not, you can sort by any field by clicking the field’s column heading.

You can see a more detailed report about any event in this log by double-clicking the event. The Description field is usually written clearly enough to provide potentially useful information. The rest of the details might or might not be meaningful to you, but they could be helpful to a support technician. Some reports include additional details sent in a text file that you can inspect for yourself. In Figure 17-4, for example, a file called WERInternalMetadata.xml captures information about the Windows installation and its memory use. None of this information is personal or linked to your PC.

Figure 17-4 You can review the contents of a problem report, including any additional information sent as file attachments, before or after it’s sent.

By default, Windows 10 configures your system so that it sends a generous amount of diagnostic and feedback information, including error reports that could inadvertently contain personal information. If you are concerned about data use or privacy, you can dial back the amount of diagnostic information by using the Feedback & Diagnostics page under the Privacy heading in Settings. Figure 17-5 shows the default settings.

Figure 17-5 If you’re concerned about sensitive data leaking out as part of diagnostic reports, consider changing the Diagnostic And Usage Data setting from its default of Full.

The Feedback Frequency setting at the top of this page controls how often Microsoft asks you about your use of features. If you prefer to be left alone, set this to Never.

The second heading, Diagnostic And Usage Data, allows you to specify how much diagnostic information your Windows 10 device sends to Microsoft servers as part of its normal operation. Much of that information is from problem reports, which rarely mean much by themselves but can be tremendously important as part of a larger data set to pinpoint the cause of problems. There are three available settings:

  • Basic. This level includes data that is fundamental to the operation of Windows and Windows Update. It includes information about the capabilities of your device, what is installed, and whether Windows is operating correctly (which includes sending basic error reports to Microsoft). No personally identifiable information is included.
  • Enhanced. Along with the data sent with the Basic setting, this setting adds data about how you use Windows (how often you use certain features or apps, for example) and collects enhanced diagnostic information, such as the memory state of your device when a system or app crash occurs. Information sent to Microsoft also includes reliability data for devices, the operating system, and apps.
  • Full (Recommended). This setting, which is enabled by default, includes the full set of information from the Basic and Enhanced levels and turns on advanced diagnostic features that provide much more detailed error reports. These reports might include system files or memory snapshots that could include the contents of a file or message you were working on when the problem occurred. If a report inadvertently contains personal or sensitive information, Microsoft’s privacy policy says the information will not be used to identify, contact, or target advertising to you.
Читать еще:  ТОП-7 лучших смартфонов iPhone 2019 года: какой купить, характеристики и отзывы

The basic report that Windows Error Reporting transmits typically includes information such as the application name and version, module name and version, exception (error) code, and offset. Hardware reports include Plug and Play IDs, driver versions, and other system details. The likelihood that any of these items will convey personally identifiable information is essentially nil. The process does transmit your IP address to a Microsoft server, but Microsoft’s privacy statement asserts that the IP address is used only to generate aggregate statistics and will not be used to identify you.

In work environments, your network administrators will almost certainly disable the sending of advanced error reports that might inadvertently disclose confidential information.

If privacy is a major concern, you should, of course, read Microsoft’s privacy statement for this feature, which is available at bit.ly/win10-feedback-privacy. Although most people are understandably reluctant to send information to a faceless corporation, remember that this is a two-way street. You’re sending information about a problem, and there’s a good chance that, in return, you’ll receive a solution to the problem, as explained in the next section. (Remember, too, that the engineers who analyze the problem information to develop solutions are not faceless!)

Reliability Monitor

Windows 10 keeps track of a wide range of system events. For a day-by-day inventory of these events, type reliability in the search box and then click the top result, View Reliability History. That opens Reliability Monitor, shown in Figure 17-6.

Figure 17-6 Reliability Monitor rates your system’s stability on a scale of 1 (wear a crash helmet) through 10 (smooth sailing). This PC has had a rough week.

Each column in the graphical display represents events of a particular day (or week, if you click that option in the upper left corner). Each red X along the first three lines below the graph (the various “Failures” lines) indicates a day on which problems occurred. The “Warnings” line describes minor problems unrelated to system reliability, such as a program whose installation process didn’t complete properly. The last line below the graph—the line marked Information—identifies days on which an app or an update was installed or removed. You can see the details about the events of any day by clicking on the graph for that day. Reliability Monitor retains its system stability records for one year, giving you plenty of history to review.

This history is most useful when you begin experiencing a new problem and are trying to track down its cause. Examine the critical events for the period when the problem began, and see whether they correspond with an informational item, such as a program installation. The alignment of these events could be mere coincidence, but it could also represent the first appearance of a long-term problem. Conjunctions of this sort are worth examining. If you think a new software application has destabilized your system, you can try uninstalling it.

Double-clicking any item exposes its contents, which are filled with technical details that are potentially useful, confusing, or both.

Although the various signatures and details for each such incident by themselves are probably just baffling, they’re much more useful in the aggregate. Armed with a collection of similar reports, an engineer can pin down the cause of a problem and deliver a bug fix. If a previously common error suddenly stops appearing in the logs, chances are it was resolved with an update.

Note also that you can click the link in the Action column to take additional steps, such as searching for a solution or viewing the technical details of a particular event.

Boot Parameters to Enable Debugging

ˇ1. необходимо изучить основные понятия (хотя бы): в шапке “Термины (определения)” (все) + “Общая теория” ( релиз “немного старый”, но общее представление дает) ;
++ “в идеале” – разобраться со “Списком открытых вопросов”
ˇ2. предоставить“абсолютный минимум” необходимой инфо (“правила темы”):

  1. ссылки на //4pda.ru/devdb/ (описание аппарата) и тему прошивки (/обсуждение) аппарата на 4pda
  2. [под спойлер!] инфо о разделах внутр. памяти – (желательно – с размерами разделов) (пример); возможно – попросить/получить в теме своего аппарата
  3. [под спойлер!] идентификаторы USB VID/PID аппарата во всех комбинациях кнопок/аккумулятора: проверить все варианты
  4. [под спойлер!] что было сделано с аппаратом перед тем, как он оказался в таком состоянии? что было испробовано из приведенных в теме методов/подходов?(детально!)
  5. [под спойлер!] вывод qblinfo одного из загрузчиков (/программера) – с прошивки (/дампа). (зачем, еще пример вывода )
  6. сколько часов на (родной?) зарядке был аппарат перед диагностикой? (FLCB ?); желательно – также уровень заряда аккумулятора (mV / mA) ?
  7. на скольких ПК (/каких ОС) было проведено диагностику?
  8. [под спойлер!] собственные соображения/предположения(/сомнения(/вопросы)) относительно возможных вариантов решения

в случае отсутствия “абсолютного минимума” необходимой инфо – сообщение будет удалено.

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

зыы: (рекомендовано) – Как правильно задавать вопросы?

  • собрать и систематизировать (“привести к “удобо-понятному” виду) общую терминологию и определения
  • систематизировать и найти общие методологические принципы и подходы восстановления
  • .
  • собрать рабочие наборы (“кейсы”) восстановления кирпичей на Qualcomm
  • .
  • разработать типовые рекомендации по составлению “кейсов восстановления” аппаратов Qualcomm для которых нет готовых кейсов

____________

  • ответы ув. vvevvevve, :thank_you: — лучше начать отсюда – и далее по теме (минимум 2 страницы)
  • Возможно ли использовать один и тот же программер (xPRG****.hex(/mbn)) на разных аппаратах но с одним и тем же SoC? ответ1
  • .

_____________

Общие особенности архитектуры Qualcomm
Процесс загрузки Qualcomm
Состояния в которых может “находится” аппарат
Как определить состояние аппарата
Протоколы работы с аппаратом
Общая “архитектура процесса” восстановления
Для информации. (by VVitaly, :thank_you: )
особенности загрузки устройств на NAND-флешке (by vvevvevve, :thank_you: )
Если не работает SB, то главный критерий – “близость” поколений платформ
Подборка всех известных подписанных программеров

—————-
“интересные заметки” (о фастбуте) + “продолжение”
nv параметр отвечающий за усиление микрофона (by =S=, :thank_you: )

Большая база распиновок jtag для большинства моделей смартфонов спасибо Vladimirs77,
Общие принципы восстановления загрузчиков на Qualcomm (Пост Vladimirs77 #50087863)

стандарты UFS (Universal Flash Storage) – спасибо Kramar111,

===
Qualcomm Snapdragon S4 Pro APQ8064:
ZTE Nubia Z5 (NX501)

актуальные версии QPST из сети (QPST2.7.422-437) – спасибо! peter23,
Общие принципы восстановления загрузчиков на Qualcomm (Пост peter23 #50215409)

утилиты для работы с IMEI – спасибо ув. ariafan, ссылка и ув. acdev, ссылка

Файл автоматической конвертации HEX значений gpt.bin (полученного dd if=/dev/block/mmcblk0 of=/sdcard/gpt.bin bs=8 count=2176) в текстовое содержание rawprogram0.xml средствами excel – спасибо Bazzz2,

recovery script for collecting the partitions info (mmcblk0info.sh/zip):
http://forum.xda-devel…=56569542&postcount=71

Средство по работе с прошивками Qualcomm by vin2809,

®Partitions Backup & Restore Немного скриншотов для пояснения процесса:®Partitions Backup & Restore (Пост aleha81 #39380773)
Partitions Backup & Restore v1.6.0 RUS – спасибо htc 600,

мод. fastboot.exe, котрый “умеет” посылать команду “reboot-edl” бутлоадеру “напрямую” (без приставки “oem”) – командной строкой “fastboot_edl reboot-edl”;
спасибо emusic, Общие принципы восстановления загрузчиков на Qualcomm (Пост emusic #50224890)

emmcdl:
спасибо peter23, “за находку” 🙂
Видна поддержка firehose, видна возможность считывать флешку с телефона, а не только записывать (в первую очередь именно этим и интересна).
Общие принципы восстановления загрузчиков на Qualcomm (Пост peter23 #50287938)

набор батников для автоматизированных чтения/записи разделов через emmcdl – спасибо emusic,
Общие принципы восстановления загрузчиков на Qualcomm (Пост emusic #50332273)

полный дамп флешки:
* как снять полный дамп флешки если нет слота для SD-карты + универсальный и платформонезависимый – скрипт :thank_you: vvevvevve,
* и попроще (но “негарантировано”) Общие принципы восстановления загрузчиков на Qualcomm (Пост wladimir_tm #41497005)
* на habrahabr.ru: ссылка на инструкцию Общие принципы восстановления загрузчиков на Qualcomm (Пост олежек1975 #43247628)
————–
** “прямо на (живом) аппарате” сделать “восстановительную SD”

“даже на WinXP” – нужно “отключать проверку подписи” драйверов :thank_you: Magnat.mg

“инструкция в картинках”: QFIL Резервное копирование и восстановление EFS: Lenovo S90 – Прошивки (OS 4.4.4 – 5.X.X ) (Пост MATVEЙ #40689013)

“примерный пример” по прошивке с помощью MiFlash:

20160915
для новичков в теме:
обязательным условием написания сообщений в данной теме есть: предоставить “абсолютный минимум” необходимой инфо для своего аппарата.
в случае если не понятно как “это” получить:
1. сразу искать нормальный СЦ (“сервис центр”)
2. обращаться в соответствующий раздел форума (=Технотрепалка)
зы: с случае невыполнения данного условия – сообщения новичков будут удалены (и конечно же – оставлены без ответа)

если у Вас нету возможности/желания предоставить информацию по всех пунктах выше, но есть желание получить совет от участников этой темы – сформулируйте вопрос в теме своего аппарата, а здесь – только линк на соотв. пост в теме Вашего аппарата;
если у кого нибудь из участников этой темы будет возможность/желание – то Вы получите ответ в теме Вашего аппарата[/i]

20160902
стандарты UFS (Universal Flash Storage) – спасибо Kramar111,

“абсолютный минимум” необходимой инфо:[/b][background][list=1 ][*]ссылки на //4pda.ru/devdb/ (описание аппарата) и тему прошивки(/обсуждением) аппарата на 4pda [*][под спойлер!]инфо о раделах внутр. памяти – с размерами разделов (пример)
зы: если у Вас нету возможности/желания предоставить информацию по всех пунктах выше, но есть желание получить совет от участников этой темы – сформулируйте вопрос в теме своего аппарата, а здесь – только линк на соотв. пост в теме Вашего аппарата;
если у кого нибудь из участников этой темы будет возможность/желание – то Вы получите ответ в теме Вашего аппарата

[*] если у Вас нету возможности/желания предоставить информацию по всех пунктах выше, но есть желание получить совет (возможно) от участником даной темы – сформулируйте свой вопрос в теме своего аппарата, а в этой теме – только линк на соотв. пост в теме Вашего аппарата;
если у кого нибудь из участником этой темы будет возможность/желание – то Вам ответят в теме Вашего аппарата

20160612
набор батников для автоматизированных чтения/записи разделов через emmcdl – спасибо emusic,
Общие принципы восстановления загрузчиков на Qualcomm (Пост emusic #50332273)

20160611
change
“абсолютный минимум” необходимой инфо
п.5 п.1

emmcdl:
спасибо peter23, “за находку” 🙂
Видна поддержка firehose, видна возможность считывать флешку с телефона, а не только записывать (в первую очередь именно этим и интересна).
Общие принципы восстановления загрузчиков на Qualcomm (Пост peter23 #50287938)
+ Нашел более свежую версию 2.15 Общие принципы восстановления загрузчиков на Qualcomm (Пост peter23 #50314988)

Большая база распиновок jtag для большинства моделей смартфонов спасибо Vladimirs77,
Общие принципы восстановления загрузчиков на Qualcomm (Пост Vladimirs77 #50087863)

мод. fastboot.exe, котрый “умеет” посылать команду “reboot-edl” бутлоадеру “напрямую” (без приставки “oem”) – командной строкой “fastboot_edl reboot-edl”;
спасибо emusic, Общие принципы восстановления загрузчиков на Qualcomm (Пост emusic #50224890)

20160608
актуальные версии QPST из сети (QPST2.7.422-437) – спасибо! peter23,
Общие принципы восстановления загрузчиков на Qualcomm (Пост peter23 #50215409)

утилиты для работы с IMEI – спасибо ув. ariafan, ссылка и ув. acdev, ссылка

Partitions Backup & Restore v1.6.0 RUS – спасибо htc 600,

CORR:
[*][под спойлер!] cmdline офф. прошивки и lsusb (USB VID/PID) своего аппарата во всех комбинациях кнопок/аккумулятора: проверить все комбинации

20160513
modiff: прежде чем задавать вопросы:

голоса
Рейтинг статьи
Ссылка на основную публикацию
Статьи c упоминанием слов: