Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tamhow to fix my flash drive no media, i was just transferring a game when i suddenly disappeared
escription: [E:]USB Mass Storage Device(NAND USB2DISK)
Device Type: Mass Storage Device
Protocal Version: USB 2.00
Current Speed: High Speed
Max Current: 100mA
USB Device ID: VID = FFFF PID = 1201
Device Revision: 0000
Manufacturer: NAND
Product Model: USB2DISK
Product Revision: 0.00
Controller Vendor: FirstChip
Controller Part-Number: FC1178BC
Flash ID code: 89D3AC32C600 - Intel - 1CE/Single Channel [QLC] -> Total Capacity = 1GB
Tools on web: http://dl.mydigit.net/search/?type=all&q=FC1178BC
Your flash drive is probably not fixable with normal Windows format tools. From the descriptors you posted — VID=FFFF, PID=1201, Manufacturer=NAND, Product=USB2DISK, Revision=0000, controller FirstChip FC1178BC — the controller appears to have fallen into a boot/service/recovery state instead of normal storage mode. For this controller family, the usual repair path is a FirstChip MPTool re-initialization, not Disk Management or diskpart. (usbdev.ru)
The practical answer is:
What likely happened is this:
From an electronics/storage-engineering perspective, a USB flash drive has two major layers:
The controller maps logical sectors to physical NAND pages and blocks. If that mapping metadata is corrupted during a write, the stick can still enumerate on USB but show “No Media” / 0 bytes because the controller can no longer expose a valid translated address space. That is why this kind of fault is below the filesystem layer. (usbdev.ru)
Your posted Flash ID code is also important. If that identification is correct, it indicates a single-channel, single-CE Intel QLC NAND with a reported total of 1GB. That creates two possibilities:
I would treat the drive as potentially fake-capacity until a full write/read verification proves otherwise. Capacity-fraud testing tools such as H2testw and F3 exist specifically to detect that condition by filling the medium and verifying readback integrity. (heise.de)
For your controller, USBDev currently lists two relevant repair-tool families:
USBDev also states that some FC1178 variants are handled by the separate FC1178/FC1179 page, so you are not limited to the old FC1178BC-only tools. (usbdev.ru)
An important practical point: tool version matters. Community cases on USBDev show that:
So “latest” is not always “best” for these controllers. Recovery often requires trying several versions. (usbdev.ru)
As of the public archives I checked, the available FirstChip repair landscape still includes:
| Tool family | Publicly listed builds |
|---|---|
| FC1178BC MPTools | 2016 to 2018-04-13 |
| FC1178/FC1179 unified MPTools | up to 2022-06-01 |
| FirstChip category index | separate sections for FC1178BC, FC1178/FC1179, and newer FC1179 branches |
The unified release notes mention improvements for Intel/Micron 3D flash, Windows 10 behavior, and fixes for occasional 0-byte / VID-PID display problems, which is relevant to your symptom class. (usbdev.ru)
A broader industry trend is that fake or misreported flash media remains common enough that post-repair verification is mandatory. H2testw and F3 remain the standard sanity checks because they write known patterns across the medium and verify them on readback. (heise.de)
A useful analogy is this:
If the database is corrupted, the warehouse may still physically exist, but the shipping desk cannot tell you where anything is. The PC then sees “a USB thing is attached,” but not a usable disk. That is why ordinary format tools often fail here: they operate only after the controller has already exposed a valid logical disk. (usbdev.ru)
Why did it happen during a game transfer? Large writes are the moment when the controller is actively updating mapping tables, wear-leveling data, and bad-block bookkeeping. If the stick is low quality, marginal, or fake-capacity, that is exactly when it tends to fail. The symptom you saw is consistent with that failure mode. (usbdev.ru)
Also note:
Those details come from USBDev’s own page and user comments, and they can save you time if the tool appears broken. (usbdev.ru)
If this product was sold as, for example, 32GB / 64GB / 128GB but repair reveals only about 1GB or some much smaller real size, that is a capacity-misrepresentation issue, not a repair success problem. In that case, the correct practical response is usually to stop trusting the device, request a refund/replacement, and report the seller if applicable. Verification tools such as H2testw/F3 are specifically intended to detect exactly this class of fraud. (heise.de)
There is also a safety angle: these MPTools are distributed through specialist repair archives, not a normal consumer vendor support channel. Treat them as low-level factory utilities:
Do basic checks first
If the descriptor stays the same
VID=FFFF, PID=1201, NAND USB2DISK, No MediaDownload the correct tool family
Best version order to try I would try them in this order:
Reason: USBDev evidence shows version sensitivity, and newer is not always better. (usbdev.ru)
How to run it
Settings approach
For a first repair attempt, the goal is to let the tool discover the real NAND, not to recreate the label capacity. Community reports show forced/incorrect settings can produce shrunken or unstable results. (usbdev.ru)
Run the repair
After a successful pass
Judge the outcome correctly
If you want to continue:
Your flash drive is most likely in a FirstChip controller recovery state, not a normal filesystem problem. The realistic repair path is a FirstChip MPTool, starting with FC1178BC-specific tools and then trying unified FC1178/FC1179 builds if needed. Expect the recovered size to reveal the true NAND capacity, which may be far smaller than the labeled size. After any successful repair, run H2testw/F3 before trusting the drive again. If multiple MPTool versions fail, the drive is effectively e-waste. (usbdev.ru)
If you want, I can give you a very short step-by-step MPTool checklist next, focused only on the buttons/settings most likely to work for FC1178BC.