u/OppositeConfusion527

SanDisk Ultra 32GB (VID:PID 0781:558A) stuck in hardware write-protect — controller shows "Unknown" in ChipGenius, looking for exact controller ID / recovery options

Hey all troubleshooting a dead SanDisk Ultra 32GB and hit a wall on controller identification. Data doesn't matter, I'm fine with destructive recovery attempts. Posting full diagnostics in case anyone's dealt with this exact chip.

Drive:

- SanDisk Ultra, 32GB nominal / 28.6 GiB usable

- VID:PID = 0781:558A

- Serial: 03018817100220090548

- Marking on casing: BM201067713W

- USB 3.x capable, currently negotiating at 480 Mbps (USB 2.0 speed)

Symptom:

Kernel and every tool I've tried report the device as hardware write-protected, not just filesystem RO:

sd 2:0:0:0: [sdb] Write Protect is on

sd 2:0:0:0: [sdb] Mode Sense: 43 00 80 00

lsblk shows RO=1. blockdev --getro returns 1. hdparm -r0 /dev/sdb is rejected outright — reports back "readonly = 1 (on)" even after the "set" command. This is coming from the controller's Mode Sense response (byte 0x80), not the OS.

What I've ruled out:

- Not a filesystem-level flag — chmod/mount -o rw/fsck won't touch this, the SCSI layer itself is refusing writes

- sg_modes -p 0x1a → "invalid field in cdb," page not supported

- sg_readcap -l → fails with "Read-only file system"

The actual problem — controller ID:

This is where I'm stuck. Genuine SanDisk Ultra drives on this VID:PID apparently use SanDisk's own in-house controller, not a merchant chip (Phison/Alcor/SMI), so the usual identification tools come back empty. From what I've found searching around, ChipGenius and Flash Drive Info Extractor report "Controller: Unknown" for this exact VID:PID on other people's genuine units too — not just mine.

What I'm hoping someone can help with:

  1. Has anyone actually identified the physical controller marking on a genuine SanDisk Ultra 558A PCB (not a rebadged/counterfeit one)? Willing to open the case and post a photo of the die/chip marking.

  2. Is there any known MPTool or recovery utility that works on SanDisk in-house silicon, even semi-official/leaked? I know Phison/Alcor/SMI all have community tools — has anyone found an equivalent for SanDisk's own controllers?

  3. Given the "Write Protect is on" bit is coming from Mode Sense and won't clear via hdparm/blockdev, is this consistent with NAND spare-block exhaustion putting the FTL into failsafe, or could it be something else at the controller level I'm not considering?

Drive is fully expendable — happy to try destructive low-level commands, vendor-specific SCSI opcodes, JTAG/UART probing, whatever. Just trying to figure out if there's a real path forward before I write it off as dead silicon.

reddit.com

SanDisk Ultra 32GB (VID:PID 0781:558A) stuck in hardware write-protect — controller shows "Unknown" in ChipGenius, looking for exact controller ID / recovery options

Hey all troubleshooting a dead SanDisk Ultra 32GB and hit a wall on controller identification. Data doesn't matter, I'm fine with destructive recovery attempts. Posting full diagnostics in case anyone's dealt with this exact chip.

Drive:

- SanDisk Ultra, 32GB nominal / 28.6 GiB usable

- VID:PID = 0781:558A

- Serial: 03018817100220090548

- Marking on casing: BM201067713W

- USB 3.x capable, currently negotiating at 480 Mbps (USB 2.0 speed)

Symptom:

Kernel and every tool I've tried report the device as hardware write-protected, not just filesystem RO:

sd 2:0:0:0: [sdb] Write Protect is on

sd 2:0:0:0: [sdb] Mode Sense: 43 00 80 00

lsblk shows RO=1. blockdev --getro returns 1. hdparm -r0 /dev/sdb is rejected outright — reports back "readonly = 1 (on)" even after the "set" command. This is coming from the controller's Mode Sense response (byte 0x80), not the OS.

What I've ruled out:

- Not a filesystem-level flag , chmod/mount -o rw/fsck won't touch this, the SCSI layer itself is refusing writes

- sg_modes -p 0x1a → "invalid field in cdb," page not supported

- sg_readcap -l → fails with "Read-only file system"

The actual problem — controller ID:

This is where I'm stuck. Genuine SanDisk Ultra drives on this VID:PID apparently use SanDisk's own in-house controller, not a merchant chip (Phison/Alcor/SMI), so the usual identification tools come back empty. From what I've found searching around, ChipGenius and Flash Drive Info Extractor report "Controller: Unknown" for this exact VID:PID on other people's genuine units too ,not just mine.

What I'm hoping someone can help with:

  1. Has anyone actually identified the physical controller marking on a genuine SanDisk Ultra 558A PCB (not a rebadged/counterfeit one)? Willing to open the case and post a photo of the die/chip marking.

  2. Is there any known MPTool or recovery utility that works on SanDisk in-house silicon, even semi-official/leaked? I know Phison/Alcor/SMI all have community tools, has anyone found an equivalent for SanDisk's own controllers?

  3. Given the "Write Protect is on" bit is coming from Mode Sense and won't clear via hdparm/blockdev, is this consistent with NAND spare-block exhaustion putting the FTL into failsafe, or could it be something else at the controller level I'm not considering?

Drive is fully expendable — happy to try destructive low-level commands, vendor-specific SCSI opcodes, JTAG/UART probing, whatever. Just trying to figure out if there's a real path forward before I write it off as dead silicon.

reddit.com

VIDEO_TDR_FAILURE (nvlddmkm.sys) even after BIOS/Firmware updates on my laptop

Hi everyone,

I'm having a recurring issue with my Acer Nitro Lite (i5-13420H + RTX 4050, Windows 11), and I'm trying to figure out if this is a driver issue or a hardware problem.

Symptoms:

-Random BSOD: VIDEO_TDR_FAILURE (nvlddmkm.sys)

-Browser occasionally crashes when hardware acceleration is enabled.

I usually use the laptop plugged in with an external monitor.

One time, the laptop suddenly shut down while the battery was around 100%. After restarting, it showed 1% battery, and once I plugged in the charger, the battery percentage increased rapidly.

What I've already done:

-Updated Windows completely.

-Installed all Optional Updates.

-Updated the firmware/BIOS as instructed by Acer Support.

Checked Event Viewer, which shows multiple nvlddmkm errors (Event IDs 13 and 153) before the crash.

Analyzed the crash dump (C:\Windows\MEMORY.DMP) using WinDbg Preview.

The dump reports:

Bug Check: 0x116 (VIDEO_TDR_FAILURE)

IMAGE_NAME: nvlddmkm.sys

MODULE_NAME: nvlddmkm

FAILURE_BUCKET_ID: 0x116_IMAGE_nvlddmkm.sys

Unfortunately, the laptop crashed again even after updating the firmware and installing all additional updates.

reddit.com
u/OppositeConfusion527 — 1 month ago