A practical Tartanleaf reference
Controlled, Reversible Troubleshooting
Fix technology without erasing the evidence or making the original problem harder to understand.
The short answer
Controlled, reversible troubleshooting means observing before changing, defining what success would look like, testing one explanation at a time and keeping a practical way back.
Begin with the least disruptive useful test. Record what you changed and what happened. Escalate to resets, removals or reinstallation only when the evidence justifies the risk and you have protected the information and settings you may need to recover.
This is not a promise that every problem has a simple fix. It is a way to learn from each step while reducing avoidable damage.
Why “try everything” often fails
When a computer, network or account stops working, it is tempting to restart several devices, change settings, update software, remove an application and reset the connection in quick succession. If the problem disappears, you do not know which action mattered. If it remains, you may have added several new variables—and perhaps removed the evidence that pointed to the cause.
A useful troubleshooting process should answer three questions after every step:
- What did we think might be happening?
- What single observation or change tested that explanation?
- What did the result teach us?
The seven-step process
Define the actual problem
Describe what is failing in observable terms. “The internet is broken” is too broad. “This laptop cannot open websites on Wi-Fi, while the phone works on the same network” separates the device, service and connection well enough to begin.
Record what you were trying to do, the exact symptom, when it began, whether it is intermittent, who or what is affected, and what still works.
Preserve the evidence
Before clearing logs, resetting settings or restarting everything, capture the complete error, date and time, recent changes, indicator lights, relevant versions or models, and the current settings you may need to restore.
Do not collect or share passwords, recovery codes, private keys or other secrets. Review diagnostic reports before sending them to someone else.
State one explanation
Turn a guess into a testable statement: “If the router is the problem, other devices on this network should also fail,” or “If the new setting caused the problem, restoring the previous setting should restore the old behaviour.”
An explanation does not have to be correct to be useful. It must be specific enough that a result can support or weaken it.
Choose the smallest useful test
Prefer observation and comparison before configuration changes. Compare one affected device with one working device, Wi-Fi with Ethernet, one browser with another, the same account on another device, or the current condition with a known-good baseline.
The smallest test is not always the easiest click. It is the lowest-risk action that can meaningfully distinguish between explanations.
Make one controlled, reversible change
Change one variable, write down the original value, know how to restore it, protect important files and settings first, and set a stopping point before the change becomes destructive.
Resetting a network, factory-resetting a device, deleting an account profile and reinstalling an operating system are not early diagnostic tests. Microsoft’s current Windows guidance places network reset after less disruptive Wi-Fi checks and warns that it removes network adapters and their settings.
Verify the result
Do not stop at “it seems better.” Repeat the action that originally failed, try it more than once, check for side effects and confirm that a restart preserves the result when appropriate. If the test did not help, restore the original state when practical before trying the next explanation.
Record the outcome and preserve recovery
Keep a short record of the symptom, useful observations, the change that mattered, anything deliberately left unchanged, the recovery route and what to watch for if the problem returns.
Good troubleshooting ends with a more understandable system, not merely a quiet symptom.
Worked example: one laptop cannot reach websites
Initial report
“The internet is down.”
Better description
One Windows laptop shows that it is connected to home Wi-Fi but cannot open websites. A phone on the same Wi-Fi works. The problem began after the laptop woke from sleep.
Evidence preserved
The browser error, network name, date and time are recorded. The phone works and the laptop can still reach the router’s local address.
First explanation
The internet connection and router are probably operating because another device works. The fault may be limited to the laptop, its name resolution or its current network session.
Small tests
Try two unrelated sites, compare another browser, check the router’s local page, then disconnect and reconnect only the laptop’s Wi-Fi.
Controlled change
Save open work and restart only the laptop. Do not reboot or reset the router because the evidence does not indicate a network-wide failure.
Verification
Repeat the originally failing tasks, wait several minutes and confirm that the phone still works. If the laptop remains broken, record that result before continuing.
What not to do first
Do not factory-reset the router, erase every saved Wi-Fi network, reinstall Windows, or change DNS, firewall and adapter settings together.
When to stop and get help
Stop before proceeding when:
- important data is not backed up;
- the next step could erase data, accounts or configuration;
- the device controls medical, safety, access-control or business-critical functions;
- there are signs of electrical damage, overheating, swelling or liquid exposure;
- you suspect malware, account takeover or financial fraud;
- recovery credentials or encryption keys may be missing;
- warranty or service terms could be affected; or
- the evidence no longer supports a safe next test.
Giving a technician a concise problem record is more useful than saying that “everything was tried.”
Troubleshooting record worksheet
Copy or print this section before beginning. Keep secrets out of the record.
Problem
Evidence
Test
Result and resolution
How this relates to the Tartanleaf method
This reference is a worked application of the Tartanleaf Practical-Technology Method. The broader method applies the same habits—clear purpose, direct observation, controlled change, verification and recovery—to choosing, configuring and maintaining everyday technology.
Sources and scope
This page documents Greg Weir’s practical troubleshooting framework for everyday technology. It is not a replacement for product-specific instructions, qualified technical support or incident-response assistance.
The sequence is consistent with official guidance that places less disruptive recovery options before destructive ones, protects important files before recovery work and tests backups and restored systems:
- Microsoft Support: Fix Wi-Fi connection issues in Windows — places network reset after less disruptive checks and documents its configuration effects.
- Microsoft Support: Recovery options in Windows — starts with less disruptive options and advises backing up important files first.
- NIST: Contingency planning — provides the wider recovery-planning context for restoring systems, operations and data.
- NIST SP 800-34 Rev. 1 — emphasizes documented procedures, checklists, testing and validation of recovery capability.
- CISA: #StopRansomware Guide — recommends protected backups and regular tests of their availability and integrity.