A useful error record captures more than the words in a pop-up: it shows what happened just before the message, which device and software were involved, and whether the problem repeats. Follow this process to preserve the evidence, protect private information, and share a concise report with a technician or support team.
1. Pause and preserve the message
If the computer is still responsive, avoid dismissing the alert until you have recorded it. Do not click buttons that might delete data, reset an application, or continue a potentially destructive operation just to make the message go away. If the alert offers a clear choice, such as Retry or Cancel, note the available options before deciding. When unsure, pause and seek help rather than guessing.
Capture the whole screen
Take a screenshot that includes the complete error dialog and enough of the surrounding application to identify where it appeared. On Windows, Windows + Shift + S opens the snipping interface; select the dialog and relevant context. On macOS, Shift + Command + 4 lets you select an area. Exact behavior can vary by operating system version and settings. If a shortcut does not work, use the built-in screenshot app or the computer manufacturer’s instructions.
A screenshot is often better than a cropped image of the message alone. It can show the program name, a button, a file name, or a warning that changes what the error means. Keep the original image; make a separate copy if you need to crop or mark it for sharing.
If the screen is frozen or the computer will not respond, do not keep trying shortcuts indefinitely. Write down what you can see, including the exact wording and any code, and note that you could not capture a screenshot. If the message disappears before you can record it, describe it immediately from memory and say that the wording is approximate.
Copy text when possible
Some dialogs let you select the text with the mouse, or copy it using Ctrl + C on Windows or Command + C on macOS. Paste it into a plain-text note and preserve line breaks, punctuation, and capitalization. Some applications display a Copy details or More information control. Use it only if it is safe and you understand what information it will copy.
Do not assume that a code copied from a pop-up tells the whole story. Record the surrounding sentence too. Codes can be shared by different problems, and a code without the application name or the action that triggered it may be hard to interpret.
2. Record the exact circumstances
As soon as practical, note what you were doing at the moment the message appeared. A brief sequence is more useful than a broad statement such as “the computer broke.” Include the action that came immediately before the error and what you expected to happen.
Record these details:
- Date and approximate time: Include your time zone if support is in another region. Avoid changing the computer clock to make the record look more precise.
- Application and task: Name the program, the screen or feature, and the action you tried, such as opening a document or connecting a headset.
- Exact message: Preserve the complete wording, error number, file path, and punctuation where visible. Mark anything you are unsure about as approximate.
- What happened next: Say whether the task stopped, the app closed, the device restarted, or the message cleared.
- Repeat pattern: Note whether it happened once, every time, or only after a particular step.
- Recent changes: Mention relevant updates, new accessories, changed settings, or a moved file if you know they are related. Do not list unrelated personal or work details.
A simple timeline helps separate observations from guesses:
| Time or step | What you did | What you observed |
|---|---|---|
| 9:10 a.m. | Connected the USB headset | Device appeared in sound settings |
| 9:12 a.m. | Started a video call | App displayed “Audio device unavailable” |
| 9:13 a.m. | Disconnected the headset | Message remained on screen |
Use your own details; the example is only a format. If you do not know the exact time, write “around 9 a.m.” rather than inventing precision.
3. Add the computer and accessory context
The same message can have different causes on different systems. Note the computer’s make and model if readily available, the operating system and version if known, and the application name and version if the app displays it. Do not delay recording the error to search through settings for every version number. “Windows laptop, version unknown” is better than a guessed version.
For an error involving a monitor, printer, storage device, dock, keyboard, headset, or other accessory, record its make and model, how it is connected, and whether it worked previously. Include practical connection details such as USB port type, cable, wireless or wired connection, and whether a dock or adapter is in use. Avoid unplugging internal components or opening a device to gather this information.
Accessory compatibility matters. A device may require a particular operating system, port, driver, power source, or connection method. Record the exact setup rather than assuming that a connector fitting the port means the device is supported. If you need to consult equipment instructions, use the manufacturer’s documentation for the specific model; instructions for a similar-looking accessory may differ.
For workstation issues, describe the arrangement only as it relates to the error: for example, “external monitor connected through a USB-C dock,” or “printer shared over the office network.” This can help distinguish a computer problem from one involving an adapter, cable, hub, network, or accessory. Keep the account focused on the technical setup, not unrelated workplace or personal information.
4. Protect private information in screenshots and logs
Error messages and diagnostic files can expose names, email addresses, account identifiers, file paths, document titles, network names, or snippets of work. Before sharing a screenshot, inspect the entire image—not only the dialog—for browser tabs, notifications, open documents, and account details.
If sensitive information is visible, keep the original in a secure location and make a separate copy for sharing. Crop or cover only the private area, while retaining the complete error text and enough context to understand it. Use an opaque block rather than a translucent highlighter. Do not alter the original evidence, and tell the recipient if you redacted part of the shared copy.
Logs and diagnostic reports may contain more information than a screenshot. Send them only through a support channel you trust, and follow the organization’s or manufacturer’s instructions about what to include. Avoid posting raw logs, serial numbers, license keys, passwords, recovery codes, or private work files in a public forum. A support agent should not need your password to interpret an error; do not put it in the report.
5. Try safe checks and record each result
Documentation supports troubleshooting, but it is not a reason to make several changes at once. First preserve the message. Then, if the computer is responsive and the task is not at risk of losing unsaved data, make one low-risk check at a time. After each action, note exactly what changed and whether the error returned.
Possible checks, depending on the problem, include:
- Confirm the accessory is connected as its instructions specify and that its cable is firmly seated.
- Check whether the same task works without the accessory, if disconnecting it is safe and will not interrupt an important operation.
- Close and reopen the affected application after saving work, if possible.
- Check the application’s own status or settings for the device involved.
- Restart only when it is safe to do so and you have saved open work. If the machine is showing signs of a failing drive or repeated data errors, stop and seek qualified help before repeated restarts or repair attempts.
Do not install a driver from an unfamiliar download site, disable security tools, edit system settings, or run repair commands just because a message suggests it. If the error refers to encryption, disk health, data recovery, or a managed work computer, stop before taking actions that might make data inaccessible or conflict with support policy. Follow the manufacturer’s guidance or contact the appropriate support team.
For each check, use a short note such as: “Disconnected USB headset; the error did not appear when opening the app without it.” Avoid writing “fixed” unless the original task now succeeds consistently enough for your needs. If a change does not help, record that too; it prevents repeating the same step without a reason.
6. Organize the evidence and share a useful report
Save the screenshot, copied text, and notes together in a clearly named folder or support case.
A practical filename can include the date and a short subject, such as 2026-11-11-audio-device-error.png.
Keep a private original and a redacted sharing copy if needed.
If your support system has an upload limit, send the clearest relevant image rather than several near-identical captures.
A concise report can follow this template:
Device: [computer make/model, if known; operating system/version if known]
Application or accessory: [name and model]
When: [date and approximate time]
What I was doing: [steps immediately before the message]
Exact error: “[message and code]”
Frequency and impact: [once/repeats; task stopped or continued]
Checks tried: [one action per line, with the result]
Attachments: [screenshot or copied details; note any redactions]
Use an approved work help desk or the manufacturer’s official support route if the computer is managed or the issue may involve a warranty. For a public technical forum, remove account details and private paths, and include enough system and accessory context for others to understand the setup. Do not post a screenshot that reveals confidential material simply to get a faster answer.
7. When the message is vague, missing, or keeps returning
Some alerts say only “Something went wrong” or vanish before you can read them. In that case, record the application, the action that led to the message, the time, and what changed afterward. If the program has a built-in history, notification center, or error-details view, use the application’s help instructions to locate it. Availability differs by program and operating system; do not assume a generic log will contain the event.
If the problem repeats, compare incidents. Does it happen with one document, one accessory, one account, or only after a particular sequence? Record the differences as observations rather than declaring a cause. For example, “occurred twice while docked; not yet tried without dock” is more useful than “the dock is broken.” Stop repeated attempts if they risk overwriting data, damaging equipment, or locking you out.
If you cannot reproduce the error, keep the record and note that it has not returned. A single incident may be enough to ask for advice if it prevented important work or displayed a data-loss warning. If it returns, add the new date and circumstances to the same report instead of replacing the original entry. Keep only the technical evidence you need, store it securely, and share it through an appropriate support channel.