Коротко — да, обращаться в сервис можно и имеет смысл, но шансы на «доказать» старые сбои после secure‑erase невелики. Что важно сделать прямо сейчас — сохранить доказательства, максимально подробно проверить диск и зафиксировать результаты, затем обращаться в Kingston с описанием симптомов и логами/скриншотами. Ниже — пошагово что делать и какие тесты проводить.
1) Немедленно — резервная копия
- Полностью скопируйте важные данные на другой носитель. Диск нестабилен — не стоит рисковать.
2) Зафиксировать текущую информацию и логи (важно перед любыми дальнейшими операциями)
- Получите SMART/логи NVMe и сохраните их в файлы:
- Linux: установить nvme-cli и выполнить
- nvme list
- nvme smart-log /dev/nvme0 > nvme_smart.txt
- nvme error-log /dev/nvme0 > nvme_errlog.txt
- smartctl -a -d nvme /dev/nvme0 > smartctl.txt
- Windows: Kingston SSD Manager (KSM), CrystalDiskInfo — сохранить отчёты SMART в файлы/скриншоты.
- Сохраните скриншоты/видео BIOS с сообщением «дисков не обнаружено», BSOD (минимально — фото/видео экрана), сообщения LiveCD «не удаётся выполнить чтение…».
- Сохраните minidump файлы Windows (C:\Windows\Minidump) и экспортируйте события из Event Viewer (System, Application) в файл.
3) Какие тесты и проверки выполнить
- Вендорская утилита: Kingston SSD Manager — диагностика, firmware check. Это первоочередной инструмент для NVMe Kingston.
- SMART/Health: CrystalDiskInfo / nvme smart-log — смотреть особенно: Media Wearout Indicator / Percentage Used, Data Units Written/Read, CRC errors, Error Count, Unsafe Shutdowns, Critical Warnings, Reallocated/Bad Block counters.
- Полный self-test/extended test, если есть в утилите производителя или HD Sentinel.
- Чтение всей поверхности (non‑destructive read scan) — можно использовать badblocks в режиме чтения: badblocks -v /dev/nvme0n1 (это только для MBR/partition; аккуратно). Для NVMe лучше использовать vendor tool или fio с verify:
- FIO-пример для теста записи/проверки (выполнять только если диск пуст или у вас есть backup — это изнашивает SSD):
fio --name=verify --filename=/dev/nvme0n1 --direct=1 --rw=write --bs=128k --size=10G --verify=crc32 --numjobs=1 --iodepth=1
- Для стресс‑теста чтения/записи: fio --name=randrw --filename=/dev/nvme0n1 --rw=randrw --rwmixread=70 --bs=4k --size=50G --runtime=3600 --ioengine=libaio --direct=1
(корректируйте size, runtime; не перегружайте если диск нужен вам на хранение данных)
- Нагрузочный/температурный тест: следить за температурой под нагрузкой (KSM/CrystalDiskInfo), посмотреть, не уходит ли в троттлинг или не пропадает ли из системы при нагреве.
- Power‑cycle test: многократные перезагрузки/включения в коротком интервале (может воспроизводить «не обнаружен»), но выполняйте осторожно.
4) Можно ли «доказать» прежние сбои после secure erase?
- Маловероятно. Secure Erase / Sanitize часто удаляет пользовательские данные и может очистить некоторые журналы и фрагменты SMART/логов; вендор может иметь внутренние логи/журналы контроллера, но sanitize может их стереть. То есть прямого «снимка» старой ошибки скорее нет.
- Зато существуют сторонние доказательства, которые не затронуты erase: видео/фото BIOS/BSOD, системные логи Windows (если вы их сохранили), лог материнской платы/UEFI, minidumps. Это стоит приложить к заявке.
5) Что требовать от производителя / как формулировать заявку
- Описать симптомы: «пропадал из BIOS / не обнаруживался / BSOD / восстановление системы», даты/время, что происходило, сколько раз, на каких компьютерах (подтверждает, что проблема не в плате).
- Приложить: серийный номер, чек/дату покупки, SMART логи, nvme error logs, скриншоты/видео, minidump/Event Viewer.
- Запросить RMA с причинами: «intermittent failure — диск периодически не определяется/падает в BSOD» — запросить замену (RMA) и детальную диагностику. Обычно при таких симптомах разумно требовать замену (exchange) или хотя бы детальную диагностики и отчёт.
- Если производитель откажет, просите подробный отчёт тестов их лаборатории. Если диск проходит у них тесты и признаков отказа нет — могут вернуть без замены.
6) Практические рекомендации по стратегии
- Если данные важны и вы не хотите риска — лучше заменить диск (RMA/замена) пока гарантия действует — это самый безопасный путь.
- Если вы готовы рисковать и диск сейчас стабилен — можно мониторить (KSM, SMART) и требовать RMA только если сбой повторится; но имейте ввиду: если проблемы больше не воспроизводятся, сервис может отказать.
- Запрашивайте обмен (replacement) вместо просто диагностики, если желаете минимизировать риски и потерю времени. Многие вендоры идут на замену по intermittent failures, но политика разная.
7) Возможные причины, которые стоит проверить
- Проблемы питания/контактов/слота M.2 (подключите диск в другой компьютер и другой слот, проверьте винты/радиатор, питание).
- Перегрев / троттлинг
- Сбой прошивки (вендор может предложить обновление прошивки)
- Аппаратный дефект контроллера/памяти (иногда проявляется как периодические «не обнаружен»)
8) Что ещё делать/не делать
- Не выполняйте повторно интенсивные write‑тесты без нужды — это изнашивает TLC. Делайте преимущественно чтение и верификацию небольших объёмов.
- Сохраняйте ВСЕ логи и материалы — они пригодятся при RMA.
- Снимите видео, как диск перестаёт определяться (если сможете воспроизвести) — это сильный аргумент.
Итог / кратко
- Снимите и сохраните SMART/логи, скриншоты/видео, minidumps.
- Сделайте резервную копию данных.
- Прогоните вендорскую утилиту (Kingston SSD Manager) и сохраните отчёт.
- Обратитесь в Kingston с описанием симптомов и приложите собранные доказательства. Требуйте RMA/замены по intermittent failure, просите отчёт лабораторного тестирования.
- Если данные критичны или хотите исключить риск — замените накопитель (RMA / покупка нового) пока гарантия действует.
Если хотите, могу помочь подготовить текст обращения/жалобы в сервис Kingston и список файлов/скриншотов, которые стоит приложить, а также дать готовые команды fio/nvme-cli под вашу систему.