Sara Perrott - Windows Server 2022 & Powershell All-in-One For Dummies

Safe Mode with Networking is most useful when you’re trying to resolve a software or driver issue. It allows you to download replacement software or replacement drivers while still in Safe Mode. Then you can replace the misbehaving driver or incompatible software with a known good version and then boot successfully.

In Safe Mode with Command Prompt, you bypass the Explorer desktop environment. This can be especially useful if the desktop is not displaying properly for whatever reason.

If you like Server Core, you’ll like this version of Safe Mode. If you aren’t as comfortable with the command window as you would like to be, having a cheat sheet available may help you.

I recommend Safe Mode with Command Prompt when the issue that needs to be fixed has something to do with graphics. The problem may be due to a driver, graphics rendering, or removing a malware infection that relied on graphical components like wallpapers and screensavers.

If you need to see which drivers were installed as the system started up, you should choose Enable Boot Logging. This will create a file called ntbtlog.txt, which lists all the drivers that were installed when the operating system started. The file is stored in your Windows system directory; typically, this will be C:\WINDOWS. Incidentally, this is the same list you see flash by on the screen when you boot into Safe Mode.

This setting is very useful if you're having display issues, most commonly after changing display settings to something your monitor doesn’t support. It uses the currently installed video driver but starts with lower resolution (typically 640 x 480) and refresh settings.

Last Known Good Configuration is helpful in fixing issues with booting that occur because the Windows Registry has been damaged. Most commonly, this occurs due to user misconfiguration or from updates or patches. When you choose Last Known Good Configuration, the Registry is reverted so that it matches the settings it had the last time the system booted successfully.

Any time you use something that modifies the Registry in any way, be extra cautious. There’s no way to undo using Last Known Good Configuration. If it doesn’t fix the issue, or it makes matters worse, you’ll need to restore from a backup.

This option only appears on a server that is a domain controller (and, therefore, it isn’t shown in Figure 2-4). Directory Services Restore Mode (DSRM) is a special form of Safe Mode made for domain controllers that allows you to repair or recover an Active Directory database.

To use this utility you need to know the DSRM password that was set when the domain controller was initially created. If you don’t know the password, you can use the ntdsutil tool to change the password. You need to have access to the Command Prompt on the system in question to run it.

If all of this is Greek to you, don’t worry! I cover Active Directory in depth in Book 2, Chapter 5. For now, think of Active Directory like a special database that stores information on users, computers, sites, and other objects in your network. This database can be crucial to your organization, so knowing how to restore it if it becomes damaged is a very useful skill.

If you’re a hard-core system administrator and you want to get your feet wet using a kernel debugger, this option is for you!

The kernel is a program that is one of the first to run when your server boots (the kernel loads right after the bootloader); it has total control over everything on your system.

Debugging Mode turns on kernel debugging, which allows you to work with the kernel debugger to examine states and processes that are running at the kernel level. This can be very useful for troubleshooting issues with device drivers that cause the infamous blue screen of death and issues with the central processing unit (CPU). You can look at the kernel memory dump on the system that is having the issue, or you can view the kernel memory dump remotely on another system via a serial connection. The information from the Debugging Mode is typically made available over the COM1 port (assuming you have a serial port and it’s assigned to COM1). On newer systems that don’t have a serial port, you can also access this information over USB.

Kernel debugging is not for the faint of heart. For more information on how to set up your system for kernel debugging with either serial or USB connectivity, check out the following articles:

Serial connection: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-null-modem-cable-connection

USB connection: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-usb-3-0-debug-cable-connection

COM ports were typically presented as serial ports with RS-232 connectors on older systems. On newer systems, these have been replaced with USB ports. USB stands for Universal Serial Bus — it’s still a serial connection.

Eventually, every system administrator has a system that will continuously try to start, fail, reboot, and then try to start, fail, reboot, and so on. This situation is known as a boot loop. If you’re experiencing a boot loop on one of your systems, you can get the system to stop automatically restarting by choosing Disable Automatic Restart on System Failure from the Advanced Boot Options menu.

Disabling automatic restart can be very helpful if the system is getting the blue screen of death and you need to get the information being displayed. When the system halts on its next blue screen, you’ll have all the time you need to copy down the information.

By choosing the Disable Driver Signature Enforcement option, you’re basically telling the system that it’s okay to load drivers that aren’t digitally signed. Microsoft requires drivers to be digitally signed by default, and it will prevent unsigned drivers from running. Microsoft does this because, when a driver is digitally signed, it’s seen as being authentic because you can verify from the digital signature that it came from the vendor it claims to be from. Digital signatures also guarantee that the driver hasn’t been altered in any way since it was released by the vendor.

Digital signatures use a code-signing certificate to encrypt the hash of a file. (Hashes are unique thumbprints — any change to the file will change the hash.) That encrypted hash is then bundled with the certificate and the executable for the driver. When the end user installs the driver, the hash of the file is decrypted with the public key in the certificate. The file gets hashed again on the end user’s system, and the new hash is compared to the decrypted hash. If they match, the driver hasn’t been tampered with.