Week 02 · lesson
Lesson 5: Diagnose the No-POST and Board-Level System
Core path: 42 minutes
A system that powers on but never reaches POST is not the same as a system with no power.
That distinction matters because the evidence points you toward a different troubleshooting path.
Start with the symptom
Scenario:
- power button responds;
- fans spin;
- display stays blank;
- no normal POST completion;
- system was recently upgraded with new RAM and CPU.
Do not call the motherboard dead yet.
Use the troubleshooting method
1. Identify the problem
Record exactly what happens and what changed recently.
2. Establish a theory
Reasonable first theories include:
- RAM not seated correctly;
- incompatible RAM or ECC/non-ECC mismatch;
- unsupported CPU;
- CPU power connection missing;
- display connected to the wrong output for the installed configuration;
- firmware support issue;
- board-level fault indicated by POST code/beeps/LEDs.
3. Test one theory at a time
A useful order might be:
- inspect power connections;
- record POST beeps/diagnostic LEDs or codes;
- verify RAM seating and configuration;
- test one known-good memory module;
- verify CPU/socket/platform support;
- inspect firmware settings/support;
- reduce to a minimal known-good configuration when appropriate.
The exact sequence depends on the evidence available.
Named board-level clues
A+ expects technicians to recognize several symptoms that can point toward motherboard/RAM/CPU/power investigation.
POST beeps or diagnostic indicators
Record the pattern/code and use the system or motherboard documentation. Do not assume every vendor uses the same code meanings.
Inaccurate system date/time
If date/time repeatedly resets after power loss, CMOS/RTC battery or firmware-state problems become plausible. It is not proof of a bad CPU.
Capacitor swelling or burning smell
Stop normal operation and follow safety/escalation procedure. Visible swelling or a burning smell is hardware evidence that should not be ignored or "tested" by repeatedly powering the machine.
Sluggish performance or application crashes
These can be RAM/CPU/platform symptoms, but they are broad. Use memory diagnostics, temperature/resource evidence, and recent-change history rather than guessing.
Why recent change matters
If the machine worked before a component change and fails immediately after it, the changed boundary deserves attention first.
That is not proof that the new component is defective.
It may be:
- incompatible;
- installed incorrectly;
- unsupported by current firmware;
- exposing another power or cooling requirement.
Build the service ticket
Your Week 2 evidence must include:
Reported symptom:
Recent change:
POST/diagnostic evidence:
Known-good behavior:
Initial theory:
Test performed:
Result:
Next action:
Final diagnosis:
Verification:
Final challenge
You receive three candidate fixes:
- replace the motherboard immediately;
- verify compatibility and reduce the system to a minimal known-good configuration;
- reinstall the operating system.
Defend the best first move using the evidence in the scenario.
Then diagnose one additional case: the machine boots but loses date/time settings after being unplugged. Explain why this changes the troubleshooting boundary.
Week 2 completion criteria
You should now be able to:
- read a motherboard as a compatibility and firmware map;
- match CPU architecture/socket/platform requirements;
- distinguish DIMM/SODIMM, DDR generations, and ECC/non-ECC;
- reason about channel configuration;
- identify key BIOS/UEFI security and hardware settings;
- include cooling and power in processor compatibility;
- interpret POST/board-level symptom evidence;
- troubleshoot a no-POST condition without random part swapping.
The goal is not to memorize model numbers. The goal is to know what must match and how to prove it.
Read it. Prove it.