jaclaz

At first sight there is nothing "wrong" in them. BUT how exactly (under which OS, with which tools) was the disk partitioned originally? The sectors you posted seems like a "normal" XP partitioned (French), single NTFS: #0 07 80 0 1 1 1023 254 63 63 976768002 The data in the bootsector is as well "standard": 3 0003 OEM String: NTFS 11 000B Bytes per sector: 0200 512 21 0015 Media type: F8 248 24 0018 Sectors per Head: 003F 63 26 001A Number of Heads: 00FF 255 28 001C Sectors Before: 0000003F 63 40 0028 Total Sectors: 000000003A384C01 976768001 48 0030 LCN for $MFT:: 00000000000C0000 786432 56 0038 LCN for $MFTMirr:: 0000000003A384C0 61048000 64 0040 Clusters per $MFT record: 000000F6 246 68 0044 Clusters per Index record: 00000001 1 72 0048 Volume Serial: 6424B80A24B7DD6C Which OS are you running/can run? Ideally you should try imaging the disk on a (larger) device as a file, first thing, do you have (or can buy) a 640 or 750 Gb disk? You could check with a disk viewer/editor the presence at the designed addresses of the $MFT and of it's mirror. $MFT is at 63+786432*8=sector 6,291,519 $MFT Mirror is at 63+61048000*8=sector 488,384,063 The first sector of both should begin with "File0" or in hex "46494C4530". jaclaz

Well, no. If it was a "mere" partition copy, it would never have booted from the new disk, you would need anyway to copy (or fix) the MBR and the disk signature - or the connected Registry entries). So, even if it would not be a "whole disk" copy, it would be anyway a "whole disk copy minus the second temporary partition" . jaclaz

No, it's OK, as said it is very likely (though not "granted") that the 32 bit programs will work in the 64 OS without a glitch, but I have a few doubts on the cloning app that you mentioned . According to this: http://www.todo-backup.com/support/tutorial/clone-hard-drive.htm It sounds like even in the "sector by sector" mode the actual partition table OR "indexed in the filesystem sectors" (used space in the above snippet) is involved in the "clone" process. This (forensic version of dd): http://gmgsystemsinc.com/fau/ or rawcopy: http://www.ltr-data.se/opencode.html/ might do (as they have a 64 bit version). If I were you I would try the latter. Something "plain" like: should do, the above uses NOT any "fine-tuning", it will probably take some time (a few hours) to perform the copy. Be VERY, VERY careful in choosing m and n ....they are the disk numbers (as you can see them in Disk Management and/or diskpart, first disk (boot disk) is 0, if you have three disks they will be 0, 1 and 2 be sure to identify correctly which one is the source and which is the target. When cloning a disk drive it is a good idea to make sure that BOTH the "source" and the "target" drives are kept "cool", depending on your setup/hardware, it could be advisable to add a fan to have some additional airflow aroud the disks. The "general" issue with 7 might be that the disk (actually some sectors on it) are "locked", from what I understand this should not apply to a disk that is seen as "RAW", most possibly later in the recovery it might be needed to put the disk "offline", see references here: page__view__findpost__p__1006402 jaclaz

You are very welcome to ask questions , but you will need to be more flexible with your "available tools". I have NO idea IF any of the mentioned software will work: under 64 bit under windows 8 under the two above combined or if they will work "correctly". If I should bet on the worst possible combination one could find for data recovery, I would bet on Windows 8 64 bit . Now, get real . You are going to risk supposedly very valuable data by using "legacy" tools, designed for 32 bit on a 64 bit OS (and this in itself is not "smart" as you rely on the 32 bit subsystem that could have some incompatibilities with "real 32 bit OS) and to this you add the use of newly released OS (and traditionally NO MS OS was EVER found to be stable before "SP1"). While the first would be IMHO a limited risk (but that I would anyway choose NOT on valuable data), the second seems to me like "pure folly" . If you had several YEARS of experience with the tools, then it would be logical for you to test the new OS and environment (on EXPENDABLE data ONLY of course) but without any experience with the tools introducing a brand new OS? Come on.... If you have not available a "good" WIndows NT based system, i.e. a 2K or XP (and possibly NOT Vista or 7 AND definitely NOT 8) then you'd better get a free Linux based live disk, that is known to work. You want either ddrescue or dd_rescue (most distro's will have one of them) and TESTDISK/PHOTOREC are also available in the Linux version on many distro's, Parted Magic is the first one that comes to mind: http://partedmagic.com/doku.php?id=start jaclaz

To be on the safe side you should first thing image the disk. Normally one would image the disk, i.e. save it's entire contents to a file on another (larger) disk. Since you only have other disks of the same size this is not possible, so, as a poorman's solution you could clone (i.e. directly copy sector by sector) the contents of the unbricked disk to the other disk. This is intended as a preventive measure, by having an image or a clone, in case of any possible "mistake" during the recovery procedure you have a "way back". Under windows NT (and possibly a 2K or XP would be "better" than a Vista or 7 because of some added complications with direct disk access in these two latter OS's) recommended tools are: For imaging DatarescueDD: http://www.datarescue.com/photorescue/v3/drdd.htm For cloning : http://alter.org.ua/en/soft/win/bb_recover/ The app of reference is TESTDISK (for partition oriented recovery) or the "companion" PHOTOREC (for file based recovery): http://www.cgsecurity.org/wiki/TestDisk It is very possible that some manual intervention by means of a hex editor will be needed anyway, in any case, if you have ANY doubt in the usage of any of the tools, ask BEFORE doing something that you may later regret . Here is an example of a similar recovery, performed succesfully after the OP used TESTDISK improperly (that should give you a fair idea also of the steps necessary to use it properly) and - if you are in the same situation - give you some hope in the success of a partition based recovery: jaclaz

Not at all competitive . Momentarily irritated by your pickyness on the unrelated thread, yes And the idea was not at all to somehow "intimidate" you and/or prevent you from replying to a question, your post to which I replied was NOT an answer to any question, or at least not an answer to any question asked on that thread, the idea was to highlight the off-topicness of your remark. We both provided a possible solution - of course as different variations - but on a SAME theme, that is/was "booting something else". But - just for the record - no, I would not have needed to create a 2nd partition on the "source" (actually currently booting drive) as I suggested to use grub4dos to boot from a floppy image saved on the same (already existing) partition. On the contrary, one would have needed a partition (even temporary) on the "target" drive, to store the image. The idea was to make the less "intrusion" in the source drive, while having the "target" drive (which is/was larger in size) "free" to be formatted/partitioned as one would like. Still in the idea of an "as accurate as possible" image, since the "source" drive is/was 40 Gb and the target drive is/was 120 GB, I would have (in my perverted mind) used the first 40 Gb of the "target" as "space available" to restore the image and the "rest" as space to hold the image to be later restored to the first 40 Gb. The only changes on the source disk would have been: a single line added to BOOT.INI <- which can be added (and later removed) by using NOTEPAD or any text editor a single file a few hundreds of Kb added to the root of the drive (grldr) <- which can later be deleted allright optionally a second very small plain text file added to root of the drive (menu.lst) <- which can be later be deleted allright a single file 1.474.560 bytes (or less if .gz compressed) anywhere on the drive (the floppy image) <- which can be later be deleted allright Your idea is good as well (and I don't see in it all the defects that you are now listing ) but IMHO it represents NOT an answer to the question, since you modify the source disk (by reducing the size of the current partition and add a new partition to store temporarily the image) the image contents that will be deployed to the new disk will be not the image of the disk"as is", but of the disk as "it will be" after your mods... Since PROBLEMCHYLD didn't use EITHER of the proposed solution (which I repeat are both "valid" and "working") but used his own way (which is as said yet another non answer to his original question but the answer to another question) I would call the result of the game between us a draw or even better a null . BTW, and just to be as picky as I traditionally am, had JorgeA asked originally the actual question he had in mind, that is/was: He would have got a simple "Yes" answer: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html and there would have been a lot less key presses, and bytes sent over the internet, and misunderstandings (for these latter ones, please accept my apologies should I have somehow hurt your feelings). jaclaz

Sure , it is designed to do that, as long as you ALSO have a way (typically a CD/DVD and/or a USB device or second instance of OS on another disk) to actually initiate the recovery procedure. I.e. the thingy is installed to "backup" into the "live" system but needs to boot (in order to "restore") from "external" media (as the new disk will obviously be "blank"). A good idea, as always when it comes to delicate things such as backing up and restoring, is: DO NOT trust the vendor/Author of the tool DO NOT trust what a guy on a board says DO NOT trust yourself (in the sense of not trusting the presumed familiarity you have with the tool, the way you understood it should be operated and/or the way it works or it is advertised as working) actually get a "new" disk and simulate the backup and recovery process BEFORE disaster happens and see if the result is what you expect If you had actually READ the manual for that thingy: http://www.seagate.com/staticfiles/blackarmor/userguides/BlackArmor_UG.pdf You would have probably found out most of the concepts I briefly summed up. The biggest "risk" with tools like that one (which can do several types of operations/different kinds of backups/images) is the actual way it is used, if you prefer there is a risk of a PEBCAK . AFAICT, it represents a "good" software, though I personally do not like that kind of software (like any other similar software that "hide" the complexity of operation behind a "few click away" APPARENT simplicity) and I prefer to use simpler (most people would call them "more rudimental") software/tools. In a nutshell: Can it do it? Yes. Will it do it? Cannot say. Will it do it when used by you? Cannot say even more.... jaclaz

Whether Microsoft forbids its use or not is totally irrelevant, as well as "MS legal standards" are, something is either legal or illegal according to Law, no matter what MS thinks about it, your local Laws may (usually slightly) differ from another country's ones, but the "opinion" by the good MS guys is irrelevant "everywhere". The question would be - in case - whether MS forbids it AND they can actually legally do it (i.e. if forbidding it is legal or not). If hypothetically they would actually forbid it BUT had no legal (nor practical) means to enforce that, even a positive answer to first question would be meaningless. The answers are anyway NO and NO and no grey areas of sort. You acquired a valid license to use a thing called "Operating System" that is an assembly of a number of separate (or separable) apps/programs/tools. (BTW, specifically also the fact of calling Vista an "Operating System" may be debated ) Let's say that - by mistake - you delete NOTEPAD.EXE or PAINT.EXE. Would this mean that your OS license is made invalid or illegal? Naah, the most they can say is that they won't provide support for your modified OS (which is good since they won't provide a good one even for your "untouched" OS ). They could also decline any responsability for the lousy text that you use notepad to type, but since they already declined any and all responsabilities for anything that the OS (or you through the OS) may ever do or fail to do, this is also allright, they could even want to keep distant from the artwork you produce in paint (or in another program that you use instead of paint), but that's all. jaclaz

Well, most probably "align=4" is used (instead of "align=32"). The result shoudl be the same. It seems like the "align=4" implies "offset=32", i.e. it actually means not "align to 4 Kb" but rather "align to 4 Kb at first multiple equal or beyond 32 Kb". The "full syntax" is something like: where m=32|64|128|256|512|1024|2048 and n=2|4|8|16|32|64 Result being that: all have the same result. It is very possible that the diskpart script (IF diskpart is used) is inside a compressed archive of some kind, yes. jaclaz

Which was actually the SAME one I had proposed LONG BEFORE you did, i.e. booting to "something else" Compare: with: and I can assure you that the suggestion I made (BEFORE yours) is as valid and possibly much simpler, and there are possibly several more very good alternatives to both. BUT, this thread is not the one where we discuss what PROBLEMCHYLD could or should do in order to solve his problem, this thread was started by JorgeA that asked a question about two statements (BTW perfectly valid) that submix8c and myself did in that specific thread and by taking it out of context managed to derive from them a doubt that needed to be cleared (the possibility to have a "good enough for bare metal restore from within an INSTALLED THIRD PARTY TOOL and a running XP). Your nice suggestion about a not installed third party tool in order to solve PROBLEMCHYLD's issue has obviously no actual relevance on a question about an installed third party tool used in another context. To try and clear the doubts: "third party tools" (NOT INSTALLED) do exist that can do a "bare metal recovery" <- from a "non-live" XP system "third party tools" (INSTALLED) do exist that can do a "bare metal recovery" <- from a "live" XP system there are ways by combining "third party tools" (EITHER INSTALLED or NOT INSTALLED) with built-in tools like cdob suggested on the referenced thread (NTBACKUP) <- from a "live" XP system jaclaz

There is nothing "wrong" in your partition table. The first partition starts on sector 64 (which IS CHS 0/1/2) and ends beyond the CHS limit (and thus CHS is at it's max values 1023/254/63). The second partition is entirely beyond the CHS limit ad thus it has CHS values 1023/254/63 1023/254/63). Yes, we can debate if the second partition should be 1023/0/1-1023/254/63 instead, but it won't make any difference in 99.99% of cases. You have clearly a "missing piece" in the puzzle . Any address BELOW the CHS limit (in this case of 255/63 geometry) aroung 8Gb or 1024*255*63*512= 8,422,686,720 bytes MUST be represented BOTH in CHS and LBA addressing. As a matter of fact ANY address MUST be represented along BOTH the addressing methods, the only difference is that for partitions extending beyond the CHS limit, the CHS address resolves to "a suffusion of yellow". How exactly did you get the 64 sectors before alignment? Most probably just like Tripredacus did here: though "somehow" using an "align=32" with diskpart or using one of the "disk manufacturer" Advanced Format formatting tools designed for XP jaclaz

Hmmm. The general idea is to ask for help BEFORE writing anything TO the disk. There are no "magic ideas" , there are only a few "common ideas" , that are actually procedures to attempt recovering the data . Mind you it is very possible that by using an UNsuitable tool in an UNsuitable way, even if the firmware unbricking procedure was successful you effectively corrupted the disk contents beyond any possible recovery . What you should do now would be: STOP fiddling with the disk make a dd-like image of it start a new thread asking for assistance in the recovery An example of the procedure involved is given here (and links within): jaclaz

Just for the record: Antenna on the Cheap (er, Chip) http://www.oreillynet.com/cs/weblog/view/wlg/448 Spanish: http://web.archive.org/web/20080701025639/http://www.selui.com/wireless/antenapringles.html Spanish double (and USB ): http://carzel.wordpress.com/2006/01/03/antena-casera-para-wifi/ jaclaz

I guess we are always around the same terminology issues. Cloning. Imaging. Backing up. Let's see if I can explain the basics. A clone is an EXACT, byte by byte, copy of a disk (normally whole disk). If you prefer there is NO way to distinguish the copy from the original. (set apart the actual hardware disk serial/make/model/capacity). An Image (a "real" or "forensic sound" or "dd-like") is the same as above, stored *somewhere* and that once deployed to a disk the target will become a clone (again No way to distinguish it form the original). Is such a "forensic sound" image (or the "clone" that you can create directly or through dploying this "dd-like" image) needed for *everything*? Certainly not . It is NEEDED; VITAL for: forensics data recovery whatever that requires an EXACT copy For other uses (such as "bare metal" recovery) more than a few things can be removed from it, an incomplete list being: unused sectors (no matter if actually 00's or simply unindexed space) slack space (see here for a NTFS oriented list) : http://www.forensicfocus.com/Forums/viewtopic/t=9374/ pagefile.sys (if any) hyberfil.sys (if any) temp folders contents and more generally caches, histories, cookies, etc. (usually) hidden sectors .... So, if we put the whole disk at 100%, a clone or a forensic sound image will be 100%, while an image done for other scopes may be anything between a very low value (for an almost empty disk) up to 99.99% (but NEVER reach 100%), more likely it should be at something like max 70%. Then there is another issue, the WHEN. A clone or a forensic sound image are made rigorously OFFLINE at a given date/time. Immediately after (and until you don't boot either the original or the copy/clone) they are IDENTICAL. Things like last time accessed timestamps are preserved. A more "normal" image CANNOT be made ONLINE IF NOT through using the Volume Shadow services (or equivalent third party approaches/methods). What the Shadow copy does is to create a "temporary" unchanged version of files. So what you copy is not actually what "is" on the system, but what "was" on the system. Since it is called Volume Shadow, the object is the Volume (and NOT the disk), so a solution (BTW Third Party) such as DriveImageXML is NOT a disk imaging solution (because it is a drive or volume imaging one) and while "enough" for many purposes it is NOT enough for "bare metal" recovery and an image made with it needs to be "integrated with some other data/through other tools, see: http://www.911cd.net/forums//index.php?showtopic=22984 A backup is - generally speaking - meant for DATA (not for disks, nor for drives or volumes). Just like the above described "simplified image" it needs to be integrated with some other data/through other tools (evidently more additional info is needed when compared with a Volume image). Summing up: CLONE=deployed dd-like IMAGE dd-like image = 100% or WHOLE DISK (including EVERY sector of the disk and thus all Volumes/Drives and all info external to Volumes/Drives) ACCURATE Shadow Copy Image=70% (single volume disk) INACCURATE needs additional (very few) info and or tools for "bare metal" use (info external to Volume/Drive) backup =50% (say) VERY INACCURATE needs additional (not very few) info and/or tools for "bare metal" use (info external to Volume/Drive AND info about Volume/Drive) This said, there all all shades of grey, just as an example this nice tool (severaly misnamed as XXCLONE) does NOT "clone" but provides an "intermediate" approach: http://www.xxclone.com/ But the original question was "without third party tools". Some further considerations are here (hardware based cloning): jaclaz

Just for the record the snippet posted by rulman is simply the same as the one dariods posted, only using (0xFF) instead of (hd32) for the vitual CD-ROM, written in a more complex "conditional" way. jaclaz

NO. "Bricked" is a highly specialized technical term ( meaning that the device CANNOT BE ACCESSED at all. If it is accessible (and up to 57%) it is not "bricked" and not necessarily has an issue with the arm not being able to move beyond 57%, it could well be a (smaller or bigger) bunch of bad sectors. This said, yes , *somehow* the actual device has failed, or is failing and it is not worth (being no valuable data on it) to lose any time to understand what is going on, if not for "fun". It is much easier and safer to get another one. In any case if the "fun" choice is made, first thing is to run the hard disk manufacturer tests on it. Happy you like it , though it is specifically or no or little use, it is simply a poor man's kind of FDISK (and nothing more). jaclaz

Three questions. Is the filesystem FAT (FAT16) or FAT (FAT32)? How EXACTLY haas it been made bootable? If you "inserted" a CD, it should mean that you have a CD drive on that machine , then why do you need to use the complex workaround you described? jaclaz

It's not a "script" issue, it is simply a non acceptable character in a filename... http://en.wikipedia.org/wiki/Filename You should replace them with (for example) - (minus or dash) or _ (underscore). jaclaz

The problem you see, is that - basically - a clicking disk is usually connected to some "calibration data" lost. A PCB swap (remember that for these disks a "transplant" of the ROM is also needed) is likely to have no effect whatsoever. Both the freezing and heating (together with "percussive maintenance") are in my view mostly more (shamelessly copied sentence): inner working. If you have nothing to lose (like a bricked disk drive BUT all your data safe in a backup) there is nothing bad in trying them, at the most the disk will remain bricked. BUT if you value the data on it, simply DO NOT EVEN THINK of doing anything the like. It is another thing in common with the medicine field, if you have a disease for which there is no cure today, your best bet is to be able to survive the time needed for a cure to be found. If you need the data and you need it now, I am sorry for you but the only way is to go to a professional and pay him/her a dear price to recover the data )if possible at all). Make sure, double sure and triple sure, if you decide to go this way, to verify the credentials of the professional service, as I suspect that there are more then a few self-defined recovery experts around. The risk with them, besides not having the data back (if possible to recover them) is that they could by mistake do something to the drive that would prevent furrther recovery by a real expert, conversely your attempts - if for any reason "wrong" - may do the same or, in the best case, increase the estimated cost for recovery. The PCB when disconnected from the mechanics (but of course powered through the SATA cable) should anyway be accessible from terminal, if it is not either the PCB itself has some issues or the TTL adapter/serial/usb you are using to access it have one.... jaclaz

Well , if Lord Wolf and allen2 CANNOT possibly have one of those, they don't exist and they weren't talked about in this thread until you revealed "Confidential" info .... . jaclaz

And guess WHY there is written "Confidential" on it? I would guess to avoid admitting even the existence of it When you get it you should have signed a document with the Fight Club rules : Seriously, the only TWO types of CD discs that you can have (unless you are an OEM) are the ones mentioned in the article, the one white with "Confidential" on it should not be available anywhere, as it is simply a sort of "master". jaclaz

Well, but what you actually did was that you installed XP TWICE, which is another thing, nothing connected to "image" or "clone" and not even to "backup". And, unless you ARE Microsoft, I would consider VCDControlTool.EXE + VCDROM.SYS "Third Party Apps" (unless I am mistaken they are not "inside" the XP install CD ) as well, and ANYHOW they need to be "installed". Anyway, glad you solved your problem . jaclaz

Not really. OEM discs are of two "kinds": the "BIG" OEM's like HP, Dell and the ike the "small" OEM See: http://www.tek-tips.com/faqs.cfm?fid=4004 While the first are "modified" to work on a given machine and often will have a protection, slic or whatever, the second one are "normal" XP discs, but coming with a OEM license (and an OEM serial). The OEM license simply "ties" the license to the actual piece of hardware bought with it, there are (or at least were) a lot of places where yu could buy an OEM disc and original license togeter with a floppy disk or a stick of Ram.... Selling an OEM license with a "trivial" piece of hardware is already "stretching a bit" the terms, but there are a lot of XP OEM's sold even without any hardware. jaclaz

If it's clicking, most likely you cannot do anything about it (i.e. it sufferes from a different illness from the ones we have a cure for). But still, you should be able to access the terminal normally, and send commands and have feedback from it. If you don't then you have most probably an additional issue in your setup/connection or an actually "fried" PCB (this latter is unlikely, but possible). jaclaz

Sure, it was just an occasion for a quick laugh , though the "aggressive" part has always been there and waiting a week or so before allowing it to install certain updates has always been a good idea, that is if you are concerned about "stability". Example : jaclaz