Stop errors, services and startup faults, and reading what they tell you

Why this matters

These three faults are grouped because they share a cause profile: something loads early, something goes wrong, and the machine either stops or arrives at a desktop with a piece missing. In every case the machine has recorded what happened, and the skill is extracting the one useful line from a great deal of output.

The exam asks about these as scenarios with a change attached — an update, a driver, a new piece of software — because that is how they actually occur. Almost nothing in this lesson fails spontaneously, and "what changed?" is therefore the question that solves most of it.

The lesson

A stop error as a driver report, and getting the useful part out of it

A stop error is not a crash report about Windows. It is Windows stopping deliberately because something — nearly always a driver — did something that cannot be allowed to continue.

What to extract from the screen:

• The stop code, the descriptive name such as DRIVER_IRQL_NOT_LESS_OR_EQUAL or PAGE_FAULT_IN_NONPAGED_AREA.
• The failing module, if one is named. This is the single most useful item: a .sys file name identifies the driver, and the driver identifies the hardware or the software that installed it.

Codes worth recognising by what they imply rather than by number: those naming a driver point at a driver; INACCESSIBLE_BOOT_DEVICE points at storage drivers or firmware mode; memory-management codes point at faulty memory or a driver abusing it; and CRITICAL_PROCESS_DIED points at system file damage.

Where to read it afterwards: the memory dump in C:\Windows\Minidump, read with a dump analyser, and the System log around the time of the restart. A machine that restarted before anyone read the screen still has both.

The order to work in:

1. What changed? An update, a driver, new hardware, new software.
2. If a module is named, identify and roll back or update that driver.
3. If it is random and varied, suspect memory or storage and test them.
4. If it is at boot and mentions the boot device, check firmware mode and the storage driver.

The general shape: a consistent stop code with a named module is a driver problem and is fixable; varied codes with no pattern point at hardware.

Event Viewer: finding the first error rather than the loudest one

Event Viewer is where a machine that restarted tells you why, and the skill is narrowing rather than reading.

The approach:

• Open the System log, filter to Critical, Error and Warning, and set the time range to a few minutes either side of the fault.
• Look for Event ID 41, which means the machine stopped without shutting down cleanly — the marker of a stop error or a power loss.
• Then look backwards from it. The entry immediately before an unexpected restart is frequently the cause, and the forty entries after it are consequences.

Finding the first error rather than the loudest one is the discipline. A service that failed to start produces an error, then every service depending on it produces one, then every application needing any of them produces several. Sorting by severity puts the noisiest at the top; sorting by time puts the cause at the top.

Two things worth knowing:

• Custom views. Save one filtered to Critical and Error across the System and Application logs for the last 24 hours, and it becomes a thirty-second check on any machine.
• Errors are normal. Every healthy machine logs them continuously. An event is evidence only when it correlates in time with the symptom — which is why asking the user what time it happened is worth more than any other question.

Services that fail to start, dependencies, and the account a service runs as

A service that will not start has a small number of causes, and the service's own properties name most of them.

The tabs that answer it:

• General — the startup type and the current state. A service set to Disabled is not failing; it was turned off.
• Log On — the account it runs as. A service using a specific account fails when that password changes or the account is locked, and the error is often a generic "failed to start" with the real reason in the System log.
• Recovery — what happens on failure. This is what restarts a service you just stopped.
• Dependencies — what must be running first, and what depends on this. A service that cannot start because its dependency cannot start is the cascade the previous section described.

The usual causes, in order:

1. A dependency is stopped or disabled.
2. The account's credentials are wrong or the account is disabled.
3. The executable is missing, or its permissions were changed.
4. A port the service needs is already in use.
5. The service is disabled by policy.

Where to look for the real message: the System log entry for the service, which usually carries a specific error rather than the generic one the interface shows. And for a service that fails only at boot, the cause is frequently ordering — it starts before something it needs, and setting it to Automatic (Delayed Start) resolves it.

Startup programs, scheduled tasks, and the clean boot that isolates them

Three places make things run without anyone choosing to run them, and a fault that appears "after logon" lives in one of them.

• Startup apps — Task Manager's tab, plus the startup folders and the registry run keys. Disabling here stops something launching at logon.
• Scheduled tasks — Task Scheduler. Far less visible, far more capable, and the place where something persistent hides. Tasks can trigger at logon, at boot, on idle, or on an event.
• Services — as above, running with no one logged in.

The clean boot is the tool that isolates which:

1. Open System Configuration, hide all Microsoft services, disable the rest.
2. Disable all startup items in Task Manager.
3. Restart and confirm the fault is gone. If it is not, the cause is not here.
4. Re-enable half, restart, and see which half carries it.
5. Repeat until one item is identified.

Half a dozen restarts identifies one item exactly. It is slow and it is certain, which is the right trade for a fault nobody can otherwise explain.

Remember to put the machine back to a normal startup afterwards, and to re-enable everything that was not the cause. A machine left in clean-boot configuration is a machine with its synchronisation client, its backup agent and its security software silently disabled — a "fix" that creates three problems nobody will connect to this visit.

Driver rollback, signature enforcement, and the update that broke the machine

Drivers are the most common cause in this lesson, and Windows provides tools specifically for undoing them.

Roll back — Device Manager, the device's properties, the Driver tab. It reinstates the previously installed driver and is the correct first move when a fault began after a driver update. It is greyed out when there is no previous version stored, which is common on a freshly installed machine.

The update that comes back. A rolled-back driver will be reinstalled by Windows Update on its next scan unless it is blocked. Microsoft publishes a tool for hiding a specific update, and on Pro editions policy can stop driver delivery through Windows Update entirely. A fault that "returns after a few days" is almost always this.

Driver signature enforcement requires kernel drivers to be signed. It can be disabled temporarily from the recovery startup options, and the honest framing is that this is a diagnostic step, not a solution: an unsigned kernel driver is a serious thing to run permanently, and needing one usually means the hardware is unsupported on this version of Windows.

When a driver stops the machine booting, the route is: recovery environment, safe mode, roll back or disable the device there. If even safe mode fails, the recovery command prompt can disable a driver by editing its start value, and a restore point is usually faster.

The general principle for this whole lesson: find what changed, undo exactly that, and confirm it does not come back on its own. The third clause is the one that separates a fix from a delay.