jaclaz

Try starting again from scratch with the MOTOR contacts insulated, i.e. try following to the letter the tutorial here: http://www.mapleleafmountain.com/seagatebrick.html AFAIK it has never been found why on some drives one needs to insulate the head and on others the motor. jaclaz

Yep, sorry, I mistook first entry in partition table as being FAT32, but the entry is actually for an Extended partition, the bootsectors are BOTH NTFS. Some more details. File MBR_HardDisk0.dat The partition table has two partition entries: Entry/Type/Boot/bCyl/bHead/bSect/eCyl/eHead/eSec//StartSector//NumSectors #0/0F/00/1/0/1/1023/254/63/-/16065/65609460 #1/07/80/1023/0/1/1023/21/20/-/65625525/246952523 The second one: is NTFS, it is Active (i.e. is the one that the MBR code will attempt booting), has balanced CHS/LBA address BUT it is NOT rescpecting Cylinder boundaries, it starts at LBA 65625525 The first one: is an entry for an Extended Partition, it has balanced CHS/LBA, it respects Cylinder boundaries, it starts at 16065 File BootSector_DriveC.dat It is a NTFS partition, it is obviously connected to the second entry in the partition table in the MBR BUT it has sectors before 161585152 (instead of 65625525) File BootSector_DriveE.dat It is also a NTFS partition, it is necessarily connected to the first entry in the partition table in the MBR BUT it has sectors before 63 (instead of 16065) - which is allright - as this is a logical volume inside extended and won't be bootable Now, a "normal" partitioning will have: as first partition a Primary one (and NOT an extended one) the CHS of ALL partitions will respect Cylinder boundaries the "Sectors before" in the partition table will be the SAME as those in the bootsector for Primary partitions "Fixing" the current partitioning to make "drive C" boot should NOT be a problem, all is needed is correcting the "sectors before", please find attached a modified bootsector for drive C that you can try restoring with the same HDhacker you used to create the one you sent. Just try applying it to LogicalDrive C:\ and it should start booting allright without the USB stick connected. But the disk will remain with the three partitioning inconsistencies previously detailed. This should normally create NO problems in "normal" use, but you may find incompatibiilities and problems with some specific kind of software, such as drive imaging/backup and partitioning/resizing ones. Still, something is not clear about HOW this non-standard partitioning happened - maybe there were remnants of a previous partitioning - possibly involving a "hidden recovery partition" - that *somehow* tricked XP into making this botched partitioning. jaclaz BootSector_DriveC_mod.zip

Well, clearly 5eraph - usually attentive and knowledgeable - did misunderstand you, and I had the same problem initially. Most "normal" command line programs do output the result of command to "standard output" and not to "standard error" AND normally use a parameter with a prepended slash or dash, it was NOT immediate to understand the question. On the other hand for all we knew, it could have been another kind of command, as an example you can take DISKPART or WMIC, that do behave "differently" from standard commands (and use not the slash or dash for parameters). Giving the exact reference - and when available - a link to the homesite of the program besides would have made your problem (and hopefully it's answer) findable by other members (or "passers-by") having your same problem. I mean, if you have a problem with, say, devtest, do you google for "devtest help" or for "some program some help commands"? This is one of the advantages of a board (as opposed to PM's or e-mail or phone help/support) problems (and hopefully solutions) are public and may be of use to a lot more people than OP. jaclaz

Under which OS (AND using WHICH utility) was the hard disk partitioned/formatted? The partition table is a mess , it uses fractional end cylinders for the NTFS (second) partition. (this should not happen if partitioned under XP with standard system tools). The FAT32 (first) partition on the contrary uses "good" balanced CHS/LBA values, but it starts at a "queer" location, CHS 1/0/1, aka LBA 16065 (instead of the "normal" CHS 0/1/1, LBA 63). The real problem about the flashing dash (or underscore) is however more likely in the NTFS bootsector (drive C:\ ) that has a "Sectors before" value of 161585152 (whilst sectors before are actually apparently 65625525 ! Same happen (though unrelated) to the FAT32 bootsector (drive E:\ ) that has a "Sectors before" value of 63 (which would be normally right) and instead an entry in partition table of 16065. I am wondering how it can have happened to have both "botched" addresses. (I'd like to understand WHAT/WHY before suggesting posible solutions). Also, what is the scope/need for the first (FAT32) partition? jaclaz

Ideally - if you ave enough space available, you should now make a copy of the image (and leave it alone) Then, get TESTDISK: http://www.cgsecurity.org/wiki/TestDisk Read a bit about it's usage. http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step http://www.cgsecurity.org/wiki/Data_Recovery_Examples Run it as follows: testdisk_win /log X:\my_path\image[0-100027630080].dd Change "X:" and "my_path" to your actual values. Se if you can list files on the partition(s). Copy them to another disk. Once you have the files safe we can try to "fix" the damaged filesystem. jaclaz

Blank screen with flashing dash is typical of a problematic bootsector. Generally speaking it is due to one of three things: UNbalanced CHS/LBA (unprobable) on some *rare* ( but not much) BIOSes by a non-standard geometry sensed for the filesystem PBR incorrectly set active partition In practice: get HD hacker: http://dimio.altervista.org/eng/index.html boot from the "NC10" (whatever it is) thorugh the USB stick remove the USB stick run HD hacker TWICE, once saving the MBR (first sector of PhysicalDrive) and once saving the PBR or bootsector (first sector of LogicalDrive) (repeat for EACH LogicalDrive listed) compress the files together in a .zip archive and post the .zip as attachment (or upload somewhere and post a link) I'll have a look at them and see if I can suggest you a way out/solution. jaclaz

The redirection can be from BOTH "standard output" and from "standard error" see here: http://www.robvanderwoude.com/redirection.php Some programs may send the output of the "help" parameter to the "standard error". You have no way to know as they appear in the console exactly as "standard output" does. Try: command help > somefile.txt 2>&1 Next time, please avoid "vague" descriptions, like "some help commands", "pertaining to some program", and the like,. STATE the EXACT program and the EXACT command and parameter you attempted issuing, as it is more likely that you won't be misunderstood and possibly have a more "targeted" reply. jaclaz

From what has been reported till now, the filesystem is lacking the $MFT, i.e. it's main file-indexing structure. I doubt that *anything* can recover *any* more fies than what dmde allowed/allows you to. BUT the rules of thumb are: NEVER give up (untill anything reasonably feasible has been attempted) throw at the stoopid filesystem each and every recovery software you can find (or can think of). Two more good candidates: SCROUNGENTFS (freeware): http://thewalter.net/stef/software/scrounge/ FILE SCAVENGER (Commercial - trial available): http://www.quetek.com/prod02.htm jaclaz

Your screenshot is about a Hitachi drive. It seems like the Seagate is NOT seen at all. jaclaz

Just press "P" on the last screenshot, as in: But I don't think you will get anything meaningful. I thought a bit over the matter and it seems to me like two things are possible: the partition was NTFS formatted using a "strange" program that puts the $MFT in the first (or last) million sectors (and that have then been wiped by the WD tool) the WD tool does something "more" than just wiping the first and last million sectors If the "P" doesn't let you see any file (or no more file than dmde did), the next logical step would be to attempt a file-based recovery (please read as PhotoRec): http://www.cgsecurity.org/wiki/PhotoRec The "quality and amount" of recovered files can vary greatly with very low percentages for heavily fragmented volumes and high ones for not fragmented ones - but you will have anyway to open each recovered file and re-name it. jaclaz

Try some other commands. There is a (partial) list of commands here: http://files.hddguru.com/download/Datasheets/Seagate/Seagate%20Diagnostic%20RS-232%20Port/ Are you doing this with: all contacts connected head contacs insulated motor contacts insulated (please choose one) jaclaz

NO. Just create the image. Then, we'll talk about (hopefully) recovering DATA from it. You DO NOT attempt booting from that image, and more generally you NEVER attempt booting from anything you want to recover DATA from. Rest assured that the size Drdd shows is the actual size. Anyway, just do the image, then we'll see what it comes in it. jaclaz

Just for the record Siginet made available a "related" tool: jaclaz

NO, the "old" one is "lost forever", but running the manufacturer tool should make a new one. It is NOT a good idea to "insist" on a failed/failing HD area. Which tool are you using? You may want to try making partial chunks of image, skipping the problematic part(s). (I don't think that any of the programs on UBCD have this possibility) - maybe Diskman You should need something like ddrescue (Linux): If you are "confined" to DOS, maybe this would be of use: http://johnson.tmfc.net/dos/index.html http://johnson.tmfc.net/dos/todisk.html jaclaz

I split the post from another topic. Generally speaking if you have a "large" question it is better to start a new topic, if you have a "narrow" one it's allright to add it to an existing related topic. About these (now numbered): 4 GB FOR DOS 6.22 AND WINDOWS 3.11 4 GB FOR WINDOWS 95 4 GB FOR WINDOWS 98 SE 4 GB FOR WINDOWS ME 4 GB FOR WINDOWS 2000 4 GB FOR SERVER 2003 4 GB FOR WINDOWS XP 4 GB FOR WINDOWS VISTA 4 GB FOR WINDOWS 7 Are they meant as "Run OS from USB hard disk" or as "Install OS from USB hard disk" ? The 4 Gb for #1÷7 are way too much. Particularly the max partition size for DOS 6.22 is 2 Gb - limit of the FAT16 filesystem that is the ONLY filesystem available on DOS 6.22. A typical Dos 6.22 + Windows 3.11 ran on 100 Mbyte size hard disks. A source for 2K/XP and 2003 still fits on a CD, a very BIG one with LOTS of drivers rarely reaches 1 Gb. If we are talking of installs, a base 2K install was 650 Mb, a typical XP install 1.5 Gb. You forgot NT 3.51 and 4.00 The 4 Gb for #8÷9 may be too little. In any case you don't really need separate partitions/volumes for each item of the list. jaclaz

NO. BUT you can find here: http://www.msfn.org/board/forum/157-install-windows-from-usb/ how to make one (from "normal" or "nlited" source) jaclaz

No , my bad, I posted WRONG dsfi command (mixed source with destination) image[0-512000000].dd should be exactly 512,000,000 bytes. as well image[319558320640-320070320640].dd should be exactly 512,000,000 bytes. Your image w:\DDimage\3200AAKS_Copy.dd should be 320,070,320,640 bytes in size. The RIGHT commands are: dsfi <destination> <offset> <size> <source> Thus: dsfi w:\DDimage\3200AAKS_Copy.dd 0 0 w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd dsfi w:\DDimage\3200AAKS_Copy.dd 319558320640 0 w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd Due to the mistake, the first one made w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd a copy of w:\DDimage\3200AAKS_Copy.dd , and the second one appended your image at the end of a BIG file (the fake image + a lot of blank sectors). Sorry for the mishap. The good news are that w:\DDimage\3200AAKS_Copy.dd was left "untouched". Delete both the HUGE, modified w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd and w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd. And re-do (with the corrected commands) starting again from the files inside the .zip/.7z. The result of the two commands should be the w:\DDimage\3200AAKS_Copy.dd still remaining the same 320,070,320,640 bytes in size, but with the first and last 1,000,000 sectors (512,000,000 bytes) replaced by the contents of the "fake image chunks". I would wait for a moment with VDK, try first what happens with TESTDISK. to open the image with testdisk open a command prompt in the testdisk directory and in it type: testdisk_win /log w:\DDimage\3200AAKS_Copy.dd jaclaz

YES, it is possible (though UNlikely), but remember though that the only thing that may have gone bad is that you ALREADY wiped/reset the G-list, so the only tihing you can do (i.e. re-wipe re-reset it) won't change situation/behaviour. You do not change the firmware to perform a LBA0 fix.. Try just doing it - leaving the firmware "as is" (whatever it is currently). Then you may want to run, from DOS, the Seatools. jaclaz

No, testdisk can operate on images allright, only your current image has no meaningful data for testdisk (no MBR, no PBR, no PBR mirror) Of course NOT with Daemon tools. But there are virtual disk drivers, even for x64, only cannot say how complex would it be to install them on Windows 7 64 bit. There are 64 bit builds of VDK.EXE (recommended) and of IMDISK (not recommended right now as it only mounts the volume and NOT the \\.\PhysicalDrive) Best place to get the known to be working VDK 64 bit driver is within this package (evolution of mbrbatch for XP x64 - won't probably work as is on 7 - the driver should): http://reboot.pro/5000/ http://reboot.pro/5000/page__st__5 just the driver: http://oss.netfarm.it/win32/ See if you get the hang of the VDK and of the thread in the meantime. jaclaz P.S.: Here are the two chunks of the "fake" image. WARNING you will need 7-zip to uncompress the archives inside the .zip and they will uncompress to 512 Mb each. The image has been partitioned/formatted under XP, but it shouldn't make any difference, for TESTDISK or other similar apps. You can use dsfi/dsfo (part of the dsfok toolkit) - it should work allright under Windows 7 64, download from: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ syntax is quite straight: dsfi <your path>\image[0-512000000].dd 0 0 <your COPY of the image> dsfi <your path>\image[319558320640-320070320640].dd 319558320640 0 <your COPY of the image> fake_image_chunks.zip

No prob, I know how it is when you try doing things you have not enough familiarity with.... Yes, in the given link it was a multi-stage process, of which integrating a SP was only one step. Yep , as said you will need some time and patience. jaclaz

Further disambiguation: you DO NOT run "a XP directly and live from the CD", you run a PE (Pre-installation Environment) derived from the XP install source. This is NOT XP (though it can be tweaked to look like XP). To build a PE 1.x (i.e. from XP source, PE 2.x is built from Vista source and PE 3.x from Windows 7 source) you need a PE builder. There are mainly two of them: Bart's PEbuilder: http://www.nu2.nu/pebuilder/ http://www.911cd.net/ Winbuilder: http://reboot.pro/forum/22/ UBCD4WIN is a nice pre-configured project making use of Bart's PEbuilder. The good news are that I lied you can actually build a "real" XP booting from CD, but you won't like the complexity needed to build one and the limitations it has about different hardware: http://reboot.pro/3890/ jaclaz

I really don't know. What you posted says: that the partition started at 2048 <- which as said makes a lot of sense if the Volume was partitioned under Vista that the $MFT should be at sector 6293504 <-which matches default values and the 2048 start BUT the $MFT view is different from a "good" $MFT <- which also justifies why Tiny Hexer cannot see the initial "FILE0" of the $MFT AND anyway *somehow* dmde can "see" your old files. If you can make a copy of the image, I can prepare a "fake" pre-formatted image and we can try replacing (on the COPY, NOT on the "original" image) the first and last million sectors from the "fake image". This way you should be able to analize the modified COPY of the image in TESTDISK and/or mount it in a Virtual disk and attempt running chkdsk on it. Another option may be (it depends on how much data you need to recover) to continue using dmde "manually" - one file at the time - or consider buying a license for it, for non-commercial uses it is 16 Euros. jaclaz

Try on another machine (one to which you NEVER connected the hard disk in a USB enclosure). It sounds like you have some "messed up" entries in the Registry. (which mind you seem like ADDITIONAL to the other problems you list). Also, can you try repeating - from scratch - the 0 LBA fix? jaclaz

http://www.datarescue.com/photorescue/v3/drdd.htm http://erwan.l.free.fr/clonedisk/ (but these of course WON'T bypass BIOS/OS - you will need a hardware imager - something in the several hundred dollars price range). jaclaz

Problem is that from the view you posted the $MFT seems corrupted. Try clicking on $MFT on the left, then on any folder and inside the folder try recovering a single (smallish) file. (BE CAREFUL as to use a folder on ANOTHER drive as target for the recovered file). I am wondering what the heck can have hapened. Can you right click on the actual image you made and choose Properties (and post screenshot)? I have some doubts about the TinyHexer screenshots you posted. How big is the image you have (in bytes)? jaclaz