yaro137 said:
The error is 0x00...7B(0xF8981524, 0xC00...34,000...,000...)
Also in safe mode it hangs on something called JGOGO.sys
yaro
JGOGO.sys is a JMicron JMB363 driver file. Perhaps the disk is
connected to the JMicron port ?
This is the approach I'd use.
First, have *two* spare disks at your disposal.
1) Copy the entire disk (all 250GB) sector by sector, to a spare disk.
That is as insurance, that you won't lose any data while working on the drive.
You can use "dd" disk dump, either in a Linux LiveCD environment,
or you can use a Windows port of "dd" (
http://www.chrysocome.net/dd )
2) Once the data is secure, you have two options for recovery.
2a) Repair the structures on the broken disk.
2b) Use a file scavenger to extract files and copy them to a spare disk.
*******
To repair structures on the disk, give TestDisk a try. If the drive
had a single partition of size 250GB, and you're absolutely sure of
that, then TestDisk can scan the disk, and see that file system,
and TestDisk will be able to write a correct partition table.
If that part worked, perhaps chkdsk could repair any other damage.
If the repair fails at any point, you have your "dd" backup copy to
use, to restore things again. If TestDisk wrote a wrong partition
table, and you ran chkdsk, it could make an awful mess. Whicn is why
you made a backup copy first.
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
*******
These are some file scavengers. These will attempt to locate files on the
broken drive, and copy them to a spare drive. Use this, if TestDisk is
not working properly or you suspect things are really messed up.
Make sure the spare disk has enough room to hold the scavenged files.
http://www.cgsecurity.org/wiki/PhotoRec
http://www.pricelesswarehome.org/WoundedMoon/win32/driverescue19d.html
*******
The 31GB number, could be indicating you've placed a jumper on the IDE
drive in an incorrect location. That jumper location is called
"clip", since it clips capacity to around 33GB or so. So perhaps
the number you're seeing, when connected to the second computer,
is because you put the jumper on the wrong pins ? Go to the web
site for the disk drive, and get the jumper block diagram.
You should also enter the BIOS and see if the identity of
the 250GB broken drive is correct or not. In some failure cases,
the drive will report a new smaller capacity, which is a sign of
serious trouble. Disk drives rely on storage of size and identity
information, at location "sector -1". If the drive controller is
not able to read that information, default information from the
disk controller firmware is used instead. I've seen this on a
40GB drive, that suddenly started saying it was a 10G drive and
its name was "Falcon" instead of Maxtor model xxxx. The ratio
of those two numbers, is the number of surfaces on all the platters.
Disk drive manufacturers provide diagnostic programs, and you
can run a program like that, to see how healthy the drive is.
You need to know what brand the drive is, to get a utility
which will do a good job of testing.
The first priority, is to back up the broken drive. You can
use "dd" for that, because it doesn't care about the state
of the partition table. It will just copy everything. If
the drive has bad sectors, there is another program called
"dd_rescue" which ignores bad sectors, and can speed up the
copy process, if "dd" is having problems.
Once you have your backup made, you can test with the
diagnostic program, repair the partition table,
scavenge files or whatever you want. If you screw up
the original broken 250GB drive, you can use "dd" to copy
the entire 250GB back to it later. Take note of the size
information from the drive, so that you can use block count and
size parameters properly when copying with "dd".
Example - copying 80GB drive to 300GB drive. 80GB drive is "broken".
Harddisk0 is the source. Harddisk1 is the destination.
The destination drive is bigger, so there is enough room to
hold the backup.
dd if=\\?\Device\Harddisk0\Partition0 of=\\?\Device\Harddisk1\Partition0
Record the exact amount of data copied. It is possible to control
exactly how much data is transferred, using block size and count
parameters. The product of bs*count should be equal to your disk
total size. The disk total size should be factorable, so two
exact numbers can be used that when multiplied together, equal
the total disk capacity of the target. Here, I'm copying back
the data, and defining exactly how much data I want copied.
Hopefully 1M * 80000 = 80GB. You can also use numbers like
bs=1048576 if you want more precision in what you're doing.
The disk size quantity should be factorable into two smaller
numbers. ("dd" commands tend to run a bit faster, if you use
block size and count parameters.)
dd if=\\?\Device\Harddisk1\Partition0 of=\\?\Device\Harddisk0\Partition0 bs=1M count=80000
Those are examples of doing it in Windows, on a second computer. In
Linux, it would look like this. The disk names are a bit different.
HDB would be the spare drive, to hold the backup copy. HDA would be
the broken drive. HDB should be bigger than HDA, so there is plenty
of room.
dd if=/dev/hda of=/dev/hdb
Anyway, that is the basic idea.
HTH,
Paul
