MHDD - Błąd command.com is missing or corrupted przy użyciu USBASPI.SYS

Witam. Mam podobny problem, jak w tym nierozwiązanym temacie: https://www.elektroda.pl/rtvforum/topic2573335.html#12332998

MHDD bootuję z tego SanDiska, a obiektem testów powierzchni dysku ma być zewnętrzny HDD WD Elements 1TB. Jak widać na poniższym obrazku, rozpoznawane są oba urządzenia.

Gdy dołączę do MHDD sterownik USBASPI.SYS, to niesety wtedy wyskakuje komunikat, że pliku COMMAND.COM nie ma lub jest uszkodzony.



Ten plik na pewno jest, wszystko z nim w porządku, bo bez USBASPI MHDD działa jak należy, dyski pod SATA spokojnie można przeskanować. COMMAND też nie ma na tę chwilę już żadnych atrybutów, więc nie może to być wina tego, że COMMAND może być np. niewidoczny. Dodam, że żadna kombinacja atrybutów nie działa. System plików pendrive'a, to FAT32.




Dodam jeszcze zawartość plików AUTOEXEC i CONFIG. O ile ten pierwszy myślę, że jest w porządku, tak z drugim może być coś nie tak, pewności nie mam, proszę o sprawdzenie i ewentualne poprawienie.

AUTOEXEC.BAT


CONFIG.SYS


Tutaj linijkę dołączającą sterownik USB dodałam na końcu, ponieważ gdy była wpisana gdzieś wcześniej, to wyskakiwał też komunikat o tym, że nie widzi RAMDRIVE.SYS.

Z góry bardzo dziękuję za pomoc.

Porównaj z http://hddguru.com/download/dl.php?file=c29md...0cdfcdcdf67c4903a532&magic=417108&rectum=1000

Myślałam, że coś ruszy, ale niestety problemy te same. Przy oryginalnej zawartości CONFIG.SYS, komunikat wyskakuje taki:



Czyli problem ten sam, jak wcześniej miałam z RAMDRIVE, gdzie powodem było wywołanie sterownika USB przed tym plikiem, więc po prostu dodałam linijkę z USBASPI na koniec i wybrałam opcję bez SCSI, bo wykonuje wtedy ten kod, który mnie interesuje. Wynik nieco lepszy, bo już widzi RAMDRIVE oraz OAKCDROM, ale problem jak początkowo - nie widzi COMMAND.



Takim łopatologicznym tokiem myślenia poszłam i dodałam z ciekawości przed załadowaniem USBASPI linijkę "device=command.com", ale się wiesza na tej linijce Ale kto wie, może w tym kierunku warto się przejść, tylko trzeba mu wpisać coś innego (choćby jak przy RAMDRIVE - zamiast "device", to "devicehigh").

Uzyj iso: http://hddguru.com/download/software/mhdd/mhdd32ver4.6iso.zip i utworz bootowalny nosnik przy pomocy rufus'a.

Rufusem się nie da: "Ten obraz nie jest bootowalny lub używa kompresji sektora rozruchowego niewspieranej przez Rufusa", ale za to bez problemu zgrało się programem UltraISO. Niestety problem z COMMAND nadal ten sam.

Zmienna path= powinna wyglądać tak:
path=%RAMD%:\;c:\
oraz:
rem set comspec=%RAMD%:\command.com

Nadal ten sam problem. Dodaję screena z AUTOEXEC, gdyby się okazało, że np. coś źle zrozumiałam. Zmiany w 1 i 3 od końca linijce w pierwszej części kodu.

sprawdź
http://hddguru.com/software/2006.02.10-Magic-Boot-Disk/
również UltraISO

A przypadkiem nie zrobiłaś systemu plików NTFS? Co tam robi folder System Volume Information?
Czym robiłaś tego pena?
https://hp-usb-disk-storage-format-tool.softonic.pl/

UltraISO nie nadaje sie do tworzenia bootowalnych pendrive'ow. Zawsze cos jest nie tak po wykonaniu.

slawekb61 napisał:

sprawdź
http://hddguru.com/software/2006.02.10-Magic-Boot-Disk/
również UltraISO

Pendrive się bootuje, natomiast jest nadal ten sam problem z command.com.

Robert B napisał:

A przypadkiem nie zrobiłaś systemu plików NTFS? Co tam robi folder System Volume Information?
Czym robiłaś tego pena?
https://hp-usb-disk-storage-format-tool.softonic.pl/

Napisałam w pierwszym poście, że file system to FAT32. Folder System Volume Information co robi? Po prostu sobie siedzi. W FAT'ach również. Nigdy ten folder nie miał wpływu na działanie MHDD, co już kiedyś Ci o tym pisałam. Nieważne w jaki sposób sformatuję nośnik i nieważne, czy to będzie NTFS, FAT32, czy FAT16, to u mnie zawsze (albo przynajmniej w większości przypadków, bo kilka razy rzuciło mi się w oczy, że go nie ma) pokazuje się ten folder. Jest absolutnie nieszkodliwy.

Nie chodzi o folder, tylko o sposób zrobienia pena. Pewnie za pomocą systemowego narzędzia i dlatego tam się znalazł.
Zatem zrób tym z mojego linku.

Robert B napisał:

Nie chodzi o folder, tylko o sposób zrobienia pena. Pewnie za pomocą systemowego narzędzia.
Zatem zrób tym z mojego linku.

Myślę, że ponowne sformatowanie tym samym programem naprawdę nie pomoże. Nie wiem dlaczego się tak uczepiłeś tego systemu plików, jak Cię zapewniam, że jest to FAT16/FAT32. Wiem, że z NTFSem mogą być tutaj problemy.

Powtórzę raz jeszcze, że MHDD działa. Bez problemu zrobię nim prawie wszystko, co zechcę. Tak, na tym "źle sformatowanym nośniku w pewnie NTFS, bo ma System Volume Information". Jedyne, czego nie zrobię, to nie przeskanuję już pełnoprawnego nawet dysku zewnętrznego, talerzowca, bo podczas ładowania sterownika USB wywala mi błąd z COMMAND.COM. Nawet bez podpiętego dysku się dzieje to samo, mając podpiętego samego penriva, czy kartę pamięci. Problemu nie ma tylko wtedy, kiedy nie chce korzystać ze sterownika USB i tego dotyczy się ten temat.


Dodam jeszcze screeny, bo już zauważyłam zależność i moje podejrzenia stały się trafne. FAT16/32 ok, zaraz po sformatowaniu nie posiada tego folderu, przy NTFS tworzy się on od razu, więc częściowo mogę Ci rację przyznać, ale tylko częściowo, bo za to również FAT, jeżeli podepniesz do komputera jeszcze raz, to w tym momencie tworzy się System Volume Information.

Zaraz po sformatowaniu:


I tutaj po wpięciu nośnika w inny komputer. Nawet po bezpiecznym usuninęciu sprzętu (tak, w razie czego, gdyby ktoś pytał). Nic więcej nie było robione:

Przeniesienie zawartości iso na pena, nic nie da. Miałem na myśli wypalenie iso na CD/RW(wielokrotnego zapisu np.) i sprawdzenie.
Niestety DOS to już dla mnie odległe czasy i nie potrafię obecnie podać poprawnych zapisów plików Autoexec i Config, te z ISO są dla płyt CD.
Aktualne pliki Autoexec i Config, możesz wyciągnąć UltraISO z obrazu Magic-Boot.
Problem polega na wskazaniu urządzenia(litery), skąd ma być uruchomiony command

slawekb61 napisał:

Problem polega na wskazaniu urządzenia(litery), skąd ma być uruchomiony command

Tutaj prawdopodobnie chodzi właśnie o lokalizację jako "C:\", bo wtedy pendrive robi za partycję systemową. To jest właśnie najdziwniejszą zagadką, że bez załadowania USBASPI wszystko działa jak należy, tyle że tylko pod SATA A co do płyt, to testowałam wczoraj jakieś CD-RW, ale nie wiem czy już coś z nagrywarką jest nie tak, czy nagle sie kilka płyt CD-RW zepsuło, bo mi się nic nie dało na nich zrobić, ale i tak lepiej na pendrive.

MHDD odpuść sobie, stwórz http://support.wdc.com/download/notes/DLGDiagUSBInstructionsv3.pdf

melanchel napisał:

MHDD odpuść sobie, stwórz http://support.wdc.com/download/notes/DLGDiagUSBInstructionsv3.pdf

W sumie nie byłoby to rozwiązanie mojego problemu, bo głównie zależy mi własnie na MHDD, ale mimo wszystko, choćby dla chwilowego efektu, próbowałam skorzystać z programu od WD. Co prawda ponownie, bo jak wszelkie Ultimate, czy Hirensy testowałam to na ten programik też się natknęłam, ale spróbować ponownie nie zaszkodzi. Niestety pod DOSem jest on tylko do dysków WD. Dysków, których jak widać, nawet nie widzi. Oczywiście dysk podpinany przed uruchomieniem komputera.

Jaką masz wersję DOSa na tym penie?
Co zwraca po poleceniu ver?

Robert B napisał:

Jaką masz wersję DOSa na tym penie?
Co zwraca po poleceniu ver?

Windows Millennium [Version 4.90.3000]

Wzięłam go z tworzenia DOSowskiej dyskietki pod XPkiem, jak widziałam w poradnikach. W razie czego, jeżeli to może być problemem, to mogę później popatrzeć inne wersje.

Wersję mogłam pobrać tylko po zgraniu "gołego" DOSa, oczywiście programem HP USB, bo po wpisaniu komendy ver w momencie, gdzie mi wyskakuje błąd o command, to nic mi nowego nie pokazuje, tylko wtedy ver brakuje lub jest zniszczone.

Rufus z opisu wgrywa http://www.freedos.org/download/download/FD12LITE.zip

Wywołaj menedżera ASPI po skopiowaniu interpretera poleceń itd. do RAM-dysku.
Np. tym https://github.com/joyent/sdcboot/blob/master/freedos/bin/devload.com - skopiuj na pendrive'a, wywal wpis ładujący usbaspi.sys z config.sys a do autoexec.bat przed ostatnią linijką (uruchamianie MHDD) daj devload usbaspi.sys /w /v

Trochę pokombinowałam na różne sposoby i wygląda to mniej więcej tak:

Rufus -> FreeDOS:

1. Dodałam tylko plik devload.com oraz w pliku autoexec.bat dodałam linię devload usbaspi /w /v przed linią mhdd /enableprimary.
Wynik: nie rozpoznaje polecenia devload, niby nie może rozpakować paczki z MHDD, ale w końcu uruchamia się "czysty" MHDD, czyli tylko z widocznymi dyskami IDE/SATA. Zewnętrzny dysk jak podpięłam, to też nie było go tam na liście. Zanim uruchomił się czysty MHDD, to wyglądało to następująco:


2. Dodałam to co napisał RobertB, reszta to samo, co w punkcie 1.

Robert B napisał:

path=%RAMD%:\;c:\
rem set comspec=%RAMD%:\command.com

Wynik: początkowo te same błędy, co w punkcie 1, ale jednak rozpoznaje polecenie devload, ładuje sterownik USB, ale zawiesza się w poniższm momencie:


3. Usunięcie słówka rem (czyli powrót tej linijki do oryginalnego stanu - set comspec=%RAMD%:\command.com), pozostawiona linijka z dopisanym ;c:\ (czyli - path=%RAMD%:\;c:\ ).
Wynik: przed załadowaniem sterownika USB, ekran wygląda jak na poniższym obrazku, natomiast po wykryciu urządzeń - komunikat ze zdjęcia pod punktem 2.


4. Po zmianie, czyli dodaniu rem, a usunięciu ;c:\ działo się dokładnie to samo, co w punkcie 1.

5. Powrót do załadowania sterownika USBASPI w pliku config.sys. Plik config.sys jeszcze troszkę zmodyfikowałam, bo FreeDOS nie wiedział, co ma zrobić ze skokami (np. [NOSCSI], [SCSI]), więc żeby nie sypało mi niepotrzebnymi błędami, to zostawiłam tylko tę część kodu, która mnie interesuje, a kod wyglądał następująco:

Wynik: nadal nie widzi command.com, tylko komunikat nieco inny, bo z FreeDOS'a Niezależnie od kombinacji ze zmianami zasugerowanymi przez Roberta, zawsze jest to samo.


6. Powrót do MS-DOS instalowanego programem HP USB. Załadowanie sterownika w pliku autoexec.bat, czyli tak jak w punkcie 1, tylko MS-DOS. Taki sam rezultat jest po dodaniu samego rem.
Wynik: kompletnie ignoruje sterownik USB, od razu ładuje się czysty MHDD.

7. Czy dodam obie zmiany zasugerowane przez Roberta, czy tylko dodam ;c:\, to efekt wygląda następująco:


Nie mam już pojęcia co robię źle.. Tak to w ogóle wygląda, jakby własnie usbaspi.sys blokował wczytywanie innych plików, bo zawsze jak dało się go gdzieś wcześniej w configu, to były problemy, bo czegoś nie widział. Nawet spróbowałam z USBASPI z innego źródła, w razie gdyby z HDDGURU był może jakiś uszkodzony (?), ale z innym wszystko jest tak samo.

Znalazłem ciekawy opis bootowalnego pena z HDAT2, możliwe iż Magic-Boot(MHDD ) z .img również da się. Powodzenia.
http://tunecomp.net/hdat2-tutorial-fix-bad-sectors-hdat2-bootable-usb-flash

Załadowanie menedżera ASPI powoduje utratę dostępu do systemu plików* - więc IMO dodanie C: do zmiennej PATH to proszenie się o kłopoty.

Masz tam Out of memory error i w następstwie dziwne błędy (w tym z devload.com) - coś zjada za dużo pamięci.

Trzeba skopiować co trzeba (MHDD, command.com itd.) do RAM-dysku.
Jeszcze warto przenieść część poleceń (ładowanie usbaspi.sys ... ładowanie MHDD) do zewnętrzego *.bat i go wywołać jako ostatni z autoexec.bat i inaczej się skończy błędem odczytu C bo autoexec.bat z niego 'odparował'.
Plik tekstowy msdos.sys może zawierać odwołania do C: <- wywalić z [Paths]

* - aby ponownie się 'dostać' do zawartości można użyć ASPI DISK Driver DI1000 (di1000dd.sys) <- problematyczny, lubi się wykładać z błędem przepełnienia przy dzieleniu.

Testowałem z dwoma pendrive'ami.

@WojtasJD Czy działa to z HDD USB 4k sector?
"MS-DOS from W98 [ver. 4.10.2222]
USBASPI 2.27X ASPI manager
MHDD 4.5 HDD tool"

@WojtasJD bardzo Ci dziękuję dobry człowieku. Troszkę miałam kombinowania, bo na początku nie do końca zrozumiałam o co Ci chodziło, ale też w sumie i tak chyba troszkę inaczej zrobiłam, w każdym razie, co najważniejsze - poszło. Bardzo dziękuję również innym osobom, które się zaangażowały w temat.

config.sys jednak trzeba zostawić w spokoju, ja powywalałam tylko niepotrzebne rzeczy, a w autoexec.bat wywaliłam w pierwszej części kopiowanie command.com, a później, po "wejściu" do RAMDRIVE kopiowałam tylko usbaspi.sys oraz devload.com. O dziwo nigdzie nie dawałam kopiowania command, a działa i nie wywala błędów. I na koniec pliku, żeby załadował sterownik, to przed uruchomieniem MHDD dałam, żeby wyszedł do nadrzędnego katalogu, załadował dopiero ASPI, a później wejście do folderu MHDD i dopiero uruchomienie programu (bez tego ignoruje sterownik). Załączę te wszystkie pliki wraz z instrukcją, żeby w razie, gdyby ktoś miał podobny problem, to żeby już nie musiał się tak męczyć jak my tutaj wszyscy. Mam nadzieję, że się komuś kiedyś przyda.

PS. Jeszcze mnie zastanawia taka rzecz, bo jak z ciekawości chciałam też przeskanować jakiegokolwiek pendrive'a i u mnie przy włączeniu skanu 2x[F4], MHDD się zawiesza, nic nie da się zrobić (jak na zdjęciu), dopiero gdy wyjmę pendrive'a, którego chciałam przeskanować, to wtedy rusza, ale twierdzi, że są same bad sectory, z tym że to już zrozumiałe, bo skoro już nie ma nośnika, który miał skanować, to będzie wywalał błędy. Natomiast zewnętrzny dysk twardy gdy się skanuje, to cały leci zielonymi bloczkami, odczyt <150ms. Czy to jest normalne?

ancykw napisał:

Witam. Mam podobny problem, jak w tym nierozwiązanym temacie: https://www.elektroda.pl/rtvforum/topic2573335.html#12332998

MHDD bootuję z tego SanDiska, a obiektem testów powierzchni dysku ma być zewnętrzny HDD WD Elements 1TB. Jak widać na poniższym obrazku, rozpoznawane są oba urządzenia.

Witam
Dlaczego męczysz się z tym żeby sprawdzić dysk .USB pod dosem
Można pobrać victorię 4,47 na Windows i widzi dyski USB skan itd
Poniżej masz link

Link




Pozdrawiam

@janpas6 , problem już praktycznie rozwiązany. Victoria pod Windowsem nie zawsze daje miarodajne wyniki (np. praca systemu potrafi negatywnie wpłynąć na wyniki testu, nawet jeżeli nie jest to dysk systemowy), dlatego chciałam skorzystać z DOSowskiego programu. Wiem co to Victoria pod Windowsem, posiadam ten oraz kilka innych programów, ale i to czasami za mało

Ok
Ale podczas testów nie korzystamy z internetu itd wtedy jest wynik w miarę wiarygodny .

@janpas6 to wiadomo, że trzeba dać wtedy spokój komputerowi, tylko po prostu dziwnie mi test powierzchni w tym dysku wychodził, też na innych lapkach inaczej (bo na dwóch testowałam), pewnie też sam fakt, że na starym lapku był podłączony pod USB 2.0, więc pewnie przez to wyniki były gorsze, chociaż wydaje mi się, ze chyba nie powinny.. ale co do tego to już ze znajomym się zgadałam, żeby mi przetestował też Victorią taki sam dysk, tylko inny egzemplarz i wtedy wyniki porównamy, czy rzeczywiście mam się o co martwić, czy niekoniecznie.