Reading an Error Message Properly

Most people react to an error message by clicking OK and hoping. The message usually contains enough to identify the problem, and knowing which part matters turns a mystery into a search that works.

The parts of a message

What failed. Which application or component.

What it was trying to do. Frequently the most useful part and frequently ignored.

Why it failed, in whatever terms the developer chose.

A code. A number or identifier. This is the part worth searching, because it is unambiguous.

A suggestion, which ranges from helpful to meaningless.

What to do first

Read it. All of it. Including the part below the fold, and any "details" or "more information" that expands.

Write it down or photograph it, exactly. Reconstructed from memory it becomes unsearchable — "something about a file" finds nothing.

Note what you were doing when it appeared. The action matters as much as the message.

Note whether it repeats. Once may be transient; every time is reproducible, and reproducible problems are far easier to solve.

Searching it effectively

Search the exact error code, in quotation marks, with the application name.

Remove anything specific to you — your username, your file path, your machine name. These make the search unique and useless. Replace them with nothing.

Bad: Error 0x80070005 accessing C:\Users\Sarah\Documents\budget.xlsx Good: "0x80070005" access denied

Include the application and version where relevant.

Add the operating system if the results are for a different one.

Prefer results from the vendor, from established technical communities, and from recent discussions. Old threads describe old versions.

Be wary of results offering a download to fix it. A large industry exists around search results for error codes, and most of it sells software you do not need.

Common message types and what they mean

"Access denied" or "permission denied" — the account you are using is not allowed to do this. Not a corruption, not a fault. Frequently fixed by running as administrator, or by taking ownership of a file from another machine. See reusing a drive.

"File in use" or "cannot delete" — something has it open, sometimes invisibly. Close applications, or restart, which releases everything.

"Not enough space" — literal, and worth checking rather than assuming, because temporary files can consume a surprising amount during an operation.

"Missing DLL" or "missing library" — a required component is absent, usually because an installation is incomplete or something was removed. Reinstalling the application is the reliable fix; downloading the individual file from a website is a common route to malware.

"Unresponsive" or "not responding" — the application is busy, not necessarily crashed. Wait before forcing it, particularly during a save or a large operation.

A blue or black screen with a stop code — the system halted to prevent damage. The stop code is the searchable part, and the cause is usually a driver, memory or storage. Note whether it happens during a specific activity.

"Cannot connect" or "network error" — see wireless connection problems.

Where to find more detail

The event log. Windows Event Viewer and macOS Console record far more than the message you saw, including what happened immediately before.

Look at the timestamp of your error and read what preceded it. The visible message is frequently a consequence rather than a cause.

Be aware that logs contain many warnings that mean nothing. Every system generates them constantly, and a page of yellow warnings is normal rather than diagnostic. Look for errors at the time of your problem, not for warnings in general.

This matters because "I looked at the event log and there are hundreds of errors" leads people to conclude their machine is failing when it is behaving normally.

Messages that are lying to you

Pop-ups claiming infection, particularly in a browser with a telephone number. These are the attack, not a warning about one. No legitimate security product asks you to ring anyone. See scams that target home users.

"Your computer is running slow, click here to fix" — advertising, not diagnosis.

Fake update prompts in a browser. Updates come from the application or the system, not from a web page.

The test: did it appear in a browser window, or as a system dialogue? Browser content can look like anything.

Describing it to someone else

Whether asking a friend, a forum or a technician, the same information helps.

The exact message, including the code.

What you were doing.

When it started, and what changed around then — an update, an installation, new hardware.

Whether it is reproducible, and the steps.

What you have already tried, so nobody repeats it.

"It says error and won't work" gives nobody anything. Two extra sentences frequently produce an immediate answer.

When there is no message

A machine that fails silently is harder. Check the event log at the time it happened — the system usually recorded something even when it showed you nothing.

Note the pattern. Always at the same point, always with the same application, always after a period of running.

Patterns substitute for messages, and they are frequently more informative.

The short version

Read the whole message, including the details section, and photograph it.

Search the error code in quotation marks, with the specifics removed — your username and file path make it unsearchable.

"Access denied" is a permissions problem, not a fault.

A pop-up with a telephone number is the attack, not a warning.

And check the event log at the time it happened — but ignore the general run of warnings, which every healthy system produces constantly.

For broader technical standards and computing references, see NIST Information Technology Laboratory.