Section 3: What Would Happen If These Files Were Missing/Corrupted

The Big Picture: Every Link in the Chain Matters

In Section 2 you met the files in the start-up chain. This section answers a practical question: what do you see when one of them goes wrong?

Corrupted means the file is there but its contents are damaged (for example, after a power cut during an update, a failing disk, or a bad driver). Missing means the file is gone (deleted, or the disk sector holding it is unreadable).

A useful rule: the earlier in the chain a file is used, the worse the symptom.

Early in the chain (fails before Windows is alive)     → PC will not boot, error screen
Middle (kernel runs, but a core process fails)         → blue screen or forced restart
Late (everything else is fine)                         → a program or the desktop fails

Warning: The tables below are for understanding. Do not delete or rename system files to "see what happens". Many of these experiments can leave a PC that will not start.

3.1 Per-File Failure Symptoms

The exact words on the screen vary by Windows version, PC maker and the exact kind of damage. Treat the wording and error codes below as typical examples, not promises.

Stage 1: Files used before Windows starts

Stage 2: Files used while the system starts

Stage 3: Files used when programs and the desktop run

3.2 Why Windows Protects These Files (WFP/WRP)

The problem: Old Windows let any installer replace system files. A badly written program would overwrite a good kernel32.dll with an older one, and it would break other programs. This caused the infamous "DLL Hell": programs breaking each other by swapping shared files.

The solution: Windows protects its own files with layers:

1. Windows File Protection (WFP) — the old way. Windows 2000 to XP watched critical files and quietly put back the original if something replaced them. It worked but was weak and easy to bypass.

2. Windows Resource Protection (WRP) — the modern way. Since Windows Vista, WRP protects critical files, folders and registry keys. Instead of fixing them after the fact, it prevents them from being changed in the first place, by using permissions (see below). The protected files have a known good copy in the component store (WinSxS, Section 1.4).

3. TrustedInstaller. Protected files are owned by a special account called TrustedInstaller (the Windows Modules Installer service). Only that account can change or delete them, and only Windows Update and servicing code run as it. Even a normal Administrator gets "Access denied" or "You need permission from TrustedInstaller".

File: C:\Windows\System32\kernel32.dll
 Owner:  NT SERVICE\TrustedInstaller
 Rights: TrustedInstaller  = Full control
         Administrators    = Read & execute only
         Users             = Read & execute only

You can read these permissions safely with the icacls command or PowerShell's Get-Acl (see the lab). That does not change anything.

Why even Administrators are blocked: A user with admin rights can still run harmful software by accident. Keeping the system files under a separate account means that mistake cannot easily break Windows. It is a safety belt for the whole system.

Taking ownership: do not. There are ways to take ownership of a system file and give yourself permission (using takeown and icacls with change options). Do not do this to system files. It removes the protection, and a single wrong deletion can stop the PC from booting. If a file looks wrong, repair it with the tools in 3.3, which put the genuine file back.

Other protections that work together:

3.3 The Repair Tools

When something is damaged, use the repair tools in this order, from least to most drastic:

The typical repair plan:

Windows starts but is odd or slow
   → sfc /scannow
        → still broken?  DISM /Online /Cleanup-Image /RestoreHealth, then sfc again
             → still broken?  System Restore
                  → still broken?  Reset this PC (keep my files)

Windows does not start
   → Startup Repair (WinRE)
        → bootrec / bcdboot (WinRE Command Prompt)
             → System Restore (from WinRE)
                  → Reset this PC, or reinstall

Read-only versions you can use safely:

sfc /verifyonly                         (admin; scans, repairs nothing)
DISM /Online /Cleanup-Image /CheckHealth   (admin; quick: reports if damage was flagged)

sfc /verifyonly only scans and reports. DISM ... /CheckHealth only checks whether the component store was already marked as damaged; it does not scan deeply (that is /ScanHealth) and does not fix anything (that is /RestoreHealth).

Where the results go: sfc writes its details to C:\Windows\Logs\CBS\CBS.log; DISM writes to C:\Windows\Logs\DISM\dism.log.

Always keep backups. Repair tools fix Windows; they cannot bring back your documents. Back up your personal files (Chapter 19 explains the file systems and recovery limits).

3.4 Putting It All Together: A Quick Story

You turn on your PC and see "Your PC needs to be repaired. File: \Windows\system32\winload.efi". What does that tell you?

1. The firmware worked (you got past POST).
2. The boot manager worked (it is showing you a message).
3. The loader (winload.efi) is the link that failed.
4. So the problem is early in the chain, and Startup Repair or bootrec from WinRE is where to start. A fresh sfc from inside Windows is not possible, because Windows is not running.

Compare: if instead you get a black screen with a mouse pointer, the chain got all the way to winlogon.exe, and the shell (explorer.exe) is the problem. Press Ctrl + Shift + Esc and run a new task.

Reading symptoms backwards through the chain is the skill that experienced technicians use.

Summary