Premise: this article covers only the advanced layer, after the basic checks are done
This article starts with a premise that must be stated up front: you have already tried another card that is known to be good, tried another reader or adapter, reinstalled the driver, seated the card firmly, tried another USB port, and restarted the machine — and the laptop SD or microSD reader still cannot read the card, keeps dropping out, runs extremely slowly, or reads only half the capacity. If any of those basic checks has not been done, the advanced reasoning in this article does not apply; go back to the basics first, because everything here is built on the starting point that the basics have already been excluded. This article will not rewrite the basic steps of swapping the card, swapping the reader, and reinstalling the driver as its main body. Those steps appear here only as a one-sentence premise, and everything that follows is used for layered fault location.
The subject of this article is specific, and its definition is strict. It covers any of the following five situations: first, after swapping the card, swapping the reader, and reinstalling the driver, the card is still not recognised at all, and no layer of the system can see the card; second, the card is recognised and its files can be seen, but reading or writing drops out midway and only returns after the card is removed and reinserted; third, the card can be read, but the speed is extremely slow, far out of proportion to the speed printed on the card; fourth, the card can be read, but only half its capacity is visible, or the capacity shown differs greatly from the labelled capacity; fifth, the card can be read, but writing is refused and the system reports write protection, even though the lock switch on the card is clearly not locked. These five symptoms look very different on the surface, but the advanced checking logic is the same for all of them: split by path first, then split by layer, and narrow down layer by layer, rather than jumping from one symptom straight to a verdict that the card is dead or the slot is dead.
One distinction must be kept clear throughout this article: the speed printed on the card is not the actual speed, the capacity shown by the system is not necessarily the true capacity, and the fact that the file manager cannot see files does not mean that the files are gone. The printed speed is the peak speed of the card itself under an ideal bus. The actual speed is also governed by the reader bus, host support, driver capability, contact quality, power stability, and file system state. The capacity shown by the system is the number reported upward by the card controller, and a controller can lie about that number, while a damaged partition table can also make the shown capacity smaller than the physical capacity. Under a camera direct connection, files that the computer cannot see may simply never have been exposed by the protocol layer, while the files themselves remain on the card. The first task of advanced diagnosis is to break these apparently identical failures back down into problems at different layers.
The first principle of advanced diagnosis: split by layer first, then replace parts
The most common waste in SD reader faults is treating problems at different layers as if they were the same single fault, described as a dead card or a dead slot, and then replacing parts. Advanced diagnosis must first ask four layering questions, and different answers point to completely different replacement directions. First, which path has failed? The built-in slot, the USB external reader, and the camera direct connection use different controllers, drivers, and power arrangements. If the same card fails on path A but works on path B, the problem is almost certainly not the card itself, but some segment of path A. Second, which stage failed first? Is it complete non-recognition, which belongs to the enumeration layer; recognition without readable files, which belongs to the file system or partition table layer; reading that drops out midway, which belongs to the power, signal, or controller layer; reading that is extremely slow, which belongs to the bus downgrade or flash retry layer; or reading that works but writing that fails, which belongs to the write protection layer? Each failure mode has a different checklist. Third, is the failure stable or intermittent? A stable failure, where the result is the same every time, points more often to hard incompatibility, partition table or file system damage, or a broken detection pin or contact. An intermittent failure, where the result comes and goes, drops when the machine is moved, or only drops on large files, points more often to poor contact, unstable power, overheating, signal integrity, firmware, or power management. Fourth, does the card hold important data that has not been backed up? If it holds important photographs, video, or work files that have not been backed up, the diagnostic order must be reversed: make a read-only backup first, and only then carry out any test that might write to the card. That order is not a suggestion. It is a hard line, and a later section deals with it in detail.
In one sentence, the advanced way of thinking is this: do not ask which part is broken; ask which signal or which negotiation step at which layer has failed. Once the question changes, the whole checking order changes with it: from trying yet another reader to asking at which layer, on which path, the card stops, and which control group can prove that a given layer is healthy. Control groups are the soul of advanced diagnosis, and a conclusion without a control group is only a guess. Another card that is known to be good, another reader, another port, and another machine each exclude one class of variable, and only when all four have been done can the problem be said to have been narrowed to a layer. Drawing a conclusion after only one control test is the most common thinking shortcut at the advanced layer.
The three paths: built-in slot, USB external reader, and camera direct connection
Many users think of a card reader as one thing. In fact a laptop has three completely different card reading paths, and their fault location methods are completely different. Mixing the three paths together is the first knot that advanced fault finding must untie. The built-in slot follows an internal controller path inside the machine, the USB external reader follows a USB bridge path, and the camera direct connection follows a camera firmware plus transfer protocol path. The three paths share only the card itself. Almost everything else — controller, driver, power, and protocol — is different. So the result that an external reader can read the card while the built-in slot cannot is itself a very strong location message: it almost excludes the card itself and narrows suspicion to the built-in slot segment. Conversely, a built-in slot that can read the card while an external reader cannot narrows suspicion to the USB segment, not to the card.
Path A: the built-in reader
The hardware form of the built-in reader is an SD slot on the side or front edge of the machine, connected through a short ribbon cable or a daughter board soldered directly to the main board, to a reader controller. There are two main controller forms. The first is a PCIe internal controller, for example the Realtek RTS5227 series, which the vendor support page lists as a Realtek built-in reader chip, a chip connected to the main board through PCIe that handles SD, SDHC, SDXC, microSD through an adapter, and MMC communication. The second is an SD host controller integrated into the platform controller or system-on-chip, following the SDHCI standard interface. On the Windows side, the official standard SD host controller sample explains that the driver, together with the protocol layer, provides the host controller register interface, but the same sample states plainly that it does not support UHS-I speed modes, HS400, SD 4.0, and other newer features. That point matters greatly: the fact that the built-in Windows generic driver recognises a device does not mean that it runs at full speed, and a vendor driver and a generic driver can differ greatly in capability.
How can Windows tell a built-in slot from an external reader? Open Device Manager. A built-in PCIe reader usually appears under memory card readers or PCI devices, and its hardware identifier carries a PCI vendor code, for example the Realtek vendor code and device code, while a USB external reader appears under universal serial bus controllers as a USB device. Looking at the hardware identifier is the most reliable dividing line. Looking at the device name alone is not enough, because a vendor can rename a device. On macOS, System Information lists the built-in SDXC slot and its supported standard. On Linux, a built-in SDHCI controller usually appears as an mmc device, while a USB reader appears as an sd device, and that device name difference is a quick system-layer way to tell the paths apart.
The built-in slot has fault points that an external reader does not have at all: a loose or crushed ribbon cable, cracked solder joints on a daughter board, tired springs or detection pins inside the slot, power control of the slot by firmware or the embedded controller, and PCIe link problems. Those faults do not exist on a USB external reader at all, so the finding that an external reader can read the card while the built-in slot cannot almost excludes the card itself and locks attention onto the built-in slot segment. In the other direction, the built-in slot has fewer power variables, because it is powered directly by the main board and does not pass through a USB hub, so power problems are less common there. Even so, power reset after waking from sleep can still leave the built-in slot unable to recognise a card until the card is removed and reinserted, and that belongs to the power management layer, not to a dead slot.
Path B: the USB external reader
The hardware form of a USB external reader is a standalone reader connected through USB, with a USB-to-SD bridge chip inside, for example a Genesys Logic bridge solution, supporting SD, SDHC, SDXC, and microSD through a USB connection. One confusion must be avoided: a well-known class of high-speed bridge chips is a USB-to-solid-state-drive bridge used for external solid-state drives, not an SD reader chip. Seeing the words high-speed bridge and assuming that it means a high-speed SD reader is a common misreading. The bottleneck of an SD reader must be judged by its own chip and its SD bus support, not by the peak figure of the USB bridge chip. No matter how fast the USB segment is, if the SD segment only supports a given grade, the actual speed is locked to the SD segment ceiling.
How does the system tell an external reader apart? In Windows Device Manager it appears as a USB mass storage device. When the card is removed and inserted, the whole USB device disappears and reappears, together with the drive letter. On Linux it appears as an sd device. If the USB device itself does not move when the card is removed and inserted, and only the drive letter appears or disappears, that is the reader firmware behaviour of hiding the drive letter for an empty slot, not a fault. The external reader has its own fault points: insufficient USB power, USB selective suspend, high-speed USB signal interference, cable or hub bottlenecks, bridge chip firmware problems, and the speed ceiling of a USB 2.0 reader itself. Those faults do not exist on a built-in slot, or they appear differently there, so getting the path division wrong sends the whole investigation in the wrong direction.
Path C: camera direct connection
A camera direct connection has three sub-modes, and they must be told apart first. The first is USB mass storage mode, in which the camera presents the card as if it were a USB stick. The computer sees a drive letter and can read and write the card file system directly. Older cameras commonly use this mode. The second is PTP, Picture Transfer Protocol, in which the camera only shows the computer the photographs and video objects that it is willing to show. The computer sees no drive letter. It sees a camera device, in File Explorer or in a photo import tool. Some cameras have a USB mode switch in the menu, mass storage versus PTP, and choosing the wrong one produces the false fault of a camera connected but no files visible. The third is MTP, Media Transfer Protocol, a media transfer protocol in the same family as PTP. The computer sees a portable device rather than a drive letter, can only browse media objects, and cannot carry out disk-layer operations directly, for example it cannot run a disk image and cannot repair the file system directly.
The key inference is that a camera direct connection that cannot see files does not mean that the card is broken. Possible causes include a camera USB mode set to PTP or MTP rather than mass storage, a camera that only shows photographs inside the DCIM folder while files in other folders never appear, and camera firmware that stalls outright when the card has a bad sector, while a simpler reader swallows the error and keeps going. The golden rule for diagnosis is that whenever the card itself is suspected, the card must always be tested again with a standalone reader, and no conclusion about the card should rest on a camera direct connection alone. A camera direct connection adds a layer of camera firmware and protocol translation, with too many variables, and it is not suitable as the basis for judging card health. Conversely, if a standalone reader can read the card but a camera direct connection cannot, the problem lies in the camera setting or protocol, not in the card.
| Path | What the computer sees | System device name | Controller | Fault points unique to this path | Suitable for disk imaging |
|---|---|---|---|---|---|
| Built-in slot | Memory card reader or PCI device; drive letter appears after the card is inserted | On Linux, usually an mmc device | PCIe reader chip or platform built-in SD host controller | Ribbon cable, daughter board, slot springs, firmware power control | Yes, when a disk device is visible |
| USB external reader | USB mass storage device; drive letter appears after the card is inserted | On Linux, usually an sd device | USB-to-SD bridge chip | USB power, selective suspend, hub, cable, bridge firmware | Yes, the most common choice |
| Camera direct connection, mass storage | Drive letter | Varies by system | Camera main chip plus USB device-side firmware | Camera firmware, USB mode setting | Possible but not recommended, with an extra camera firmware layer |
| Camera direct connection, PTP or MTP | Camera device or portable device, no drive letter | Not a disk device | Camera main chip plus USB device-side firmware | USB mode, only media objects exposed | No, the protocol layer does not expose a disk |
Symptom triage: describe the phenomenon first, then name the layer
The first step of advanced investigation is not to replace another piece of hardware. It is to answer three layering questions, because without them every later action will go in the wrong direction. First, at which layer does the chain stop? Does Device Manager or System Information see the reader itself? Does Disk Management or Disk Utility see the card? Does File Explorer or Finder see the volume? The combination of answers to those three questions points directly to different layers. Second, is this a whole-system problem, or does it only happen on this machine, this account, or this power state? For example, a fault that only appears after waking from hibernation, only under a company domain account that refuses writing, or only behind one particular USB hub points to completely different layers. Third, does the card hold important data that has not been backed up? If it does, the order of the whole article must be reversed: stop first, make a read-only image first, and only then talk about repair, formatting, or rebuilding partitions. Without important data, rebuilding partitions and formatting can be discussed first.
| Symptom | Layer pointed to first | Thing that should not be done at once |
|---|---|---|
| Device Manager shows a yellow warning or an error code | Driver layer, registry filter layer, power layer | Reinstalling the same driver repeatedly without looking at the error code and the driver date and vendor |
| Disk Management sees a disk but no volume, or shows RAW | Partition table layer, file system layer | Pressing format at once, or running repair at once |
| File Explorer cannot see the card, but Disk Management sees it and reports it as healthy | Drive letter layer, group policy or encryption layer | Assuming that the card is dead and throwing it away |
| Finder cannot see the card, but Disk Utility sees it and reports it as not mounted | macOS mounting layer, Finder display layer | Erasing it at once |
| Dropping out from time to time, getting slower as copying goes on, failing at a certain capacity | Power layer, bus layer, fake card or flash wear layer | Keeping on copying onto the same card, or repeatedly retrying writes |
| Camera direct connection shows only photographs, not other files | Camera USB mode layer, PTP or MTP versus mass storage | Assuming that the files are gone and formatting inside the camera |
| Every card inserted into the same slot reports write protection | Slot detection pin layer | Assuming that every card is locked and formatting them one by one |
| Speed locked for a long time at one low level, the same after swapping cards | Bus or reader bottleneck layer | Assuming that the card has aged and buying new cards one after another |
The contact layer: gold fingers, springs, and slot deformation
The basic layer has already swapped the card and the reader, but a contact layer problem can still produce the result that swapping the card does not help, because the problem is on the slot side, or in the fit between the card and the slot. A UHS-I card has only one row of contacts on its back, in the traditional nine-pin layout. A UHS-II card has a second row of contacts behind the first row, two rows in total. A microSD card is itself smaller, with denser contacts, and when it is used through a microSD-to-SD adapter, the contact points become two groups in series: microSD to adapter, and adapter to slot. The failure chance is not simply doubled. It follows a series rule: if either group has poor contact, the whole group fails. An adapter itself has no controller. It is only a set of passive contacts and traces that maps microSD pins to SD pin positions. Passive does not mean fault-free: the microSD slot inside the adapter also has springs and contacts that oxidise, tire, and deform; the adapter lock switch is the adapter own slider and has nothing to do with the microSD card itself; and when the adapter shell has a larger tolerance, the microSD card inside the adapter may shift slightly, so that the high-speed signal fails first and the result is a speed drop rather than complete failure to read.
Write protection detection is not the switch on the card cutting power by itself. The lock switch on the side of the card is only a plastic slider, and it carries no electricity by itself. What really detects its position is a microswitch or detection pin inside the slot. A technical discussion explains that write protection is judged by a microswitch inside the socket: when the slider is pushed forward, toward the pin direction, the switch arm should close and ground the write protection circuit, and only then can the card be written. If the detection arm is damaged, every card inserted will report write protection. That mechanism is expanded in the write protection section. For now, remember one principle: the slider itself does not conduct electricity, the detection pin is the key, and a broken slot can make every card report write protection.
On oxidation, the gold finger surface is theoretically gold plated and fairly resistant to oxidation, but in practice the contacts inside the slot, the contacts of an adapter, and the non-plated edges of the card, when exposed for a long time to humid air, sweat, and dust, still form an oxide film or a dirt film that raises contact resistance. A high-speed mode such as UHS-I SDR104 demands very high signal integrity. A slight rise in contact resistance can cause high-speed negotiation to fail and fall back automatically to a lower mode, or to retry repeatedly. Under a low-speed mode everything may look completely normal, and only under a high-speed mode does the fault appear. That is the classic contact layer signature of an old card that reads at low speed while a new high-speed card cannot be read. On spring fatigue, the contacts of a built-in slot are spring leaves that press against the card gold fingers by spring force. Long-term insertion and removal, long-term pressure from a card left inserted, or a card that is slightly thick or slightly bent, can all reduce the spring force of individual leaves, producing symptoms such as reading only when the card is pushed fully in, dropping when the card is moved slightly, or reading only at a certain angle. An external reader has spring fatigue too, but because the whole reader can be replaced, the effect is smaller. Spring fatigue in a built-in slot can only be seen after opening the machine.
On slot deformation, a laptop that has been dropped, pressed, had a foreign object enter the slot, or had a thicker card or adapter forced in, may suffer slight deformation of the slot opening or its internal guide rails, so that the card does not sit parallel when inserted, and individual contacts bear uneven pressure. The symptoms are often intermittent and highly correlated with how deep the card is inserted and at what angle. On card wear and bending, an SD card is itself a plastic shell around a small circuit board. Long-term insertion and removal, pressure, and sun exposure can bend the shell slightly, so that the gold fingers no longer meet the slot contacts evenly. A microSD card is thinner and bends more easily, and when it is used through an adapter, wear of the adapter plastic shell itself magnifies the problem.
Contact layer tests that can be done without opening the machine include the following. Is the same card consistent between the built-in slot and the external reader? If not, the slot side takes priority. Is the same card consistent across different adapters? If not, the adapter takes priority. When the card body is pressed lightly at different positions, or the insertion depth is changed slightly, does reading come and go? If yes, contact, spring, or deformation takes priority. Does the card gold finger show obvious scratches, dull patches, or green or white spots? If yes, assess cleaning first, using only a suitable method and never scraping with a hard metal object, and if the card is still unstable after cleaning, send it for inspection. Note that these tests only apply to cards that have been backed up or that hold no important data. A card with important data should first be imaged read-only, and should not be subjected to repeated insertion and removal as a stress test.
The protocol layer: negotiation failure that looks like a slow card
This is the layer most easily misdiagnosed at the advanced level. The speed printed on the card is the peak of the card itself under an ideal bus. The reader and host bus is the actual ceiling. The lower of the two governs, and on top of that, a downgrade after a negotiation failure can make the actual speed an order of magnitude lower than the printed figure, while the card itself is completely undamaged. Three different concepts must be kept apart. Bus speed is the width of the channel between the card and the reader, and UHS-I, UHS-II, UHS-III, and SD Express are all bus standards. Speed class is the minimum sustained write speed guaranteed by the card, for example Class 10, U1, U3, V30, V60, V90, A1, and A2. A speed class marks a minimum speed, not an actual speed, and cards of the same class can perform very differently in practice. The printed peak speed is the highest read speed measured by the vendor under ideal conditions, usually sequential reading. It is not a guaranteed value, and still less is it a write speed. Mixing these three figures is the root of speed misdiagnosis.
UHS-I uses only the first row of contacts, and raises speed by raising the clock rate and the signal mode. SDR12, SDR25, SDR50, DDR50, and SDR104 are different speed modes, and SDR104 is the top of UHS-I. The negotiation flow, in outline, is that the host and the card first communicate in a low-speed mode, exchange capabilities, and then try to switch to a higher-speed mode and carry out signal training. If training fails, or signal integrity is insufficient, for example because of poor contact, cable or trace problems, or voltage switching problems, the host should fall back to a lower mode and try again, rather than giving up outright. That is the mechanism behind the finding that a card can be read, but its speed only reaches a lower mode level. Common triggers for a UHS-I downgrade include the following. A high-speed mode requires the signal voltage to switch from a higher level to a lower level. If the host, the reader, or the card is unstable in switching, the high-speed mode cannot be reached. When contact resistance rises, the high-speed signal distorts first, while the low-speed signal can still pass. When the reader chip itself only supports a lower mode, no card, however fast, can help. And when the Windows generic SD host controller sample driver is used, it does not support UHS-I speed modes, so speed is locked to a lower mode, and only a vendor driver gives a chance of reaching high speed.
A UHS-II card has two rows of contacts on its back. The first row is the traditional UHS-I contact row, and the second row is the added high-speed channel. Turn the card over and look at the contacts: one row means UHS-I, and two rows are needed for a chance of running UHS-II. Insert a UHS-II card into a UHS-I slot that has only one row of contacts, and the second row of contacts has no counterpart to talk to, so the card is used as an ordinary UHS-I card. It is not damaged, but its speed cannot rise. The fault significance is that if any one group in the second row of contacts has poor contact, oxidation, scratches, or if the second row of springs in the slot is tired, UHS-II negotiation will fail, and the system will quietly fall back to UHS-I mode. What the user sees is a card that can be read, with all files present, but with speed fallen from a higher level to a lower level, and the user thinks that the card has aged and slowed down, when in fact the second channel has failed. How can a second-row failure be told apart from a card that is simply slow? Use the same UHS-II card and the same UHS-II external reader on another computer that is known to support UHS-II and measure the speed there. If high speed returns on the other machine, the problem lies in the original machine slot or controller, not in the card. Check the second row of contacts on the card for obvious scratches, stains, or dull patches. Check whether the second row of springs inside the slot is deformed, which needs opening the machine or sending it for inspection, and never probe the slot with a hard object. Note also that many laptop built-in slots only support UHS-I, so even with a UHS-II card, the speed ceiling remains the UHS-I ceiling. That is not a fault. It is a specification ceiling, and the laptop specification should be checked before buying a card.
| Bus | Theoretical ceiling |
|---|---|
| Default Speed | 12.5 MB/s |
| High Speed | 25 MB/s |
| UHS-I SDR50 or DDR50 | 50 MB/s |
| UHS-I SDR104 | 104 MB/s |
| UHS-II half duplex | 312 MB/s; full duplex 156 MB/s per direction |
| UHS-III full duplex | 624 MB/s |
| SD Express PCIe Gen 3 x1 | 985 MB/s |
| SD Express PCIe Gen 4 dual lane | Up to 3,940 MB/s |
The reader bottleneck is the most common misdiagnosis. On the USB 2.0 reader ceiling, the theoretical bandwidth of USB 2.0 is itself below the UHS-I SDR104 ceiling, and after protocol overhead is deducted, the actual speed is often only in the twenties of MB/s. Measuring a card marked as high speed with a USB 2.0 reader and obtaining a slow result reflects the reader, not the card. A USB 3.x reader is not necessarily a UHS-II reader: USB 3.0, 3.1, and 3.2 only describe the speed of the USB segment, not whether the SD segment supports UHS-I or UHS-II. There are many readers on the market described as USB 3.0 readers whose SD segment only reaches UHS-I, and a UHS-II card inserted into them still only runs at UHS-I speed. Buying a reader requires looking at two figures at the same time: USB speed and SD bus support. On the built-in slot bottleneck, a laptop vendor specification sheet may only write SD reader or SDXC slot, without writing the UHS grade. A more transparent example lists support for UHS-II, but not for UHS-III or SD Express, and actual transfer may still fall below the theoretical ceiling, showing that supporting UHS-II does not mean running at the full theoretical ceiling. The Windows laptop situation varies even more, and the official specification or service manual for that model must be used, rather than inferring from the printed card speed. On hub and cable bottlenecks, when an external reader is connected through a USB hub, an extension cable, or a USB-C adapter, hub bandwidth is shared among several devices, and the USB version of the cable also limits speed. In advanced testing, the reader should first be plugged directly into a machine USB port, without passing through a hub, to exclude hub and cable variables.
The protocol layer diagnostic flow, for speed problems specifically, runs as follows. First, record the card markings: capacity type, UHS grade, and speed class. Second, record the reader markings: USB version, SD bus support, and whether it passes through a hub. Third, record the host markings: the SD support grade in the official specification for the laptop model. Fourth, take the lowest of the three, and that is the theoretical ceiling. A measured speed close to the ceiling is normal. A measured speed far below the ceiling enters downgrade investigation, covering contact, driver, power, and flash retry. Fifth, cross-test: the same card plus the same reader measured once on another machine, and the same machine plus the same reader measured once with another card of the same grade. Only by comparing the two results can the fault be assigned to the card, the reader, or the host.
The capacity layer: reading only half, a 32 GB ceiling, and sudden shrinkage
Reading only half the capacity has at least five completely different mechanisms, and their handling methods are opposite to one another. They must never all be treated as a dead card or all be formatted. The first mechanism is the FAT32 limit of Windows built-in tools. The Windows File Explorer and Disk Management built-in formatting tools only offer the FAT32 option for volumes of 32 GB or below. For a card larger than 32 GB, the built-in tools by default only offer exFAT and NTFS. That is a human-imposed limit, not a technical ceiling of FAT32 itself, because the FAT32 format itself can support a larger volume. The misreading consequence is that a user who sees no FAT32 option thinks that the card is broken, the reader is broken, or the system is broken, when it is only an option limit of the Windows tool. Conversely, if a user insists on formatting an SDXC card as FAT32 to suit an older device, another tool or a command line method must be used, and it must first be confirmed that the target device really needs FAT32. By the same logic, if a larger SDXC card is mistakenly formatted as a 32 GB FAT32 volume, the remaining space becomes unallocated space, and File Explorer will only show 32 GB. The user thinks that the card has shrunk by half, when in fact the partition has been made smaller. Disk Management will show the combination of a full physical disk plus a small volume plus black unallocated space. Expanding or rebuilding the volume can restore it, but rebuilding affects data, and for a card with important data a read-only image must be made first, rather than rebuilding directly.
| Capacity type | Capacity range | Factory default file system |
|---|---|---|
| SD | Up to 2 GB | FAT12 or FAT16 |
| SDHC | Over 2 GB up to 32 GB | FAT32 |
| SDXC | Over 32 GB up to 2 TB | exFAT |
| SDUC | Over 2 TB up to 128 TB | exFAT |
The third mechanism is an SDXC card inserted into an older reader that only supports SDHC. The SDHC ceiling is 32 GB, and SDXC starts above 32 GB. An older reader that only supports SDHC, at hardware or firmware level, when it meets an SDXC card may show three behaviours: complete non-recognition, recognition but a wrong capacity display, or recognition but unstable reading and writing. That is a hardware capability ceiling, and reinstalling a driver cannot solve it, unless the vendor has a firmware update that explicitly adds SDXC support. The difference from the second mechanism is that the second is an operating system or file system driver problem, where changing to a new computer may solve it, while the third is a ceiling of the reader hardware itself, where changing to a new computer but keeping the same older reader still cannot solve it, and the reader must be replaced. The detection method is to check the official specification of the reader or laptop model to see whether it is marked as supporting SDHC or SDXC, and to test a 32 GB or smaller SDHC card on the same reader. If the SDHC card is normal and the SDXC card is not, the older reader ceiling is the strongest suspect.
The fourth mechanism is a fake card or expanded-capacity card, the most dangerous capacity illusion. The controller of a fake card has been rewritten to report upward a figure far larger than the true flash capacity. The operating system and File Explorer only show the figure lied about by the controller, so a display that looks exactly right proves nothing at all about whether the card is genuine. The failure mode is that before the amount of data written exceeds the true capacity, everything looks normal. Once the amount written exceeds the true capacity, the controller starts overwriting old data or discarding new data. Files become damaged, photographs cannot be opened, video breaks halfway through playback, and the damage happens silently, so the user often only discovers it when reading the data back. The only reliable detection method is to write the card full and read it back for verification. The standard method uses a full-write verification tool to write known test data across the whole labelled capacity, and then read it all back for comparison. A genuine card reports that the test completed with no errors, while a fake card reports many errors and reveals the true usable capacity. An important warning is that a capacity verification test is itself destructive, because it writes the whole card full. It can only be done on an empty card or a card that has been backed up, and never on a card with important data. The test takes a very long time, and a large card may take hours, and the test must not be interrupted. A fake card does not necessarily show half capacity. It usually shows the complete fake capacity. Reading only half is more often a partition table problem or an older reader ceiling. Even so, if a card starts damaging files after a certain amount has been written, even though the shown capacity looks complete, a fake card must be suspected. On the buying side, fake card risk is highly related to the purchase channel. Buying only from authorised dealers, being wary of abnormally low prices, checking packaging and warranty information, not buying second-hand or refurbished cards, and verifying a new card before use are practical directions.
The fifth mechanism is the contrast between partition table damage and controller damage. They look similar, but their handling is completely different. With partition table or file system damage, Disk Management shows a physical disk capacity that is roughly correct, but the volume shows RAW, unallocated, or a smaller capacity. Reading and writing may intermittently read some files, but the file system structure is disordered. The handling direction is to make a read-only image first, and then carry out file system repair or data rescue on the image. With controller damage, the display may show zero bytes, no media, jumping capacity, or complete non-recognition. Reading and writing show repeated disconnection, read timeouts, and no tool can read stably. The handling direction is not to test repeatedly with power applied. With important data, the card should go directly for professional data rescue assessment. Without important data, it should simply be replaced. Formatting in the partition table damage case clears file system records and may make rescue harder, so it should only be considered after data has been backed up or given up. In the controller damage case, formatting is usually useless, and may even worsen the controller state.
One more capacity difference must be stated clearly, because it is not a fault: the decimal versus binary capacity difference. Vendors label capacity in decimal, while Windows displays it in binary, so a labelled card will always show a slightly smaller figure in Windows. Only when the gap is far larger than this conversion difference, for example half missing or nine-tenths missing, does it count as abnormal. The capacity layer diagnostic flow is as follows. First, open Disk Management, Disk Utility, or a system device list, and record three figures: physical disk capacity, volume capacity, and unallocated space. Second, a correct physical capacity plus a smaller volume plus unallocated space points to a partition problem first. Third, a physical capacity itself smaller by half or more points to an older reader ceiling, a controller problem, or a fake card, which must be told apart by full-write verification, but only on an empty card. Fourth, a jumping physical capacity, zero bytes, or no media points to a controller problem first, and repeated testing should stop. Fifth, is the physical capacity consistent across different readers or computers? If not, reader or host support takes priority. If consistent, the card itself takes priority.
The disconnection layer: USB power, selective suspend, interference, firmware, heat, and flash wear
Repeated disconnection is the most wearing symptom, because it appears intermittently, is hard to reproduce, and each cause has a different repair method. On insufficient USB power, a USB external reader is powered through USB. The power capability of a laptop USB port, the power method of a hub, powered versus unpowered, and the other USB devices connected at the same time, all affect the power stability of the reader during high-speed transfer. During continuous transfer of large files, current demand is higher. When power is marginally insufficient, the reader first shows transfer errors, and in severe cases the whole USB device resets, which is what the user sees as disconnection followed by reconnection. The detection method is to plug the reader directly into a machine USB port, without a hub and without an extension cable, and then transfer a large file. If direct connection is stable but connection through a hub drops, the problem lies in the hub or power. If direct connection also drops, the problem lies in the reader, the cable, the host USB port, or the card itself. The built-in slot has fewer power variables, because it is powered directly by the main board and does not pass through a USB hub, so power problems are less common there. Even so, firmware or embedded controller power management, and power reset after waking from sleep, can still leave the built-in slot unable to recognise a card after waking, until the card is removed and reinserted.
On USB selective suspend, Windows has a power management feature under which the system selectively suspends a USB device when it is idle, to save power. Some readers or bridge chips handle the suspend-to-wake transition poorly, and after waking they cannot resume normally, showing up as a card that disappears after a period of idleness, a transfer that drops midway, or a card that only returns after removal and reinsertion. The diagnostic logic is to first cancel, in Device Manager, the option to allow the computer to turn off the device to save power, for individual USB root hubs or devices, and then, if needed, set USB selective suspend to disabled in the power plan. If disconnection disappears after disabling, that proves that the device cannot handle the selective suspend transition cleanly. If disconnection still happens after disabling, the problem lies in the cable, the bridge chip, insufficient power, or the driver, and the setting should be restored to its original state, rather than leaving a power saving feature disabled for a long time. Note that selective suspend only affects the USB external reader path, and does not affect a built-in PCIe or SDHCI slot. If a built-in slot shows a similar symptom of disappearing after idleness, the host PCIe or SDHCI power management, sleep settings, or firmware should be checked, not USB selective suspend.
On fast startup, fast startup is a Windows hybrid shutdown: on shutdown, core state is written to a hibernation file, and on startup it is restored directly, rather than fully reinitialising every device. The effect on a USB reader is that USB controller state and reader state left over from the previous startup may be carried into the next startup, showing up as a reader that disappears after startup and only returns after removal and reinsertion, or a card that is normal on the first insertion after a restart but not on the second. The advanced test is that if the fault only appears after shutdown followed by startup, but not after a restart, fast startup residue should be strongly suspected, because a restart usually fully reinitialises devices, while a fast startup shutdown does not. When testing, a true full shutdown followed by startup with fast startup disabled must be done, rather than several restarts in a row, because the test itself would otherwise hide the residue state. Disabling fast startup makes startup slightly slower. That is a trade-off, not damage caused by repair.
Need a laptop repair expert?
Free diagnosis · Transparent pricing · No fix, no fee · 180-day warranty
On a reader disappearing after waking from sleep or hibernation, three waking situations must be told apart. Disappearance after waking from sleep mostly involves selective suspend or root hub power management that has not resumed. Disappearance after waking from hibernation may involve device state inside the hibernation file, or reader firmware that cannot re-enumerate after power has been fully cut. Disappearance after closing and reopening the laptop lid may involve a power policy triggered by the lid action, or vendor power management software that additionally controls USB power. If the fault only happens after waking, and a cold startup is completely normal, the investigation should not keep swapping cards and readers. It should focus on the power layer and on rebuilding the USB controller stack, which means uninstalling USB controllers and restarting, so that Windows rebuilds the stack.
On USB signal and interference, a poor quality cable, an unshielded hub, or a reader placed too close to a wireless device may cause mutual interference. At the same time, signal loss in the cable itself can make high-speed transfer unstable, showing up as speed fluctuation, transfer errors, and intermittent disconnection, while low-speed transfer, for example reading only small files, may look completely normal. The detection method is to change to a short cable that is known to be good, plug directly into a machine port, and move away from wireless devices before testing again. If changing the cable or port restores stability, the problem lies in the cable, interference, or hub, not in the card. This article only keeps the change-cable and change-port comparison as a diagnostic method, and does not write quantified interference figures or frequency band impact figures, because those figures are unverified, as listed in the unverified list at the end.
On reader firmware problems, USB bridge chips and PCIe reader chips both have firmware, and a firmware defect may show up as a fault that only happens with a particular capacity or brand of card, only with a particular file system, only after a long transfer, or only as non-recognition after waking from sleep. The signature of a firmware problem is that the symptom is highly correlated with the model or capacity of the card, for example only happening with one series of cards, rather than with every card, and that updating reader firmware or a vendor driver makes the symptom disappear or change. The practical limit is that many low-cost external readers have no public firmware update channel at all, so a firmware problem cannot be fixed by the user, and the reader can only be replaced. Firmware updates for a built-in reader are usually included in the laptop vendor firmware or driver update package, and the official support page for the laptop model must be used, rather than downloading firmware at random from a third-party driver site. The difference between a firmware problem and a driver problem is that a driver is software at the operating system layer, while firmware is software of the chip itself. When reinstalling a driver has no effect, but the same symptom recurs after changing the operating system or changing the computer, firmware suspicion rises.
On thermal throttling and cache filling, two mechanisms that both produce a pattern of fast first and slow later must be told apart. On thermal throttling, during long continuous reading and writing, the temperature of the card controller and flash rises, and some products lower their working frequency to control temperature, showing up as a transfer speed that falls clearly after a period of time, and returns after cooling. On cache filling, some cards use a small high-speed cache to absorb writes. Once the cache is full, data must be moved to the slower main storage area, and speed falls from high speed to the native speed of the main storage area. That fall is a sudden fall after the amount written reaches a threshold, not a gradual fall with temperature. Cooling will not restore it. The controller must finish its internal move while idle before it recovers. How can the two be told apart? Thermal throttling correlates with ambient temperature and continuous working time, and speed returns after a cooling pause. Cache filling correlates with the total amount written. Before the threshold is reached, speed is normal. After the threshold is reached, speed falls, and after a period of idleness it may partly recover. Neither is a broken card, but if a card already throttles severely at normal room temperature during a short transfer, controller or flash ageing should be suspected. In the Hong Kong situation, long transfer of large files outdoors in summer, inside a car, or in an environment without air conditioning will bring thermal throttling earlier. A metal shell reader conducts heat better but itself becomes hot, while a plastic shell reader dissipates heat worse, and during long transfer attention should be paid to the temperature of the reader itself.
On flash wear and bad blocks in the card itself causing read retries, the pattern is different again. Flash memory has a limit on write and erase cycles. Long-term high-frequency writing, for example dash cameras, surveillance, or camera cards that are frequently overwritten, wears some blocks, and the controller must use error correction, bad block management, wear levelling, garbage collection, and other mechanisms to keep working. Those background tasks consume processing and storage resources, and lower the apparent transfer performance. The pattern of read retries is that the card is especially slow when reading certain files, stalls intermittently, transfer progress stays at a certain percentage for a long time before continuing, or some files are damaged while other files are normal. That happens because the controller must retry repeatedly, correct errors, or even move data to a new block when reading a worn block. The difference from poor contact is that flash wear retries usually correlate with a particular file or a particular capacity position, meaning that reading the same file is slow every time, while poor contact retries usually correlate with insertion state or movement, meaning that moving the card causes a drop. If the same file is equally slow on different readers, flash wear suspicion is larger. When the controller judges that flash memory is no longer safe to write, it may lock the card into a permanently read-only state: old data can be read out, but nothing can be written, deleted, or formatted. The purpose of that protection mechanism is to protect existing data from being further damaged by writes to damaged blocks. At that point the correct action is to back up readable data at once and replace the card, rather than forcibly breaking write protection.
| Disconnection pattern | Layer to check first | Control test |
|---|---|---|
| Disappears after a period of idleness | USB selective suspend, root hub power management | Does it disappear after selective suspend is disabled |
| Disappears after shutdown and startup, but normal after a restart | Fast startup residue | Test again after a true full shutdown with fast startup disabled |
| Disappears after waking from sleep or hibernation | Power management, USB controller stack | Cold startup normal but waking fails, which locks attention to the power layer |
| Drops during large file transfer, small files unaffected | Power, heat, cache, flash retry | Plug directly into a machine port, cool down, then transfer a large file again |
| Drops when the laptop or card is moved | Contact layer | Response to pressing the card body lightly or changing insertion depth |
| Only a particular file drops, or only a particular position is slow | Flash wear, bad blocks, file system damage | Is the same file equally slow on different readers |
| Drops in every pattern | Reader firmware, controller, host USB port, card controller | Do all three controls: change reader, change port, change computer |
| Only drops through a hub, direct connection unaffected | Hub power, bandwidth sharing | Bypass the hub and plug directly for comparison |
The driver layer: a reader is not one driver, but a stack of drivers
Many laptop built-in readers have two identities, and confusing the two is the most common starting point for an advanced fault. The first layer is the SD host controller, the layer that talks the SD protocol, which in Windows Device Manager commonly falls under an SD host adapter or memory technology device category. A support discussion records that a user finally confirmed that one vendor SD host controller was itself the built-in reader, and its driver information showed a system-provided driver file. The second layer is the reader chip driver, for example a PCIe card reader driver or a USB reader bridge driver, which handles the PCIe or USB interface of the chip itself. A real case shows a PCIe reader under memory technology devices, where the problem was solved by rolling back the driver. The third layer is the USB mass storage layer: an external USB reader first looks, to Windows, like a USB device, and then like a disk drive. If the USB layer fails, the disk layer never appears at all. If the disk layer fails, the USB layer can be completely normal. So the phrase that the driver has been reinstalled is not precise enough at the advanced layer. It must be asked which layer was reinstalled: the host controller, the chip driver, the USB controller, or the disk drive driver? Device Manager must be checked across three categories at the same time, SD host adapter or memory technology devices, universal serial bus controllers, and disk drives, rather than only one of them.
On error codes, three codes are not the same synonym for a broken driver, and their handling directions differ. Code 10 typically means that the device cannot start, with causes including an outdated or damaged driver. At the same time, a vendor custom error string inside a hardware key can make a vendor custom error message appear, so the same code can hide different vendor causes behind it. Code 43 is officially explained as Windows having stopped the device because it reported a problem: one of the drivers controlling the device notified the operating system that the device had failed in some way, and at the same time the possibility of driver damage and driver cache needing clearing is mentioned. Code 28 means that no driver is installed for the device, which differs in mechanism from Code 43, where the device reports failure. Another real case also shows a bridge chip reader showing Code 28 after a major Windows update, together with a message that the driver is not intended for this platform, which belongs to driver and platform mismatch, not merely to having no driver. The advanced method is as follows. For Code 28, first check whether the driver source matches the correct platform and architecture, whether it comes from the laptop vendor rather than a chip vendor generic version, and whether Windows Update has substituted a similar-looking driver. For Code 10, check the driver version, date, and vendor, and compare with the laptop vendor support page version. Also check whether only one kind of card, for example a large capacity card or a particular speed grade, triggers it, which means that the host controller and the card are not negotiating at the protocol layer, rather than the driver failing completely. For Code 43, do not only reinstall the driver. Check power management, the USB controller stack, and the reader chip firmware layer at the same time, and check whether the card itself triggers the same code on another machine. When the card controller itself reports failure, Windows will also use Code 43 to disable the device.
On driver rollback and Windows Update overwriting an older driver, this is the mechanism most worth suspecting at the advanced layer, yet most easily hidden by the phrase that the driver has already been reinstalled. The occasion when rollback makes sense is when the fault started only after a Windows update, a driver update, or a laptop vendor driver package update, while before that the same card and the same reader were normal. The solution in a real case was precisely to press roll back driver on the driver page, after which an adapter card could be detected again. An official reply also suggests trying rollback first, and only if that fails, uninstalling and restarting so that Windows reinstalls. The trap of Windows Update overwriting is that after a user manually installs an older driver version, the next Windows Update may push the driver back to the newer version, and the fault returns after a few days. Advanced checking must look at whether the driver date and version changed before and after the fault, not only at whether the driver is the latest. If the fault recurs after every update, the driver version and the update number should be recorded together, because otherwise the investigation starts from the beginning again next time. On driver source, the general practice is to first check the model-specific driver on the laptop vendor support page, and then compare the chip vendor generic driver and the generic driver automatically matched by Windows Update, comparing versions and update logs. Individual models may be the opposite, for example a vendor that has not updated a driver for a long time, where a newer chip vendor version instead fixes the problem, so each machine must be judged by the version and update log on that model support page, and the priority order must not be treated as an iron rule, as noted in the unverified list at the end.
On registry filter residue, UpperFilters and LowerFilters are Windows device class registry values used to attach filter drivers, for example filter drivers left behind by burning software, encryption software, virtual disc software, or older storage tools after installation. When the original software is removed but the filter value remains, Windows may fail to start a device or make it disappear when loading the driver stack, because it cannot find the corresponding filter driver. An official support document lists the standard steps for deleting filter values: enter the device class registry key, delete UpperFilters first, then delete LowerFilters, and then restart. A guide also stresses that the registry must be backed up before deleting, and that software that originally depended on that filter may need to be reinstalled after deletion. The correct advanced understanding and its limits are as follows. The class identifier given as an example in the official document is the optical drive class example, and it cannot be applied directly to an SD reader. The class identifier involved for an SD reader is different, and the class must first be confirmed in the device properties in Device Manager, and then matched against the registry value for that class. Blindly deleting the optical drive class value will not fix a reader. A filter value is not something to delete on sight. Only when the value points to a filter driver file that no longer exists, or when that value appears together with a driver stack error, does deletion become targeted. Indiscriminate deletion may disable other healthy devices at the same time. The practical order is to back up the registry first, export the affected class key, record the original value content, meaning which filter driver name it names, disable the related software or uninstall it first, and then consider deleting the residue value, and verify one by one after restarting. That order itself is a requirement of data safety and reversibility.
On group policy, BitLocker, and device encryption, if the machine is a company machine or a school machine, or has ever joined a domain or device management system, and the reader looks normal in hardware, normal in driver, and normal in Disk Management, but File Explorer refuses writing or even refuses reading, the policy layer is highly likely, not a broken card. On removable storage access policy, an official document in the BitLocker settings reference states plainly that when BitLocker removable drive settings are enabled, three policies under removable storage access must be disabled, including all removable storage classes deny all access, removable disks deny write access, and removable disks deny read access, because otherwise the two sets of policies fight each other. On denying write access to removable drives not protected by BitLocker, the policy path is under computer configuration, administrative templates, Windows components, BitLocker drive encryption, and removable data drives. Once enabled, an unencrypted SD card becomes read-only, and Windows File Explorer shows a lock icon and a write protection prompt. That phenomenon is easily misdiagnosed as a card lock switch that has been moved, or as a broken card. Another face of device encryption is that if the card itself was once encrypted with BitLocker To Go on another machine, and is moved to a new machine without a password or recovery key, Windows will ask for unlocking, and that is not a card that cannot be read. At that point, formatting, repair, and rebuilding partitions are all in the wrong direction, and they will damage the rescue possibility for encrypted data. The correct triage is to first confirm whether the card is in an encrypted state, and then deal with the key problem. A blind spot of the home edition is that a home edition without a local group policy editor does not mean that no policy exists. Policies delivered by a company or school through device management can affect other editions too. A personal user whose machine was once a company machine, or who once signed in with a school account, should also list the policy layer as a suspect. The specific residual path for an individual home machine varies with account history and needs checking machine by machine, as noted in the unverified list.
Disk Management three states and drive letter conflicts
Disk Management has three states, and they must never be confused with one another. Not initialised means that Windows recognises a disk device, but cannot read a valid partition table, or the partition table is damaged beyond recognition. An official troubleshooting document notes that an offline or missing dynamic disk may appear because of damage or intermittent unavailability, and handling includes checking physical connections, controller and disk health, and then using reactivate disk to bring it back online. Offline means that the disk device itself is marked offline by Windows, for reasons that can include policy, disk signature conflict, for example a copy image of the same card connected at the same time, storage area network policy, or having previously been set offline manually. Offline does not mean no media, and does not mean damaged. Right-clicking to bring it online may restore it at once. But if the offline reason is a signature conflict, forcing it online may cause another disk to fail, so the target disk must first be confirmed. No media means that Disk Management shows a disk capacity of zero and a state of no media, which usually means that the reader recognises the controller, but cannot read the flash memory of the card itself: the card controller does not respond, the card is internally damaged, the adapter contact layer is broken, or the reader only recognises an empty slot. A guide also notes that when a disk tool shows no media, zero bytes, or input and output errors, the problem is more likely at the hardware, enclosure, or controller layer. The three must never be mixed: not initialised can be a logic problem, meaning a broken partition table; offline can be a management state problem; no media is mostly a physical or controller layer problem. For a card with important data, the most dangerous action for a not initialised disk is to press initialise disk at once, because initialising writes a new partition table, overwriting the original partition information, and making later rescue harder.
| Disk Management state | Meaning | Most common layer | Most dangerous action |
|---|---|---|---|
| Not initialised | Disk device recognised, no valid partition table readable | Partition table layer, logic layer | Pressing initialise disk at once |
| Offline | Device marked offline, not necessarily damaged | Policy, signature conflict, management state | Forcing online without confirming the target |
| No media | Controller recognised, flash memory unreadable | Controller, contact, hardware layer | Repeated power-on and repeated formatting tests |
| RAW volume | File system type unrecognised | File system metadata damage, encryption not unlocked, another system file system | Formatting at once, running repair at once |
| Healthy but invisible in File Explorer | Volume healthy, letter or policy layer stopped | Letter conflict, policy, encryption | Assuming that the card is dead and throwing it away |
On the volume layer, partition table damage must distinguish MBR from GPT. The standard practice for SD cards at factory and camera formatting is mostly an MBR partition table plus a single partition. GPT is not the norm on an SD card. If a camera card suddenly becomes GPT, or the partition table shows several unexplained partitions, it is highly likely that it was once written by another system, for example a system installation tool, or that the first sector of the partition table is damaged. The clean command of a disk tool clears partition settings, after which converting the partition table, creating a primary partition, formatting, and assigning a letter form a rebuilding flow. But a guide also states plainly that clean clears all previous data, and backup must come first. The advanced principle is that partition table damage does not mean a dead card. If the card capacity in Disk Management shows correctly, and there is no repeated input and output error, partition table damage mostly belongs to the logic layer, and can be handled by making a read-only image first and then trying to rebuild on the image. If capacity jumps, comes and goes, or imaging keeps producing errors, work should stop. Another system layer trap is that Windows quick formatting only rewrites file system metadata, and does not check the whole card flash memory. Full formatting takes longer, but for a suspected damaged card, formatting itself is a write action, and with important data it must never be formatting first and rescue later.
On the RAW file system, File Explorer or Disk Management showing RAW means that Windows does not recognise the file system type of that volume, for reasons that can include file system metadata damage, for example an exFAT boot sector or a FAT file allocation table; a volume that is another system file system which Windows natively does not know; an encrypted volume that has not been unlocked; or a partition table pointing to a wrong sector range. RAW does not mean no files, and does not mean that formatting is required. The correct order is always to make a read-only image first, judge the file system on the image, carry out file rescue if needed, and only rebuild the file system after data is safe. Running repair directly on the original card may cause secondary writes on an unstable card.
Write protection: four causes, completely different solutions
Write protection has four completely different causes, and confusing them wastes a great deal of time, and may even damage data. The first is a card-side lock switch locked: the plastic slider on the side of an SD card or adapter has been pushed to the lock position, and the detection pin inside the slot senses it. It only affects that card or that adapter, and changing to another card restores normality. The solution is to push the slider back to the unlock position, and to check whether the slider is loose or inaccurately positioned. The second is a reader write protection detection pin failure: the microswitch or spring arm inside the slot that detects the lock switch is damaged, deformed, or stuck. Every card inserted into that slot reports write protection, while the same card can be written on another reader. The solution is to send the slot or reader module for inspection and replacement, and not to use a folk remedy such as taping over the slider position for a long time, because it may leave adhesive residue inside the slot. The third is a card controller permanent read-only lock: the controller, because of flash wear or too many bad blocks, locks itself to read-only automatically to protect existing data. Every reader and every computer reports write protection. Data can be read but cannot be written, deleted, or formatted. The solution is to back up readable data at once and replace the card. There is no software solution. The fourth is a system policy or read-only attribute: a Windows registry write protection value, a group policy refusal of writing, or a disk read-only attribute. It only affects that computer, that user, or that disk attribute, and changing to another computer restores normality. The solution is to check the registry and group policy, and to clear the read-only attribute with a disk tool, but the correct disk must be selected.
| Cause | Mechanism | Key signature | Solution direction |
|---|---|---|---|
| Card-side lock switch locked | Plastic slider pushed to lock position, slot detection pin senses it | Only that card or adapter affected, changing cards restores normality | Push back to unlock, check for a loose slider |
| Detection pin failure | Microswitch or spring arm inside the slot damaged, deformed, or stuck | Every card in that slot reports write protection, another reader can write | Send for slot or reader module replacement |
| Controller permanent read-only lock | Controller locks to read-only because of wear or too many bad blocks | Every reader and every computer reports write protection, readable but not writable | Back up readable data at once, replace the card |
| System policy or read-only attribute | Registry write protection value, group policy refusal, disk read-only attribute | Only that computer or user affected, changing computers restores normality | Check registry and group policy, clear read-only attribute, selecting the correct disk is essential |
On system policy and read-only attributes, a Windows registry write protection value set to one value makes USB devices write protected, and changing it to another value and restarting can restore writing. On group policy, a company computer or school computer may set a policy to refuse writing to removable storage devices through group policy. At that point, even if the registry value is correct and the card itself is normal, writing is still protected. In that situation the user should not bypass company policy on their own, and should ask the information technology administrator. On a disk tool read-only attribute, a disk tool can clear the read-only attribute of a disk, but a guide warns that this command only changes a software setting, and cannot override a physical lock, an organisation-managed refusal of writing policy, or a hardware fault. A serious warning applies: before using a disk tool, the disk number selected must be confirmed again and again to be the SD card disk number, not the system hard drive or an external hard drive. Clearing a read-only attribute or running clean on the wrong disk causes irreversible data loss. For any card with important data, a read-only image should be made first, before considering any disk tool operation.
The write protection diagnostic flow is as follows. First, check the lock switch position of the card or adapter, and try another adapter that is known to be good. That step is essential for microSD users. Second, try the same card on another reader and another computer, to judge whether the problem is the card, the slot, or the computer. Third, if write protection only happens on one computer, check the registry, group policy, and disk read-only attribute. Fourth, if write protection happens on every computer and every reader, and the card is readable but not writable, suspect a controller permanent read-only lock, back up at once, and replace the card. Fifth, if every card in one slot reports write protection, suspect a detection pin failure, send it for inspection, and do not hold it together long term with a folk remedy.
File system trade-offs and camera-specific structures
The capacity standard ties file systems to card types, and that mapping is the key to understanding many cases of a card that has been formatted, yet the camera still says that it is not supported. FAT32 has the widest compatibility. Older cameras, older devices, and many embedded devices know it. Its disadvantages are a single file limit and the fact that the Windows graphical formatting interface usually does not offer a FAT32 option for larger cards. exFAT is designed for flash memory, with an extremely large single file limit, suitable for high-resolution video recording and large file transfer. Its cost is that it has no journaling and no file permissions, so a sudden power cut or direct removal of the card more easily leaves an inconsistent state. NTFS is the most complete Windows native system, with journaling, permissions, and shadow copies, but cameras, many playback devices, and macOS, which natively reads NTFS only and needs a third-party driver for writing, are not suitable for using NTFS as a camera card. The practical conclusion is that a camera card should follow the camera vendor format, a general computer card should follow exFAT for large cards or FAT32 for small cards and older devices, NTFS should not be used as a camera card, and a card that will go back into a camera should not be formatted on a computer as NTFS for the sake of speed.
| File system | Compatibility | Single file limit | Journaling and permissions | Suitable use |
|---|---|---|---|---|
| FAT32 | Widest, older devices know it | Has a 4 GB limit | No journaling, limited permissions | Small cards, older devices, compatibility first |
| exFAT | Mainstream for modern computers and cameras | Extremely large, suitable for large files | No journaling, no permissions, safe removal required before removal | Large cards, video recording, large file transfer |
| NTFS | Most complete Windows native, macOS natively read-only | Extremely large | Has journaling, permissions, shadow copies | Windows-only disks, not suitable as a camera card |
| APFS | macOS native, Windows and cameras do not know it | Extremely large | macOS-specific features | macOS-only disks, not suitable as a camera card |
On the 4 GB single file limit, the FAT32 single file ceiling sits near 4 GB. That limit is often misdiagnosed as three different errors. First, a card is said to be broken because copying a large video fails halfway, when in fact a FAT32 card copying a single video file over the limit receives a system report that the file is too large for the destination file system. Solutions in a comparison include changing to exFAT or NTFS, converting the file system, splitting the file, or using another transfer method. Second, a camera that stops recording halfway may be explained by a FAT32 card, where camera firmware usually splits recording automatically, while a card formatted on a computer as NTFS or another format and put back into the camera may refuse continuous recording or ask for reformatting. Third, a card that reports no space even though space remains may be explained by remaining space distributed in fragments, or by a file system cluster configuration problem, so that writing a single file fails because of insufficient contiguous space, looking like a full card, when in fact it is a file system layer problem, not flash memory exhaustion. The diagnostic point is to look at the card file system first, and then at whether the failing file size sits just near the limit. If the failure point is at the same file size threshold every time, it is a file system limit, not card speed, not a reader, and not a USB bottleneck.
On the macOS layer, not visible does not mean not recognised. macOS has two display switches, and switching off either one makes a card that is already mounted invisible in Finder: a Finder settings general option for external disks decides desktop display, and a Finder settings sidebar option under locations for external disks decides sidebar display. Several guides list both items as the first checks. The advanced implication is that when a user says that a Mac cannot read a card, the first question should be whether Disk Utility can see it, not whether Finder can see it. Different answers to those two questions point to completely different layers. The distinction between mounted and not mounted in Disk Utility also matters greatly. Seeing a disk, but with a volume greyed out and not mounted, means that the system recognises the card and its partition at the device layer, but refuses mounting at the file system layer, or mounting has been paused manually or automatically. The mount button in Disk Utility targets that state. If the mount button does nothing, or mounting pops out again at once, file system damage, encryption not unlocked, or reader power or signal instability should be suspected. If Disk Utility cannot see it at all, but System Information can see the reader, that means that the device layer responds, but the disk layer has not been established, possibly because the card controller does not respond, the partition table is damaged beyond establishing a disk device node, or there is a reader firmware or driver layer problem. If System Information cannot see it either, that means that the USB or Thunderbolt layer, the reader itself, or the accessory approval layer has already stopped, and no more time should be wasted at the file system layer. The repair function of Disk Utility also has an order limit: several guides warn that if a card holds files that have not been backed up, files should be copied or rescued first, before running repair or formatting, because both rewrite card content and may make rescue harder.
On the APFS versus exFAT choice error, APFS is macOS native, suitable for built-in solid-state drives and macOS-only external disks, but cameras, Windows computers, and many playback devices do not know APFS. Formatting a card that will go back into a camera as APFS means that a computer may read it, but the camera certainly cannot. exFAT is cross-platform and suitable for large SDXC cards. In macOS Disk Utility format options, smaller capacities use MS-DOS, meaning FAT, and larger capacities use exFAT, which is the practical dividing line in guides. MS-DOS in Disk Utility is the label for FAT32. For larger cards, the Disk Utility graphical interface may hide the MS-DOS option, and a terminal command must be used to force it, which is precisely the system layer reason for a user who wants FAT32 but finds no option in the interface. On NTFS, macOS natively reads only, and writing needs a third-party driver. An NTFS card on a Mac that can be seen but not written to is not a broken card and not a broken reader. It is a native limit of the file system driver layer. That situation is especially common in cross-platform workflows: Windows formats as NTFS, the Mac can only read, and the user thinks that the Mac reader is faulty.
On the effect of system integrity protection on third-party drivers, the effect must be discussed separately, and cannot be generalised. A built-in SDXC slot and a standard USB mass storage reader usually use built-in system drivers, need no third-party kernel extension, and are not directly affected by the protection mechanism. Individual older readers, older USB expansion cards, or readers needing a vendor-specific driver may depend on a third-party kernel extension on an older system. After a system upgrade or a protection setting change, that driver may fail to load, showing up as a reader that disappears. The correct advanced attitude is not to switch off system integrity protection casually for one SD card. Switching it off lowers whole-system integrity protection, and if the problem remains after switching it off, the cause was never the protection mechanism in the first place. The correct order is to first confirm whether the reader really needs a third-party driver, using vendor documents and system report driver information, and then to consider a driver update or replacement with a standard mass storage reader. Differences between machine generations, in built-in slot availability, accessory approval, and the applicable scope of older troubleshooting commands, must also be discussed separately. A built-in SDXC slot only appears on particular models, while other models need an external USB reader, so it must first be confirmed whether the machine itself has a built-in slot, rather than assuming that a particular laptop must have a slot. When a new USB accessory is connected on a newer system, the system may ask the user for approval, and the new reader must be approved, with settings viewable under system settings privacy and security accessories. Older reset procedures cannot be applied directly to newer architecture models, and accessory approval, Finder settings, Disk Utility, the reader, and the card itself should be checked first.
Speed diagnosis in four layers: card slow, reader slow, bus slow, or file system slow
On the correct reading of test tools, a Windows speed tool sequential figure represents large files and continuous sectors, while a random small file figure represents random small file reading and writing. A guide notes that a single queue, single thread sequential speed is close to everyday single large file transfer, while a multi-queue random small file figure reflects performance under multitasking pressure. A macOS speed tool designed for video workflows focuses on whether continuous reading and writing can cope with a particular codec and frame rate, rather than random small file performance. A guide notes that the limitation of that tool is that it only focuses on continuous reading and writing, and does not measure random reading and writing, so it cannot fully reflect everyday system responsiveness. A Linux raw device tool can measure continuous reading and writing of a raw device, but has no file system layer meaning, while a rescue tool strength lies in handling read errors, having a log, and being resumable, making it suitable for imaging a faulty card, rather than for a speed contest.
| Test combination | If speed clearly rises | Conclusion pointed to |
|---|---|---|
| Same card, same reader, change machine port | Rises | Bus or port bottleneck |
| Same card, same port, change reader | Rises | Reader bottleneck |
| Same reader, same port, change to another card known to be good | Rises | Original card itself slow or worn |
| Same card, same reader, same port, change file system | Rises | File system layer or fragmentation problem |
| All of the above changed, no rise | No rise | Laptop USB controller, power policy, background program load, or card and reader limited at the same time |
On write cache and safe removal, a Windows disk drive properties policy page has two options. Quick removal disables write cache, so writes reach the card as soon as possible, removal risk is lower, but write speed is slightly slower. Better performance enables write cache, so write speed is faster, but safe removal must be used before removing the card, because otherwise data in the cache may not have reached the card. A discussion notes that NTFS drives, because of journaling, write cache, and File Explorer holding control codes, more often refuse safe ejection, and changing to the quick removal policy can reduce ejection problems, but write speed will fall slightly. The advanced implication is that the saying that removing a card at once after copying damages the card is not a superstition. If the policy is better performance and safe removal has not been used, data in the cache and file system metadata may not have been written, and removal leaves an inconsistent file system, so that the next insertion shows RAW or asks for repair. The case of a copy that looks finished, with the progress bar complete, but with files missing, may mean that the cache has not been flushed, or that a File Explorer thumbnail or indexing program still holds the file, and forcibly removing the card when safe removal is refused causes the problem. When testing speed, the removal policy at the time must be noted. Figures under better performance look better, but do not represent the true everyday experience under quick removal.
On fake card speed test signatures, a fake card marked speed may also be faked, with a marked peak speed far above its sustained speed. The speed signature of a fake card is that the first segment, within the true capacity range, runs at normal speed, or even very fast. Once the true capacity boundary is crossed, speed falls off a cliff, write errors explode, and read-back data is damaged. The capacity display differs each time, or shows different capacities on different devices. Testing must use an empty card or a card that has been backed up, because full card write verification is itself a destructive test, and cannot be used on a card with important data. On the USB 2.0 bottleneck, the marked speed of USB 2.0 converts to about 60 MB per second, but that is a signal speed, not a file copy speed. Protocol overhead, half duplex communication, and host polling all eat bandwidth. A technical discussion notes that the theoretical transfer rate of USB 2.0 converts to that figure, but the actual transfer rate seems limited to the thirties of MB per second, for reasons including protocol overhead and time slice reservation of the USB protocol. A guide also notes that the USB 2.0 high-speed signal converts to about 60 MB per second before protocol overhead, that a figure of about 40 MB per second at most is a rough practical estimate, not a specification figure, and that actual transfer will be lower still. Another throughput analysis notes that the actual highest speed for bulk transfer, covering file copying, external disks, and flash storage, is about 35 to 40 MB per second, for reasons including packet and protocol overhead, half duplex, host polling, and device and driver limits. The advanced implication is that a card marked as high speed, measured through a USB 2.0 reader at a figure in the thirties of MB per second, is not necessarily a slow card or a broken reader. It may already be close to the practical USB 2.0 ceiling. The only way to judge the bottleneck is to fix other variables and change one by one: the same card, then a USB 3.x reader, then a machine USB 3.x port, and then measure again. If speed jumps at once, the bottleneck lies in the bus or reader. If speed does not change, the bottleneck lies in the card itself or the file system. The shape of a port does not equal its speed: a USB-C port can run a USB 2.0 protocol, and a blue USB-A port does not guarantee USB 3.x. The connection speed description in System Information or Device Manager must be used, not colour or shape.
The data safety red line: read-only imaging first
This section is not a suggestion. It is a hard line for advanced diagnosis. Violating it may turn data that could have been rescued into data that cannot be rescued. Things that must never be done first on a faulty card include the following. Do not format a faulty card. Formatting rewrites the file system structure, and makes file records that rescue software might have recovered disappear. Even if the system pops up a message that formatting is needed before use, formatting must not be pressed at once. Do not run a repair tool in repair mode on a faulty card. Repair mode writes to the card and changes file system metadata, and may repair a damaged structure into a state even harder to rescue. A guide states plainly that before running clean, deleting a volume, or repair, readable files must first be copied to another hard drive. Do not write a new file onto a faulty card as a test, including trying to write a small file to see whether writing works, or using a capacity test tool to write the card full for verification. Those writes may overwrite old data that has not yet been rescued. A capacity verification tool can only be used on an empty card or a card that has been backed up. Do not repeatedly insert and remove, or repeatedly power on, a card as a stress test. For a card with controller damage or severe flash wear, every power-on and retry may worsen its state. With important data, power-on times should be minimised, and the read-only imaging procedure should be entered directly.
The correct order for the read-only imaging first principle is as follows. First, stop writing. As soon as a card shows an abnormality, including file damage, capacity abnormality, repeated disconnection, or write protection, stop writing any data to the card at once, and eject safely, rather than pulling it out during transfer. Second, read read-only. Use a standalone reader to read the card, and as far as possible make the whole card into an image file in a read-only way, for example using a disk imaging tool to copy the whole card sector by sector to an image file on another hard drive. During imaging, if a read error is met, the tool should record the error position and continue, rather than stopping or retrying the same position repeatedly. Third, work on the image file. All later file system repair, file rescue, and partition table rebuilding must be done on a copy of the image file, not directly on the original card. Even if repair fails, the image file of the original card remains, and another method can be tried again. Fourth, double backup. Files successfully read out should be copied to two different locations, for example a computer hard drive plus an external hard drive, and only after confirming that the files can be opened normally should the original card be handled, including formatting, replacement, or repair. Fifth, when to send directly for professional rescue. If the card is completely unrecognised, shows no media, drops repeatedly so that imaging cannot be completed, or shows abnormal sound, smell, or heat, self-attempts should stop, and the card should go directly for professional data rescue assessment. Repeated self-attempts may make the controller fail completely, so that professional rescue also becomes impossible.
On imaging tools and methods, at the concept level, a rescue tool should first make a fast first pass without retries, rescuing the easily readable parts as soon as possible, rather than torturing a faulty area with retries from the start. Afterwards, a log file can be used to resume and retry bad areas. After imaging, the image can be mounted read-only in a loop, and important files can then be copied. On Windows or macOS read-only adapters, hardware write protection adapters on the market can block write commands at the physical layer. Without a hardware adapter, at least the system layer should mount read-only, or before imaging the system should not be allowed to mount automatically and write metadata, for example automatic playback and search indexing may write. On the correct use of a write protection switch, a full-size SD card side write protection switch, when moved to the locked position, should make a standard reader refuse writing. But that switch itself is only a mechanical switch, and the reader must know to respect it before it takes effect. A microSD card itself has no write protection switch, and must rely on the adapter switch. If the adapter switch is loose, worn, or moved by mistake, write protection may fail, and the card cannot be assumed to be read-only merely because of the switch. Imaging failure itself is a diagnosis. If during imaging the error rate keeps rising, speed keeps falling, and capacity display jumps, that means that the card flash memory or controller is already unstable, and work should stop and the card should be sent for inspection, rather than changing to another tool and running again.
A special reminder for camera users is that a photographer work card is often the only copy of that day shooting, not yet backed up, and its value is far higher than the card itself. When a card shows an abnormality on a shoot, the safest action is to change to another card at once and keep shooting, to store the abnormal card properly, marked as faulty and not to be formatted, and after returning home to image first and then handle it. Do not use the camera formatting function on site to try to fix it. Camera formatting differs from computer formatting. Camera formatting usually rebuilds structure according to the camera file system preference, which may differ from computer expectation. Before rescue, do not format an abnormal card with a camera. Build a habit: after every shoot, first copy the card contents to a computer and confirm that the files can be opened, and then format the card for next use. Do not treat a card as long-term storage. A card is a shooting medium, not a backup.
Stop signals are as follows, and any one of them means stopping. Repeated input and output errors, where the same sector range repeatedly fails to read, and error messages keep repeating, not a one-off event. Capacity jumping, where the same card shows different capacities on different insertions or different devices, or capacity suddenly changes from large to small, or from small to large. Overheating, where the card or reader becomes abnormally hot in a short time, hot to the touch, or smells burnt. Overheating may mean a controller short circuit or flash abnormality, and continued power may expand the damage. Imaging progress stalling or going backwards, where rescued capacity stays still for a long time, error areas keep expanding, or every retry makes more areas become bad areas. Physical damage to the card body, including broken gold fingers, a cracked card body, bending, or powering on after water entry before thorough drying. An encrypted card without a key, where a BitLocker or other encrypted card has no password or recovery key, and any formatting, partition rebuilding, or repair attempt will damage the rescue possibility, so the key problem should be handled first. When any stop signal above appears, the correct action is to power off, seal the original card, record the fault phenomenon, including which machine, which reader, which error message, and which capacity display, and then hand it over for diagnostic handling. SD-related diagnostic and repair costs are always subject to a written quotation after diagnostic, and the general direction of pricing can be seen on the pricing page, but an SD item itself will not be priced in advance on the pricing page. Everything is subject to a written quotation after diagnostic.
Common misdiagnoses and traps
| Misdiagnosis | Appearance | Truth | How to tell |
|---|---|---|---|
| Reader bottleneck treated as a broken card | New high-speed card only runs in the twenties of MB/s on an older reader | Reader USB version or SD bus support is itself the ceiling | Change to a reader clearly supporting the corresponding grade, plug directly into a machine port, and test again |
| Fake card treated as a broken reader | Card starts damaging files after a certain amount is written, capacity display looks normal but files cannot be opened, same on several readers | Fake card controller lies about capacity, and after the true capacity is exceeded it starts overwriting old data | On an empty card only, use full-write verification. If verification reveals a true capacity far below the labelled capacity, it is a fake card |
| File system problem treated as hardware failure | SDXC card unrecognised on an older device or older system, or asking for formatting | Older device has no exFAT driver, or older reader only supports SDHC | Is the same card normal on a new computer and a new reader. Check the older device official specification |
| Camera direct connection PTP or MTP not showing files treated as a broken card | Camera connected by USB cable to a computer, no files visible or only some files visible | In PTP or MTP mode, the computer can only browse media objects that the camera is willing to show | Take the card out and read it once with a standalone reader. Check the camera USB mode |
| Windows FAT32 limit treated as card shrinkage | Formatting options have no FAT32, or a card only shows 32 GB after formatting | Windows built-in tool human-imposed limit, and a partition made smaller leaves the rest as unallocated space | Open Disk Management and look at physical capacity and unallocated space |
| Poor contact treated as controller failure | Card reads sometimes and not others, drops when moved | Contact oxidation, spring fatigue, slot deformation, or a loose adapter can all cause intermittent failure | Cross-testing plus response to pressing lightly or changing insertion depth |
| Detection pin failure treated as card locking | Every card in the same slot reports write protection | Slot write protection detection pin damaged, so the slot misjudges every card as locked | If the same card can be written on another reader, it is a slot detection pin problem |
| Speed drop treated as card ageing, or thermal throttling treated as permanent damage | Card becomes slower after a period of use, or speed falls after long transfer | Speed drop may only be a second-row failure falling back to a lower mode, a reader bottleneck, thermal throttling, or cache filling | Does speed return after cooling, after changing readers, or after changing computers |
| Partition table damage treated as controller damage, or the reverse | Card shows RAW and asks for formatting, assumed to be a dead controller to be thrown away at once. Or a card shows no media and zero bytes, assumed to be only a partition table problem, with formatting tried repeatedly | The two look similar but are handled completely differently. With partition table damage, physical capacity is roughly correct. With controller damage, physical capacity is abnormal or drops repeatedly | Physical capacity and stability in Disk Management are the key dividing line. With important data, always image read-only first |
| Letter conflict treated as a broken card | Disk Management sees the card, capacity correct, state healthy, but File Explorer has no drive | A mapped network drive has taken the letter | Disconnecting the network mapping restores normality at once. Changing the letter restores normality at once |
| Group policy or encryption treated as a broken card | Card becomes read-only, or asks for encryption, mistaken for a lock switch or a broken card controller | Same card normal on a personal laptop, read-only on a company machine. Policy path and encryption state explain it | Check the policy path, encryption state, and compare by changing computers |
| Finder display setting treated as a broken card | Mac user says a card is missing, while Disk Utility sees it and reports it as mounted | Finder has simply not ticked external disks | Disk Utility sees it, and changing Finder settings makes it appear at once |
| Reinstalling a driver treated as a universal solution | Same driver reinstalled repeatedly, but the problem lies in the power layer, registry filter layer, or the division of labour between reader chip and host controller | Driver version, date, and vendor completely unchanged, but the fault only appears after waking from sleep or after idleness | Record a driver version timeline, and compare the power layer and registry layer |
| Formatting treated as repair | Seeing RAW or not initialised and formatting at once | Before formatting, no read-only image was made. After formatting, file rescue becomes much harder | With important data, image first. Only consider formatting after data is safe |
| Large file copy failure on FAT32 treated as a full or broken card | FAT32 card fails to copy a single file over the limit | File system single file limit | Failure point sits near the limit every time. After changing to exFAT, the same file can be copied |
| Camera asking for formatting treated as card damage | Card formatted on a computer put back into a camera, camera asks for reformatting | Camera expected directory structure or file system does not match | Reformatting inside the camera restores normality at once. Computer formatting did not follow the camera vendor format |
| Fake card treated as card ageing | Capacity jumping, fast first segment then a cliff, damage after a certain capacity is written | Expanded-capacity fake card, not normal wear | Full-write verification shows a true capacity far below the labelled capacity |
Repair, replacement, and upgrade decision framework
Before a decision, three answers must be available. First, which layer has the problem been located to? Card, adapter, reader, built-in slot, main board or platform controller, operating system or policy. Without location, no decision should be made about what to replace. Second, has card data been safely backed up? With important data not yet backed up, the decision order is rescue first and repair later, and data must not be sacrificed for repair. Third, what is the actual user need? Only occasional photo transfer, or daily large transfer of high-speed cards? Different needs justify completely different repair costs and upgrade directions.
| Option | Suitable situations | Unsuitable situations | Points to note |
|---|---|---|---|
| Replace the built-in reader module | Located as a built-in slot fault itself, for example springs, detection pins, daughter board, or ribbon cable, while other main board parts are normal. User values machine integrity and does not want a long-term external reader. Laptop model has a standalone reader daughter board that can be replaced | Slot is soldered directly to the main board, so replacement equals main board level repair. Laptop is already old, with low overall residual value. User rarely uses the built-in slot, and an external reader is already enough | Before replacement, confirm that the part model and laptop model match exactly. After replacement, test whether the grade has returned, not only whether a card can be read. If replacement involves main board desoldering, assess risk and warranty effect |
| Use an external USB reader to cover | Problem only in the built-in slot, while an external reader reads normally. User transfer frequency is low, or a high-speed external reader is already owned. Built-in slot repair cost is high or difficult. User is about to change machines, and major repair of an old machine is not worthwhile | User places extreme value on machine integrity and accepts no external attachment at all. USB ports are already long occupied by other devices, with no free port for a long-term reader | Usable at once, and a grade can be chosen according to need, as long as the host USB port supports it. When changing machines, the reader can be taken away and used again. USB power and selective suspend problems need extra attention |
| Change the main board, give up the built-in slot, or change machines | Located as a main board or platform controller host controller fault, not merely a slot or daughter board problem. Laptop has several other hardware problems at the same time, with low overall repair value. Laptop model built-in slot does not support the grade the user needs, and the upgrade need cannot be solved by changing the slot | Problem is actually only a slot or daughter board, and the decision jumps to main board level without location. User still needs the built-in slot, and the laptop overall value is high | Giving up the built-in slot does not mean giving up card reading. It only moves card reading to an external reader. When changing machines, the SD slot support grade should be listed as a machine selection condition, especially for photographers and users who transfer large amounts daily |
| Replace the card | Located as a card problem itself, same fault on changing readers and changing computers. Suspected fake card, keeping purchase proof for channel handling | Card holds important data not yet backed up, and the card is thrown away before imaging | Before using a new card, carry out empty-card capacity verification first. Before replacing a card, confirm that data has been safely backed up |
| Replace the adapter | Located as an adapter problem | Adapter judged broken without a direct insertion comparison | An adapter is the cheapest and fastest repair, and a direct insertion comparison should be done first |
| Keep pursuing the system layer | Letter conflict, selective suspend, fast startup residue, driver rollback, registry filter residue, policy setting error, display setting, mounting state, file system choice error, or camera USB mode error. These have a clear system layer mechanism, and repair cost is low and reversible | Four-layer speed testing completed, all combinations show no improvement, and the fault phenomenon reproduces stably. All system layer methods tried, fault still present. Card itself already shows stop signals. User time cost already exceeds replacement cost | Each system layer change must be followed by one comparison test. Do not change all settings at once, because then it is unknown which change was effective |
When is it no longer worthwhile to keep pursuing the system layer? When any of the following appears, the marginal benefit of continuing at the system layer is already extremely low, and work should stop and turn to diagnostic handling or replacement. Four-layer speed testing has been completed, all combinations show no improvement, and the fault phenomenon reproduces stably. Driver rollback, power settings, fast startup, registry filters, group policy, letters, file systems, and camera modes, all system layer methods, have been tried, and the fault still exists. The card itself already shows stop signals, including capacity jumping, repeated input and output errors, or overheating, and further system layer pursuit only adds writes and power-on times, making rescue harder. The user time cost already exceeds replacement cost, for example a photographer facing an imminent submission deadline, or a student facing an imminent assignment deadline, where continuing to try system settings one by one will cause delay, and the work should first be completed with a card and reader known to be good, before returning to the faulty card. A combination of an older system plus an older reader plus a newer large card already exceeds vendor support scope, and the system layer cannot break through a hardware support ceiling by settings alone.
On pricing and diagnostic, SD reader related diagnostic and repair are always subject to a written quotation after diagnostic. This article writes no specific SD repair price. For the general direction of pricing pages, see pricing. To arrange diagnostic, see diagnostic. An SD item is finally always subject to a written quotation after diagnostic, and the pricing page does not replace an individual diagnostic result. For clarity, other repair starting prices already confirmed on this site, for example battery from HK$580, screen from HK$1,280, main board chip-level from HK$880, and keyboard from HK$480, have nothing to do with SD readers. They are only stated to show the principle that prices are only written for confirmed items, while SD readers remain always subject to a written quotation after diagnostic.
Hong Kong situations: humidity, commuting, photographers, and outdoor cards
The high humidity environment in Hong Kong is long-term pressure on the contact layer and on the inside of card slots. Spring humidity returning, the rainy season, and condensation caused by temperature differences between air-conditioned rooms and the outdoors, keep slot contact surfaces in a humid state for a long time, speeding up oxidation and dirt accumulation. Practical suggestion directions, without involving specific product recommendations, are as follows. When a card is not in use, it should be stored in a dry, dust-proof card case, and not left inserted in a slot for a long time. When bringing a card and camera from an air-conditioned room outdoors for shooting, allow the card and camera some time to adapt to temperature before inserting and removing. After contact with water or sweat, dry first before inserting into a slot. Regularly check whether card gold fingers show dull patches or spots. A card that has become damp should not be powered on for testing at once. It should first rest in a dry environment, and its gold fingers should be checked for water marks or oxidation traces. A card that has already become damp and then powered on may see its fault expand from the contact layer to the controller layer. This must be stated clearly: the link between humidity and poor contact is a reasonable inference, but the quantified effect of humidity on oxidation is unverified, and this article writes no humidity threshold or oxidation time figures, as listed in the unverified list at the end.
On commuting vibration and insertion frequency, Hong Kong users commonly commute with laptop bags and camera bags, and cards left inserted in slots under vibration suffer micro-motion wear of the contact layer faster than use fixed on a desk. Photographers, journalists, and event shooters who insert and remove cards several times a day also suffer spring fatigue and card body wear faster. When commuting, if not necessary, a card can be taken out and put into a card case, reducing vibration inside the slot. When inserting and removing, push and pull straight along the slot direction, rather than inserting at an angle or forcing it in. A card case should have dividers, to prevent several cards from scratching each other gold fingers. When copying a card on a laptop during commuting, the laptop mostly runs on battery mode, where the power policy is more conservative, and USB selective suspend is more easily triggered. After returning to a company or home and plugging into mains power, normality returns, and that contrast itself is a diagnostic clue for the power layer. When students submit assignments or office workers submit documents, they often use only one card, one reader, and one port, with no control group. Advanced investigation must first establish a control group, including another card known to be good, another reader, another port, and another machine, because otherwise it cannot be told whether the problem is the card, the reader, the port, or a system setting.
On special risks for photographers and outdoor users, cards used for hiking, outdoor work, seaside, and beach shooting face three enemies: dust, salt, and moisture. Sand entering a slot scratches contacts, salt speeds corrosion, and moisture raises contact resistance. Outdoor card faults are often not sudden breakage, but chronic damage from the combination of dust plus humidity plus vibration. High-speed cards commonly used by photographers demand more of the second row of contacts and signal integrity, so a slight contact layer problem first shows up as a speed drop, rather than complete failure to read. If a photographer finds that the same card shoots normally inside a camera, but transfer on a computer becomes slower, the reader and contact layer should be checked first, rather than suspecting the camera or the shooting capability of the card. On local buying, the price direction is broadly that cards and readers from original or authorised channels usually cost more than channels of unknown origin, but fake card risk and warranty support are also more assured. Abnormally low-priced cards carry a significantly higher fake or expanded-capacity card risk. This article writes no specific selling price, because selling prices vary with model, capacity, channel, and time, and a written figure would soon become outdated and misleading instead. Buying direction suggestions are as follows. For cards, buy from authorised dealers or reputable shops, keep packaging and purchase proof, and carry out capacity verification before using a new card, on an empty card only. For readers, look at USB speed and SD bus support at the same time, not only one of the two figures. A photographer using a high-speed card should choose a reader clearly marked as supporting the corresponding grade, because otherwise the speed advantage of a high-speed card cannot be used. For adapters, microSD users should choose an adapter with a solid structure and a lock switch that does not loosen easily, and prepare one spare adapter for cross-testing.
On the reality of older systems still in use, many Hong Kong users laptops still run older Windows or older macOS versions, for reasons including company software compatibility, older camera software that only supports older systems, or hardware upgrade limits. Effects of older systems include older host controller drivers that do not support new card speed grades or large capacity cards, older exFAT drivers with incomplete support for large cards, older macOS Finder and Disk Utility behaviour differing from newer versions, and older system USB power management defaults that are more aggressive. Advanced investigation must first record system version, driver version, and firmware version, and then compare them with the minimum support version on the vendor support page. It must not be assumed that the latest driver is necessarily the best, and it must not be assumed that an older system necessarily does not support a new card. Both must be verified with version figures. The specific version dividing line for older system support of new cards varies with system version, driver version, and firmware version, and this article lists no unified dividing line table. Each machine must be checked individually, as listed in the unverified list at the end.
Inspection checklist
When sending for inspection, bring the faulty card, the adapter normally used, the external reader normally used, the laptop itself, and the charger, to allow long testing. Provide the specific fault appearance in words: not recognised, not readable, dropping out, extremely slow, only half readable, or write protected. Provide how each path performs separately, including built-in, external, and camera direct connection. Provide whether every card behaves the same, whether only a particular file fails, and whether the fault only appears after idleness, on large files, or on movement. Provide whether the card holds important data not yet backed up. If yes, that must be stated first, so that read-only imaging can be arranged. Provide laptop brand, model, system version, driver version and date, and reader chip name. Provide card type, labelled capacity, actually shown capacity, file system, and whether it was ever formatted in a camera or another device. Provide a complete description of the fault phenomenon, including which error code, which Disk Management state, which port, which reader, which power state, including battery or mains power, after waking from sleep or on cold startup, and which file size fails first. Provide control group results already tried, including another card, another reader, another port, and another machine, and what each result was. Provide whether the card holds important data not yet backed up, whether it is encrypted, and what the write protection switch state is. Provide camera model, USB mode setting, and firmware version, if a camera direct connection is involved. Things not to do: before inspection, do not format a faulty card on your own, do not run repair, and do not use a capacity verification tool to fill a card that holds data. Shop information: Room 1209, Dali Plaza, Shek Mun, Sha Tin, telephone +852 2186 8010, WhatsApp +852 6558 6806, hours 12:00–19:00. SD-related matters are always subject to a written quotation after diagnostic. The pricing page gives only a general direction, and diagnostic results govern individual cases.
Frequently asked questions
Q1: After swapping the card, swapping the reader, and reinstalling the driver, the card still cannot be read. Does that mean that the card is dead?
A1: No. After swapping cards and readers, many layers remain unexcluded, including built-in slot ribbon cables or daughter boards, host controller driver layers, power management, registry filters, letter conflicts, policy or encryption, partition table damage, and controller damage. First look at where Device Manager, Disk Management, and File Explorer each stop, and then narrow down with control groups, rather than concluding from swapping alone that the card is dead.
Q2: An external reader can read the card, but the built-in slot cannot. Does that mean that the built-in slot is dead?
A2: Not necessarily dead, but the location is already very clear: the problem lies in the built-in slot segment, not in the card itself. Possible causes include a loose ribbon cable, daughter board solder joint problems, slot spring fatigue, detection pin problems, firmware power control, or driver layer problems. It must further be split into hardware versus driver or power problems, rather than jumping straight to a main board level conclusion.
Q3: A card can be read but is extremely slow. Does that mean that the card has aged?
A3: Not necessarily. Extremely slow speed is most often caused by a bus ceiling or a negotiation downgrade, including a reader that only supports a lower grade, a USB 2.0 bottleneck, a second-row contact failure falling back to a lower mode, a generic driver that does not support high-speed modes, rising contact resistance, thermal throttling, cache filling, or flash retries. Four-layer speed testing must be done, changing one variable at a time, before it can be told whether the card, the reader, the bus, or the file system is slow.
Q4: A card only shows half its capacity. Does that mean that the card has shrunk or is a fake card?
A4: Not necessarily. Showing only half capacity has at least five mechanisms, including a partition made smaller, an older reader that only supports a smaller capacity type, a missing file system driver, partition table damage, and a fake card. First look at the three figures in Disk Management, physical capacity, volume capacity, and unallocated space, and then compare across different readers. Do not conclude a fake card merely from half capacity, and do not conclude not a fake card merely from a complete capacity display.
Q5: How can a card be proven to be a fake card?
A5: The only reliable method is full-write and read-back verification on an empty card only, writing known test data across the whole labelled capacity, and then reading it all back for comparison. A genuine card completes testing with no errors, while a fake card reports many errors and reveals its true usable capacity. Looking only at system shown capacity, looking only at card markings, or doing only a short speed test all prove nothing about capacity, because the figure that a fake card fakes is precisely that number. The test itself is destructive, and must never be done on a card with important data.
Q6: A camera direct connection cannot see files. Does that mean that the files are gone?
A6: No. In PTP or MTP mode, a computer can only browse media objects that the camera is willing to show, and will not expose other files on the card. Taking the card out and reading it once with a standalone reader will very likely show all files present. The camera USB mode must also be checked for whether it is set to mass storage, and whether the photographs really exist on the card rather than in camera built-in memory.
Q7: Every card in the same slot reports write protection. Does that mean that every card is locked?
A7: No. That phenomenon points most strongly to a slot detection pin failure: a microswitch or spring arm inside the slot is damaged, so the slot misjudges every card as locked. The golden test is to change readers and change computers with the same card. If the card can be written on another reader, it is a slot detection pin problem. Only if every reader and every computer reports write protection should a card problem or a controller permanent read-only lock be suspected first.
Q8: A microSD card reports write protection, but a microSD card itself has no lock switch. Why?
A8: Because the problem is not in the microSD card itself, but in the adapter, the reader, or the controller. A microSD card usually has no physical lock, and write protection problems must be checked against the lock switch of the microSD-to-SD adapter, including a loose slider, inaccurate slider positioning, a reader detection pin failure, or a controller permanent read-only lock. Trying another adapter known to be good is an essential first step for microSD users.
Q9: Disk Management shows not initialised. Should initialise be pressed at once?
A9: No, especially when the card holds important data. Initialising writes a new partition table, overwriting original partition information, and making later rescue harder. The correct order is to image read-only first, and then judge the partition table and file system on the image. Only after data is safe should partition rebuilding be considered. Not initialised, offline, and no media mean completely different things, and must not be confused.
Q10: File Explorer cannot see a card, but Disk Management sees it and reports it as healthy. Does that mean that the card is broken?
A10: No. That combination points most strongly to a drive letter conflict, a group policy or encryption layer, or a display setting layer. Check whether the letter has been taken by a mapped network drive, check policy or encryption state, and check display settings. Changing the letter or correcting the policy will very likely restore normality at once. Do not assume that the card is dead and throw it away.
Q11: After a period of idleness, a card disappears, and only returns after removal and reinsertion. Does that mean that the reader is broken?
A11: Not necessarily. A time pattern points to the power layer first: USB selective suspend, root hub power management, and power reset after waking from sleep can all cause disappearance after idleness. First carry out a power layer comparison test: does disappearance stop after selective suspend is disabled? If disconnection still happens after disabling, the problem narrows to cable, bridge chip, insufficient power, or driver. After testing, settings should be restored to their original state, and power saving features should not be left disabled for a long time.
Q12: Measuring through a USB 2.0 reader gives a figure in the thirties of MB per second. Does that mean that the card is slow?
A12: Not necessarily. That figure may already be close to the practical USB 2.0 ceiling, because protocol overhead, half duplex, and host polling all eat bandwidth. The way to judge the bottleneck is to fix other variables and change one by one: the same card, then a USB 3.x reader, then a machine USB 3.x port, and then measure again. If speed jumps at once, the bottleneck lies in the bus or reader. If speed does not change, the bottleneck lies in the card itself or the file system.
Q13: A FAT32 card fails to copy a large file. Does that mean that the card is full or broken?
A13: No. FAT32 has a single file limit, and copying a single file over the limit produces a system report that the file is too large for the destination file system. The diagnostic point is to see whether the failing file size sits just near the limit. If the failure point is at the same file size threshold every time, it is a file system limit. Solutions include changing to exFAT or another file system, splitting the file, or using another transfer method, but before changing file systems, data backup and target device compatibility must first be confirmed.
Q14: A faulty card pops up a message that formatting is needed before use. Should formatting be pressed at once?
A14: Absolutely not, especially when the card holds important data. Formatting rewrites the file system structure, and makes file records that rescue software might have recovered disappear. The correct order is to stop, image read-only, and rescue on the image. Only after data is safe should formatting be considered. Formatting is not repair. Formatting is clearing, and reversing the order of the two has completely different consequences.
Q15: Before sending for inspection, what are the most important things to prepare?
A15: First, a symptom timeline: when it started, whether there was an update, a card change, or a move beforehand, whether it is continuous or intermittent, and whether it appears at startup at once or only after a period of use. Second, layered test results already done: how the three paths perform separately, Disk Management state, error codes, driver versions, and which settings were changed. Third, control results: what another card, another reader, another port, and another machine each showed. Fourth, bring the card, adapter, reader, laptop, and charger normally used, so that diagnostic handling can reproduce the real combination. SD-related matters are always subject to a written quotation after diagnostic, and the general direction of pricing can be seen on the pricing page, which does not replace an individual diagnostic result. Fifth, confirm that backups can be opened, and that encryption recovery keys are in hand and stored separately from the machine. On smelling burning, smoke, abnormal heat, liquid residue, or a cracked card body, stop at once and send for inspection.
Unverified list
The following items could not be sufficiently verified with reliable sources, and this article has not treated them as facts in its main text. They are listed here only, so that readers know which claims still await verification. First, support speed, grade, and SD Express support details for particular reader chip model series. This research reliably verified only one built-in chip and one USB bridge chip. Details for other series did not obtain vendor datasheet originals, and are unverified, and must not be written directly into a specification table. Second, SD support grades for each generation of platform controller or system-on-chip vary by model, and are unverified, and the official specification or service manual for that laptop model must be used. Third, the full official SD specification requires membership authorisation. Capacity divisions and speed ceilings in this article are a publicly compiled system, retransmitted through public guides, not a direct quotation of the official full text. If official specification is to be marked, it should be noted as a public compilation, or an official public page original should be obtained separately. Fourth, the actual speed of a particular laptop built-in slot. Reports indicate that actual speed may fall below the theoretical ceiling, and actual speed varies with card, system version, and test method, and must not be written as a fixed guaranteed value. It should be written as a theoretical ceiling, with actual performance depending on card and system. Fifth, the quantified effect of high-speed USB signal interference on SD readers. Specific quantified data are unverified, and this article only keeps the change-cable and change-port comparison as a diagnostic method, and writes no specific interference figures or frequency band impact figures. Sixth, the specific rate at which Hong Kong humidity speeds oxidation. Humidity plus salt plus vibration is a reasonable mechanism inference, but specific acceleration multiples, oxidation timetables, and other quantified claims are unverified, and must not be written as figures. Seventh, specific lifespan figures for flash memory in each brand of card. Write cycle ranges for different flash memory types have broad intervals in public information, but lifespan for a particular card model must be based on that model vendor information, and this article writes no general lifespan figure. Eighth, specific channels for reader firmware updates. Whether a low-cost external reader has a firmware update, and how to update it, varies by brand and model, and this article only writes that vendor or laptop vendor official channels govern, and writes no general update steps. Ninth, the popularity of SD Express on ordinary laptops. This article only writes that before buying, it must first be confirmed whether the laptop and reader are marked as supporting SD Express, and writes no popularity rate figure. Tenth, the order of laptop vendor drivers taking priority over chip vendor generic drivers. That is a practical repair principle, and individual models may be the opposite. Each machine must be judged by the version and update log on that model support page. Eleventh, the internal bus path of a built-in slot on a particular newer architecture laptop. Official documents do not directly list internal bus details, and this article only discusses two verified differences, built-in slot versus external reader and accessory approval, and invents no internal bus speed figure. Twelfth, the specific scope of effect of system integrity protection on a particular reader driver. Only the general mechanism that older kernel extensions are restricted under protection was verified, and it was not verified whether any particular brand reader on a current system must switch protection off. Protection must not be suggested to be switched off for a single reader problem. Thirteenth, large capacity card support ceilings for particular camera models. Ceilings differ by brand and model, and this article invents no ceiling figure for any particular model. The supported memory card page of that model manual must be checked. Fourteenth, the quantified effect of humidity on gold finger oxidation. The link between humidity and poor contact is a reasonable inference, but this article found no quantified data, for example humidity thresholds or oxidation times, so it only gives a situation reminder, and makes no causal quantification. Fifteenth, the specific path by which a home edition system is affected by domain or device management policy. This article verified the existence of group policy and encryption policy, but the residual policy path for an individual home machine that once joined a managed environment varies with account history, needs checking machine by machine, and cannot be generalised. Sixteenth, the specific version dividing line for older system support of new cards. Dividing lines for older Windows or older macOS support of large capacity cards, file systems, and speed grades vary with system version, driver version, and firmware version, and this article lists no unified dividing line table. Each machine must be checked individually. Seventeenth, the specific current threshold for insufficient USB hub power. This article verified the mechanism that insufficient power causes reset and disconnection, but did not verify the actual power consumption figure of a particular reader during reading and writing. Judgement should be based on whether stability returns after bypassing the hub, rather than on a guessed current figure. Eighteenth, any specific repair price for SD reader related matters. All are unverified, and all are subject to a written quotation after inspection. Nineteenth, firmware menu paths for individual laptop models. They were not verified brand by brand, and this article only writes general guidance. Twentieth, specific repair cases for individual reader or laptop models. No cases were verified, and this article writes no clients, cases, reviews, or real names.
Need Professional Laptop Repair?
Laptop King has 15+ years of repair experience in Shek Mun, Sha Tin. Free diagnosis, transparent pricing, no fix no fee. 180-day warranty for your peace of mind.