Data Recovery Case File · Cameras, Drones & Cards · Suspect the Host
The Device That Was Already Misbehaving
His enquiry contains a detail offered as background that turns out to be the lead. His father's phone "has been going berserk for a while now. Today the phone didn't recognise the microSD card that was in it — about a year's worth of photographs. I took it out and plugged it into my computer, ran various searches, and my computer couldn't find it either. I've used alcohol wipes to try and wipe any dust or" dirt from the contacts. Two things follow. The card is genuinely faulty — and a handset that has been malfunctioning for weeks and then kills a card is a suspect, not a bystander.
| Media | microSD card from a handset exhibiting prolonged instability — card not recognised by the phone or by a separate computer; approximately one year of photographs held |
| Reported situation | Handset behaving erratically over an extended period · card no longer recognised by the phone · card not detected on a separate computer · contacts cleaned by the owner · approximately one year of photographs held |
| Fault class | Card-level failure with the host implicated as a possible cause — slot, contacts or supply on the handset to be established before reuse |
| Equipment used | No further insertion into the suspect handset · enumeration attempted write-blocked under strict timeouts (DeepSpar USB Stabilizer 10Gb) · chip-level read past the controller where required · photographs validated by rendering |
The decode: why the phone matters, and the cleaning question
What the computer test established: the important elimination, and he did it unprompted. A card that is invisible to a completely separate machine is a faulty card rather than a phone that has lost track of it. So the card genuinely needs work — that part is settled.
Why the phone is nevertheless the thing to worry about next: a handset that has been unstable for weeks is not a neutral environment. A worn or damaged card slot with poor contact, or a fault in the power circuitry feeding it, can damage what is inserted rather than merely failing to read it. Intermittent power to a card — enough to start it, not enough to run it, applied repeatedly — is considerably harder on a controller than clean power or no power. And a phone described as going berserk has, by definition, something wrong with it.
What follows practically, and it is the most useful thing here: do not put a replacement card into that phone. This is the pattern that catches people — the card fails, a new one is bought, it goes into the same handset, and some weeks later it fails too. At that point the conclusion drawn is usually that the cards were faulty. If another card is available, testing it in that phone settles the question before anything valuable goes near it. And if the phone is due for replacement anyway, that decides it.
On the alcohol wipes: a reasonable instinct, and mostly harmless, with two caveats. Isopropyl alcohol on a lint-free swab is the correct way to clean contacts; consumer wipes can leave residue and moisture behind, and rubbing repeatedly wears the thin plating on the pads. More to the point, dirty contacts would not explain a card being invisible to a card reader as well — poor contact tends to produce intermittent detection rather than none. So the cleaning was unlikely to have been the answer, and it is worth knowing that so no further cleaning is attempted.
Why the photographs are probably recoverable: a card that has stopped enumerating has usually lost its controller rather than its memory. The route past it is to read the memory directly through the card's internal test points and reconstruct in software — descrambled, error-corrected and rebuilt through the translation layer until the filing structures stand up.
What to stop: further insertion anywhere, and particularly in the phone that may have caused this.
On the bench
No further insertion into the suspect handset was attempted, since a phone that has been unstable for weeks may have a slot or supply fault capable of damaging what is inserted — and the commonest sequel to this case is a replacement card failing the same way. Enumeration was attempted write-blocked behind the DeepSpar USB Stabilizer 10Gb under strict timeouts, and where the controller could not be brought up the memory was read at chip level past it and reconstructed in software. Photographs were validated by rendering.
The outcome
The card read past its failed controller and the photographs validated and delivered. Free assessment, one fixed written figure including VAT, 50% of parts and labour upfront with the balance only on successful recovery. The decode, for anyone whose card died in a phone that was already misbehaving: the card is genuinely faulty, since a separate computer could not see it either — but the phone is a suspect rather than a bystander. A worn slot or a fault in the power feeding it can damage what is inserted, and intermittent power is harder on a controller than none. Don't put a replacement card in that handset until it has been tested with one you don't care about.
Card that failed in a phone that was already playing up
Don't put a new card in that phone — this is the pattern that catches people. The card fails, a replacement goes into the same handset, and weeks later that one fails too, at which point everyone concludes the cards were faulty. A worn card slot, damaged contacts, or a fault in the power feeding the slot can damage what's inserted rather than just failing to read it, and intermittent power that's enough to start a card but not run it is harder on its controller than no power at all. Test the phone with a card you don't care about first. Your elimination was good, though: a card invisible to a separate computer is genuinely faulty. And cleaning was unlikely to be the answer, since dirty contacts cause intermittent detection rather than none.
Don't put a new one in it — call Newcastle Data Recovery on 0191 406 1051; enumeration read under strict timeouts, memory read at chip level past the controller, photographs validated by rendering.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.