Basic computer troubleshooting
Troubleshooting means narrowing the circle before you change anything: restart once, then answer two questions, whether the problem is one program or everything, and whether it is new or has always been there. Almost every wrong repair people perform on their own computer starts by skipping those two questions.
- Lesson 12 of 12
- Beginner
- Free, no signup
The first fork of any troubleshooting
Is the problem one program, or everything?
Look inside that one program
- Try the same task with a different file
- Check the add ons and settings inside it
- Open it in a fresh user account
Look underneath all the programs
- Check free disk space, this is the most common one
- See what in the background has taken the resources
- Try safe mode and see whether the problem is there
Before this fork, restart once. And if the answer is not clear, not knowing is itself the next step: you have to test it.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
Why restarting really does work
The advice has been repeated so often that it became a joke, and it is still right. The reason is not folklore.
Programs hold state while they run: things in memory, files left open, network connections, locks on resources. When one of those gets stuck in a strange condition, everything around it starts behaving strangely too. A restart throws all that state away and everything starts from a known point.
So restarting does not hide the problem; it genuinely solves a whole class of them. What it does not do is change whatever caused that state. So the rule is simple: restart once. If the problem comes back, restarting is no longer the answer and you move to the next question.
And a few things a restart never fixes, where it is only wasted time: a full disk, a corrupted file, dying hardware, and a wrong password.
The two questions that decide the route
Before you install, remove or configure anything, answer these two. Their answers shrink the circle from my computer is broken down to one specific small thing.
One program or everything? If only the word processor is slow and everything else is fine, the problem is inside that one program: its files, its settings, an add on installed in it. If everything is slow, the problem sits underneath all the programs: the disk, the RAM, the operating system, or a program in the background that has taken all the resources.
New, or always been there? If it was fine until last week, something changed and your job is to find that thing: an update, a program you installed, a file you opened, a setting you touched. If it has been like this since day one, this is not a fault; it means this machine is not enough for this task.
A fast way to answer the first question is the one the operating system built a tool for. Microsoft own page says safe mode starts Windows in a basic state, using a limited set of files and drivers, and that if a problem does not happen in safe mode, this means default settings and basic device drivers are not causing the issue. That is exactly what is called isolating: simplify the environment and see whether the problem is still there.
On Mac and Linux the same idea takes other forms, but the logic is identical. Simpler still: create a fresh user account and do the same task in it. If it works there, the problem is in your account settings and not in the machine.
The ladder you climb before the repair shop
Take these five steps in order. The order is not arbitrary: it starts from the cheapest and most reversible action and moves towards the most expensive.
Step one is restarting, once only. Step two is to make the problem happen again. If you cannot reproduce it, you do not yet know what the problem is, and every repair from here is a guess. Step three is capturing the error message word for word, by photographing the screen or copying the text. It gave an error is not information.
Step four is isolating: safe mode, a fresh user account, a different file in the same program, or the same file on a different machine. Each of those removes one variable.
And step five is the rule that will serve you more than anything else in this lesson: change one thing at a time and write it down. If you change five settings together and the problem goes away, you do not know which one it was, and next time you start from zero. If it does not go away, you now also have five unintended changes. Keep a piece of paper next to you and write down every change you make; that paper is what later lets you put everything back.
And one boundary: if the machine is clicking, if there is a smell of burning, if it does not power on at all, or if this started right after a physical knock, this ladder is not for you. Especially if there is important data on the disk, repeatedly powering a failing drive up and down reduces what a recovery company can save. Leave it off and take it in.
Five steps, from cheapest to most expensive
-
1
Restart, once
Free and fully reversible. If the problem returns, do not repeat it.
-
2
Make it happen again
If you cannot reproduce it, every repair from here is a guess.
-
3
Capture the message exactly
A screen photo or the copied text. It gave an error is not information.
-
4
Isolate
Safe mode, a fresh account, another file, another machine. Each removes one variable.
-
5
One change at a time, and write it down
That piece of paper is what later lets you put everything back.
This ladder is for software faults. Clicking noises, a burning smell and a machine that will not power on at all do not even pass step one; they go straight to a technician.
When you must not run what the AI told you
An AI assistant is genuinely useful for troubleshooting, because it gives you a list of likely causes faster than any search. The danger comes from exactly the same place: the answer is always written with confidence, whether it is right or not, and you have no way of telling which from the tone.
The rule we use, and it has prevented damage more than once, is one sentence: do not run a command you cannot explain in one sentence. Not that you could have written it; that you can say what it does and what would be destroyed if it is wrong.
Three categories are where the rule gets strict:
- Any command with the name of a disk or a partition in it; one wrong letter in those means everything is gone
- Editing the Windows registry or deep operating system configuration files
- Anything that starts with for a quick fix, disable this, where the thing is a security feature
And a simple way to use the same tool properly: instead of how do I fix it, ask what could cause this and how do I test each one. The second answer can be checked; the first can only be executed. The fast path below turns that question into a ready made prompt.
A word about backups belongs here too: before any change you are not sure of, if there is important data on the machine, take a copy first. The backup lesson has the plan and it takes ten minutes.
How to ask so that you get an answer
Whether you ask a person or a model, a good answer is the result of a good question. And a good question needs only one thing: the details that do the thinking for you.
Five things, always. The exact error message, not summarised. When it started. What changed right before. What you have already tried. And which machine and which operating system.
Compare the two. My laptop will not start, what do I do leaves no route except guessing. Windows laptop, since last night when an update installed, on boot it shows a blue screen reading INACCESSIBLE BOOT DEVICE, safe mode gives the same, I have not tried anything, is a question that can be answered.
Here is a good habit few people have: photograph the error screen, even when you think it does not matter. Error screens usually close themselves after a few seconds, and their exact text is the only part that actually carries information.
And a warning before you send that photo: look at the whole frame, not just the message. File names, an email address, a client name, a serial number and an activation key are all in that image and they travel with it.
The sheet for a question that gets answered
Include these
- The exact error text, unsummarised and untranslated
- When it started and what changed right before
- What you have tried and what each attempt did
- The machine and the operating system, with its version
Do not send these
- A photo with a client name or an email address visible beside it
- A serial number, an activation key, or any password in the image
- Your own translation of the error instead of the original text
The same list works for asking a person and for asking a model. The difference is that a person says I do not know and a model usually does not.
The fast path, with AI
Almost everybody asks a model to fix it, and that is where it goes wrong: the model gives a confident solution, you run it, and if the cause was something else you now have a new problem too. The fast path is to change the request. Instead of a solution, ask for <strong>a list of likely causes with one cheap test for each</strong>, ordered by how easily each one is undone if it turns out wrong. The output becomes a test plan instead of a command, and you make the decision rather than the model.
- First collect the five details from the previous section: the exact error text, when it started, what changed before it, what you have tried, and the machine and operating system. Without those, any answer is a guess, whether from a person or a model.
- Send the recipe below with those details. If the error message is on screen and cannot be copied, photograph it and hand over the photo, but look at the frame first for anything private in it.
- Start at the top of the list and perform only the <em>tests</em>, not the fixes. Tests change nothing, which is why they come first. Two or three tests are usually enough to show which cause is the real one.
- Once the cause is known, then go for the fix, with the usual rule: one change at a time, written down. If the fix sits in the irreversible column, take a copy of the important data first and only then proceed.
Copy-ready recipe
I want to find the cause, not to run a solution. Do not give me a solution.
Situation:
Machine and operating system: {for example a Windows 11 laptop}
Exact error text: {verbatim, not summarised}
When it started: {for example last night}
What changed right before: {an update, an install, a setting, nothing}
What I have tried: {short list}
One program or everything: {answer, or "I do not know"}
Give me a table with these columns and at most six rows:
Likely cause | one test that changes nothing | what a positive test would mean | the fix, and whether it is reversible
Rules:
1. Order the rows from most likely to least likely.
2. A test must be only looking or trying, and must change nothing.
3. Do not write any command whose effect you cannot explain in one sentence, and put that explanation next to it.
4. Mark every fix that deletes, formats or touches the registry as "irreversible".
5. If you cannot rule a cause in or out from the information above, write "not enough information" and say what you need.
6. No preamble. Only the table.Before you trust the output: The reversible column is filled in by the model itself, and that is exactly where it can be wrong; if a row is marked reversible but you cannot say how you would undo it, that row is irreversible for you. The real cause may also not be in the table at all, because the model sees only what you wrote. And if every test comes back negative, that is an answer in itself: it means you described the problem wrongly and should go back to step two and make it happen again.
AI in this kind of work
Troubleshooting is one of the things language models are genuinely good at, because it is exactly their job: building likely hypotheses from an incomplete description. Our position is to take hypotheses from them, not commands. And use one difference deliberately: a model reads images, so a photo of the error screen usually gets you further than describing it, provided you looked at the frame first.
Tools that actually help
- Claude For building that cause and test table, and for asking it to state its assumptions separately from its conclusions. Iran is not on Anthropic supported countries list, which we read on their own page.
- Gemini The same role, and handy for handing over a photo of the error screen. Google own page says the Gemini web app runs in over 230 countries, and Iran is not on that list.
Where it backfires
Two specific risks, and both come up in troubleshooting more than anywhere else. First, a command that works but does something else. A model answers even when it does not know the cause, and in the territory of disks, partitions and the registry, one confident wrong answer can take everything. The rule is the one stated above and it is worth repeating: do not run a command you cannot explain in one sentence. Second, that photo you are about to send. A screenshot of an error message usually also carries the taskbar, the names of open files, email subject lines and sometimes an activation key, and you only looked at the middle of the frame. Google own page on Gemini says that with activity on, conversation content is used to improve Google services, human reviewers may see it, and a human reviewed copy is kept for up to three years and does not go away when you delete it; the same page says not to enter confidential information. The sourced detail is in our lesson on privacy in AI tools.
Sources: Google: how Gemini Apps activity and data are used Anthropic: supported countries Google: where the Gemini web app is available
Where this advice stops
This ladder is for software faults on a personal machine and does not work elsewhere. Hardware symptoms, a clicking drive, a burning smell, no power at all, or a fault right after a knock, are not a reasoning problem, and continuing is harmful: repeatedly powering a failing drive up and down reduces what a recovery company can save. Servers and networks take a different shape too, because logs and several simultaneous services enter the picture, and one restart can wipe exactly the evidence you needed.
From our own work
The two times we wasted the worst hours on this server, neither was a hard problem; both were places where a tool lied quietly. First, the command used to read the database directly does not connect at all on this machine, and instead of an error it prints nothing. So a search that should have found something returns empty output, and empty output looks exactly like nothing found. We took the wrong answer, made a decision on it, and only then realised no question had been asked at all. Second, the web server on this machine caches the fact that a cache file exists for up to 60 seconds. So if you delete a page from the cache and check immediately, you see the same old page and conclude the deletion did not work. Twice we redid work that had already been done correctly for exactly that reason. Since then we have a rule, and it is in this lesson too: before believing a negative answer, make sure the question was actually asked and that the answer you are looking at is fresh.
Real follow-up questions
Does restarting solve the problem or only hide it?
It genuinely solves one class of problems, because it throws away the stuck state in memory. What it does not solve is the cause. That is why restarting once is right and a third time means you are avoiding the question.
The error is in English, should I translate it?
No. Keep the original text exactly and search or send that. That English sentence is an identifier, and the people who had the same problem wrote it in exactly those words; your translation destroys the identifier. If you do not understand it, ask for the meaning separately, but send the original as well.
How do I know the problem is hardware?
When the symptom has nothing to do with software: an unusual noise, a burning smell, sudden shutdowns, no power, or a problem that is identical in safe mode and under a fresh user account. If you have important data on the disk, stop there and do not power the machine on again.