Features
Part of Repair diagnosis guide: separating hardware faults from software ones
Intermittent laptop failure: a fictional case of logs, tests, and repair
A fictional laptop shutdown case that shows how to log symptoms, control test conditions, read built-in diagnostics, scope a repair, and verify the fix over time.
What to take away
- This fictional case demonstrates method, not a diagnosis for another laptop.
- A timestamped log exposes patterns that a one-time bench test may miss.
- Changing one condition at a time prevents a false conclusion.
- Built-in diagnostics and event records narrow possibilities but need interpretation.
- A repair succeeds only when the original symptom is tested under the original conditions.
Maya owns a four-year-old laptop that shuts down without warning. It may run for hours at a desk, yet sometimes turns off during a video call. The computer restarts normally and shows no obvious error. She needs it for contract work, so lost time and data matter as much as the part price.
This is a fictional worked example. Product-specific instructions, safety conditions, warranties, and evidence differ.
Day 1: replace the guess with a record
Maya's first guess is a failing battery. She does not order one. She writes a neutral symptom statement: "The laptop loses power instantly, with no shutdown screen, during some video calls. It restarts using the power button." That sentence already follows the repair diagnosis guide: behavior, conditions, reproduction, and no cause baked in.
Symptom Log Fields
- Time of failure
- Power source
- Battery percentage
- Activity running
- Surface type
- Accessories connected
- Result observed
She starts a log:
| Time | Power | Battery | Activity | Surface | Accessories | Result |
|---|---|---|---|---|---|---|
| 9:10 a.m. | charger | 82% | hard desk | dock | normal | |
| 11:42 a.m. | charger | 100% | video call | hard desk | dock | instant off |
| 2:30 p.m. | battery | 71% | documents | hard desk | none | normal |
| 4:18 p.m. | charger | 96% | video call | lap | headset | instant off |
She records the model, firmware, operating-system version, charger rating, and dock model. She photographs the vents and checks for swelling, odor, liquid evidence, damaged cables, and unusual surface heat. There is no visible battery deformation or other condition that calls for immediate hazardous-device handling.
Day 2: protect data and preserve evidence
Maya copies her work files, photographs, local mail archive, and password-manager recovery material to controlled destinations. She opens a sample from the backup. She saves screenshots of software versions and photographs the serial number.
She avoids a factory reset because the current state may contain logs. She does not update several drivers, replace the battery, clean the operating system, and change the charger at once. That would make any improvement hard to interpret.
Day 3: control conditions
Maya creates a repeatable 30-minute call test. She first removes the dock while keeping the same charger, desk, network, and workload. The computer still turns off on the second run. She then uses the maker-approved charger with no headset. The fault appears again.
She places the laptop on a hard, open surface and records fan behavior; the fault takes longer but returns under sustained load.
She does not block vents to provoke it; the timing suggests load or temperature may matter, but it doesn't prove which component is at fault.
The laptop overheating problems guide explains why heat evidence needs caution.
Day 4: collect device evidence
The laptop's maker provides a built-in hardware test. Maya follows the exact model instructions, records the result, and photographs the reference code. A quick test passes. She understands that one passing run cannot rule out an intermittent fault.
She also checks the firmware's records, and a computer's power-on self-test runs before the operating system every start. Its error codes can appear on screen or be stored for a diagnostic tool. They can also signal as light or beep patterns when the display is out.
Maya's fictional machine holds two stored thermal entries that align with the recorded log she kept. This evidence raises a testable lead, but it is not a final parts list.
Day 5: ask for a bounded diagnosis
Maya gives a repairer the laptop, charger, symptom statement, timestamps, photographs, test code, and event record. The repair intake checklist is the fuller version of this hand-off. The intake says:
- diagnostic fee$45
- no parts without written approval
- maximum pre-approved total$45
- data erasure and storage replacementnot authorized
- target testsustained video workload on AC power
- included itemslaptop and labeled charger
The technician reproduces the shutdown, checks cooling, and finds the fan sometimes fails to start. Inspection shows debris and a worn fan bearing, but the battery passes the shop's model-appropriate test.
The written proposal covers cleaning, fan replacement, labor, tax, and part condition. It includes a 90-day warranty on the repair; a healthy quote looks like this, while the repair quote problems guide catalogs the other kind.
Compare the options
Maya records the three real choices:
Immediate cost
- Decline after diagnosis
- $45
- Approve fan repair
- $165 total
- Replace laptop
- $890 plus setup
Downtime
- Decline after diagnosis
- 1 day
- Approve fan repair
- 3 days
- Replace laptop
- 2 to 5 days
Expected result
- Decline after diagnosis
- laptop still unreliable
- Approve fan repair
- specific confirmed fault treated
- Replace laptop
- supported new system
Main uncertainty
- Decline after diagnosis
- replacement setup needed
- Approve fan repair
- other aging parts remain
- Replace laptop
- migration and accessory fit
She checks the device's remaining software support, current working value, replacement compatibility, and her recent backup. The upgrade, repair, or replace decision formalizes exactly that comparison. She approves the bounded repair because the shop reproduced the fault and tied its proposal to evidence.
Verify instead of assuming
At collection, Maya matches the serial number and checks the case, ports, screws, charger, and invoice. The technician identifies the installed fan and shows the completed test record.
Maya repeats the original video-call workload on AC power, then checks battery operation, charging, sound, camera, and network. She also checks sleep, wake, and fan behavior, then reruns the maker's hardware test and records the code.
Methodical troubleshooting treats an intermittent symptom as the hardest kind. Reproduce the original conditions, change one variable at a time, and accept that a fault failing to appear once is not yet proven gone.
She keeps the backup and continues the same timestamped log for two weeks. The shutdown does not return across twelve controlled calls. That supports the repair result more strongly than a few minutes of idle use at pickup.
What the case does not prove
It does not prove that all sudden shutdowns are thermal, that a fan should be replaced after any thermal event, or that a passing battery test settles every power fault. It shows how observation, controlled tests, device records, a written scope, and post-repair verification can turn an intermittent complaint into a defensible decision.
Common questions
Why did Maya not replace the battery first?
The observed fault did not establish battery failure, and it occurred on external power. Testing before purchasing limited waste and confusion.
Why keep testing after the repair?
An intermittent symptom can disappear temporarily. Repeating the original workload over time provides better evidence.
Could software still have caused the shutdown?
Yes at the beginning. The controlled reproduction, aligned event record, physical fan finding, and successful post-repair tests made the confirmed cooling fault the stronger explanation in this fictional case.
When should an owner stop testing?
Stop when there is a safety hazard, risk to irreplaceable data, required live electrical work, or a step outside the owner's tools and competence.
