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

YES! it's about the third time I am telling you that! YES. Actually Dell's CD's (and also hardware and BIOS) have been a nightmare for years! It's NOT "easy". Here are some hints/resources: http://reboot.pro/5655/ (additional to the already given link: ) Basically you have a non-standard source, and the only way out is to make it "standard". BUT it's not "difficult" either: you will just need some time and patience. As explained in the given links, often integrating a Service pack "fixes" the Source. jaclaz

VERY good. Select/highlight in top section "NTFS 0" and click on "Open Volume". It seems that the $MFT has been foind (though size seems "wrong") You should have a view similar to the one attached. Post a screenshot of it. In the view I posted you can see that the $MFT starts on sector 6291519, which is allright for me as I have 63 sectors before. From the other view, (the one you already posted) you can see that the probable start sector is 2048 (which makes sense if it was partitioned under Vista). You can also try clicking (on the new view you created by "Open Volume" to click on the + near $Root and see if you can recognize some files/directories. jaclaz

Yep, at this point it seems like it's not going to find anything or anything of value. No prob, the "Free" version is allright for our scope, the Commercial adds features to recover files in batches/groups and "whole" directories: But for us it is at the moment just an alternative to search for the $MFT. jaclaz

If you had a motherboard with USB 2.0 chips BUT with BIOS using it at 1.1 speed only you would know what the point is. jaclaz

The more likely culprit is actually still your source. Either a file is missing or an entry in TXTSETUP.SIF pointing to "nowhere" or some other quirks are inside the source. Compare with this: You need to verify the source and/or try with an original XP CD (slipstreamed to the SP of your choice) but otherwise UNMODIFIED. You can also try through a PE: (slightly more complex as you also need to create a PE) It is possible that this solves the problem (i.e. by using a different install method by-passes it) or that it confirms that the Source is problematic. No way to know what will happen in advance. jaclaz

Sure , the Setupfailover.cmd is the script normally used to add the WINRE partition option to the BCD, this is why I posted these: http://www.svrops.com/svrops/articles/winvistare.htm http://blogs.msdn.com/b/winre/archive/2007/01/12/how-to-install-winre-on-the-hard-disk.aspx if you read them you should be able to understand the usage of the script and/or (if needed) modify it to suit your needs. jaclaz

Hmmm. Very strange. The $MFT is by default at sector (786432*8+sectorsbefore)=min 6,291,456 + "x" If you are at 18,805,000 it's no good, as it would mean that "x " is 18,805,000-6,291,456=12,513,544 which should mean roughly a 6 Gb hidden partition ( that you don't recall). Are you sure you are looking for the right string? In HEX it should be: 46494C4530 Try another thing. Get dmde: http://softdm.com/ Try scanning the image for NTFS volumes with it. jaclaz

Hmmm. Maybe the disk had a "recovery" or "hidden" partition of some kind? Try another thing. Go to sector 6291400. Then: Edit->Find/Replace Search for "FILE0" (CAPITAL, without double quotes, last character is a zero, not an "o") make sure you have selected "Find Text" and "DOS 8 bits". You will be prompted to continue searching beyond current sector, press the "Yes to all". It may take some time, but you should find a hit. If the hit is NOT at offset 0x00 in the sector then press again "Find", you want to find first hit that is at the beginning of a sector. jaclaz

Sure , we were talking of Windows XP, though. jaclaz