How to Export AS SSD Results: Screenshot and XML Guide

A benchmark result you cannot find, prove, or explain later is only half useful. AS SSD Benchmark gives you two ways to keep a result from the File menu: a screenshot of the result window and an export to an XML file. This guide explains when to use each format, exactly what to save, what context to record alongside the numbers, and what to check before you share a result in a forum, with a seller, or with anyone helping you troubleshoot a slow drive.

The steps below assume a finished run in version 2.0.7316.34247. If you have not completed a run yet, follow running your first benchmark and come back when the main window shows all four rows and a total score. Get the tool itself from the download page if you need it.

Screenshot: the format most people should save

Open the File menu and choose Screenshot. The tool saves an image of its window showing the drive information at the top, the four result rows, and the scores. That single image is powerful because it contains the evidence helpers actually need: drive model and firmware, controller and alignment status, capacity, test results in their chosen unit, and the total score, all captured at the same moment under the same conditions.

Save the screenshot immediately after a run, before you change settings or run another test that overwrites the window. Give it a filename that identifies the drive and date rather than accepting a generic name you will not recognise in six months. Store screenshots for one drive together in a dated folder, so a timeline naturally builds up: first baseline, after a Windows reinstall, after moving the drive to a new machine, and so on.

Do not crop the image down to just the total score before sharing it. Cropping removes the top information lines that often contain the actual diagnosis, such as the wrong drive being tested, an alignment warning, or a controller running in a slower mode. A full-window screenshot lets someone help you. A cropped score mostly invites guesses.

Export to XML: the structured record

Also in the File menu, the Export option saves the result as an XML file. XML stores the values as structured text that software can read, which makes it useful for keeping precise records, building a personal log across many runs, or supplying exact numbers rather than reading them off an image. The values are the same results shown in the window; the export does not re-run anything or add new measurements.

A good habit is to save both formats for any run you care about: the screenshot for human eyes and quick sharing, and the XML with the same filename stem for the record. They take seconds to create together and cover both audiences. For a run you are only glancing at before re-testing on a quieter system, neither is necessary; export the run you are actually going to stand behind.

Naming that future-you will thank you for: drive model + date + test size, kept identical for the screenshot and the XML. Example pattern in words: model, year-month-day, 1 GB. When the files sort by name, your history sorts itself.

The context checklist: numbers alone are not enough

Two results with identical scores can mean different things, and two different scores can both be healthy, depending on context the window does not fully record. Before you share or file a result, note these items alongside it, in the filename, a small text note in the same folder, or your forum post itself:

  • Test size: 1 GB by default, or 3, 5, or 10 GB if you changed it. Results at different sizes are not directly comparable.
  • Display unit: whether the window was showing MB/s or IOPS from the View menu. State it when you quote numbers in text.
  • Free space: roughly how full the drive was. A nearly full drive benchmarks differently from an empty one.
  • What changed: new drive, new computer, driver or firmware change, Windows reinstall, or nothing at all since the last run.
  • Conditions: anything unusual, such as a warm laptop, background updates running, or the drive connected through a USB enclosure rather than internally.

This checklist is also what separates a helpful forum post from a frustrating one. Helpers who can see the screenshot and read the context can often spot the issue immediately, for example alignment or controller mode visible at the top of the window. Without context they can only repeat generic advice, and you will be asked for exactly this information anyway.

Sharing results safely and honestly

Before sharing publicly, glance over the screenshot once. It shows drive model, firmware, and capacity, which most people are comfortable posting, and it does not contain your personal files or Windows username. Still, avoid adding unrelated screenshots of your desktop or file explorer that might show private folder names. Share the benchmark window, not your whole screen, when privacy matters.

Share honestly: post the run you actually got on a representative system, not the best of ten runs with everything else stripped away, and say if the drive was empty and freshly installed. An empty-drive result presented as a daily-driver result misleads everyone, including you later. If your score looks low, resist editing or re-running until it looks respectable; a low, well-documented result is exactly what gets a problem diagnosed. For the next steps when a total disappoints, our troubleshooting coverage starting with why an AS SSD score is too low works through the common causes in order.

Building a useful results history

Keep baselines for every drive you own, export after major changes, and resist deleting poor results; the poor ones are the diagnostic gold. Over time your folder becomes a personal reference that no review site can give you, because it tracks your drives, in your computer, under your workloads. When you replace a drive, the old exports let you verify that the new one is genuinely performing as it should in the same system.

In short: screenshot for sharing, XML for the record, both with the same clear name, and always with test size, unit, free space, and what changed written alongside. That small discipline is the difference between a pile of mystery images and a benchmark history that can actually answer questions. It connects directly to the main workflow in how to use AS SSD Benchmark, where saving the result is the final step of every proper run.

Similar Posts