Why does the same microSD card test differently on another computer?

The same microSD card can fail on one computer and pass on another. That does not automatically prove that the first result was false, that the second computer repaired the card, or that the card is acceptable. It shows that the card-reader-host test chain changed.

A defensible decision separates the sample from the reader, adapter, cable, port, operating system, cache policy, power state, test program and environment. The first failure remains evidence. The recheck must follow a written order and change one variable at a time.

Start by defining the question

Different tests answer different questions:

• a controlled write/readback comparison checks whether expected data returns from the tested address range;
• a read-only scan checks whether the host can read the accessed logical range on that path;
• a sustained-speed test measures time-dependent performance under a stated workload;
• a target-device run checks compatibility with the real camera, recorder or industrial host.

Compressing those questions into one green or red button produces results that cannot be audited. Before running software, write down what the result must support and what it cannot support.

Why another computer can change the result

Desktop software observes the complete host path. The following variables can alter timeouts, throughput, disconnects or returned data:

• reader controller and supported SD bus mode;
• microSD-to-SD adapter contact condition;
• USB cable, hub topology and physical port;
• host-controller driver and operating-system build;
• sleep, power-saving and removable-media cache policy;
• antivirus, indexing, backup or other background I/O;
• card, reader and ambient temperature;
• software version, test mode, block size and data coverage.

Therefore, “failed on workstation A, passed on workstation B” means only that the failure was not reproduced under B's conditions. It does not erase the first log.

Freeze the test record before comparing cards

Each sample record should include:

A blue USB connector is not proof of link capability. Port colour is only an appearance convention; an internal hub, reader controller, cable or driver may still become the bottleneck. Record the actual reader and port, then check station headroom with an appropriate reference device.

Protect data and control the run

Full-range write tests are normally destructive. A block-device mode can also overwrite the partition table. Before testing:

1. identify the device by more than a drive letter;
2. copy required files to another medium and verify the copy;
3. connect the computer to stable power;
4. disable automatic sleep for the defined run;
5. prevent unplugging, reader changes and unrelated heavy I/O;
6. preserve the original logs before formatting or repair.

The SD Association formatter guidance likewise tells users to back up data before formatting and notes that overwrite formatting may take substantial time. Operating discipline matters because an interrupted host path can look like a card failure.

Confirm what the tool actually does

The product name of a utility is not a method definition. Confirm whether it:

1. writes unique or otherwise verifiable data;
2. covers the complete agreed usable range or only a sample;
3. reads the data back and compares it with the expected pattern;
4. reports tested bytes, error positions, corruption and loss;
5. formats, repairs or restores data automatically.

F3 provides a transparent example. Its f3write fills a mounted medium with pseudorandom files and f3read checks whether the same content returns. f3probe is a faster, destructive block-device probe. These modes do not cover the medium in the same way and must not be reported as one generic “full test” [1].

A reproducible sequence

1. Preserve initial evidence

Photograph the card and packaging, capture available identity fields, and record reported capacity and filesystem. If an error already occurred, export its log before any format or repeated run.

2. Establish the station

Run a known-good reference card on the original reader path. A reference failure points toward the station, but a reference pass does not automatically clear the suspect sample.

3. Write the agreed range

Record start and finish times, bytes written, average or time-series performance and interruptions. A progress bar is not the final evidence.

4. Read back and compare

The expected content must be compared with the returned content. Opening a directory or completing a read-only scan does not establish the same evidence.

5. Archive before recheck

Store logs, screenshots, conditions and sample identity together. Only then move the failed sample to the controlled reference path while retaining the same software version and mode.

Estimate whether a claimed full test is plausible

A simple scheduling estimate is:

test time ≈ data amount / actual write speed + data amount / actual read speed

For 256,000 MB written at 40 MB/s and read at 90 MB/s:

• write time: 6,400 seconds;
• read time: about 2,844 seconds;
• theoretical total: about 154 minutes.

This is an example, not a Kalstor product specification. Filesystem overhead, comparison work, temperature and background activity add time. If software claims a large-capacity full test in a fraction of this order of magnitude, confirm whether it sampled rather than covered the full range.

Do not translate a red block into a physical diagnosis

A desktop utility operates on host-visible logical addresses. A red area may mean returned-data mismatch, command failure, timeout or another tool-defined state. It does not directly reveal a NAND die defect or the controller's internal bad-block, spare-block and wear-level mapping.

Recheck without “testing until it passes”

Define the recheck order before seeing the result:

1. inspect host sleep, disconnect, space and system-event records;
2. run the reference card on the original chain;
3. move the failed sample to the controlled reference reader and port;
4. keep software version and test mode unchanged;
5. if the error repeats, isolate the sample for supplier analysis;
6. if it does not repeat, retain the first result and investigate the original chain.

Repeatedly formatting and rerunning until one green screen appears destroys diagnostic value. The protocol should state the number of repeats, allowed variable changes and disposition rule in advance.

What procurement and quality should receive

A release record should connect the sample and lot identity to the test range, tool and version, reader chain, start and finish time, full logs, error positions, first result, recheck result, operator, approver and disposition.

For an agreed project, Kalstor can help structure the capacity, reader, target host, sample count and failure-escalation fields into a validation sheet. This support does not turn a desktop run into product certification, target-host compatibility evidence or endurance qualification. Those claims require their own defined methods.

For related procedures, see the microSD incoming-inspection checklist and the comparison of full-address scanning and write verification.