jaclaz

Naah, actually very indirect way to say that YOU will not be able to do that very easily, while actually saying it . But this is not intended to put you down in any way , since I have a few years of experience with all the mentioned tools (and also a few years of supporting people on various boards on similar topics), I think I know quite well the difficulties that you may face, and I find only fair to you to tell you my opinion, expecially since I previously suggested what I still think was an easier path to get the result you asked initially. You shouldn't take my approach as rude (it is not meant to ) it is simply a matter of (declared BTW) grumpyness and pickyness, but still with the end goal of actually trying to help you solve your problems . jaclaz

Oh, yes, they are very different. Try making a boot CD of both, then compare them. Specifically, UBCD is (mainly) DOS based and has most (if not all) Manufacturer's Hard disk diagnostic tools (which is part of what you asked for initially), whilst UBCD4WIN is (mainly) BartPE based, has NOT ANY Manufacturer Hard disk diagnostic tools. The former is "self-contained" the latter needs an original Windows XP (or server 2003) installation media (and an appropriate license). Also, measure the time one and the other takes to boot.... Carpenter's comparison (if needed) : Waiter come taste this soup: http://www.imdb.com/title/tt0094898/quotes?qt=qt1099763 UBCD ALREADY has Seatools (for DOS) included which is what you asked for. UBCD4WIN has NOT Seatools (for DOS or for windows) included; adding them to it may be easy or difficult, but is anyway additional work that - since you are a self-declared n00b - raises the necessity for you to quickly become and ex-n00b in order to be able to perform this task. For the record, I talked about a (CD compatible) bootmanager: giving two common examples, both capable (as stated) to load floppy images (DOS, Linux or other OS) and an already built tool (still as an example) that makes use of this approach (CD compatible bootmanager and severla floppy images) that coincidentally also already contains, ready for use both Memtest and Seatools. Ultimately I am very happy that: you found what you wanted you have chosen to experiment and become a non-n00b but still my pickyness makes me clarify how: you initially asked a question that question was properly replied to you substantially ignored the given answer and found yourself another answer to another question (which you never asked) jaclaz

@Dogway Well, I am usually grumpy , but sometimes I feel like it is well justified. You asked a question, I gave a proper answer to THAT question, pointing you to the UBCD as an example to try, and you first go astray with UBCD4WIN (which is ANOTHER thing VERY DIFFERENT from UBCD and totally UNrelated to your original question) and then you ask if UBCD (which is what has been suggested for you to try FIRST) is "for linux" ? Sometimes I feel like the Chewbacca Defense: http://en.wikipedia.org/wiki/Chewbacca_defense was originally inspired by forum threads like this .... Anyway happy you got the whatever you were looking for (and didn't ask about) . @Ponch Sure , just nitpicking a little (and yes, besides being grumpy I am also picky (and cheap , but that's another story). @allen2 Being picky, I find the link you posted to be strangely similar to the one that was already suggested in post #2. (as in "already suggested" and "already ignored") jaclaz

Technically (specifically for the two mentioned tools) it doesn't make a difference if using a floppy image or a cd image, and even more technically BOTH the mentioned thingies are available as floppy, by means of ways to create one or by extracting the floppy image from the .iso. Specifically: SeaToolsDOS220EURO.144.ISO <-contains a "normal" 1.44 El-Torito floppy image SeaToolsDOS223ALL.ISO <-contains a no emulation bootsector (actually using BCDW) and a "special" floppy image 5,898,240 bytes in size i.e. a 4x1.44 image or 5760kB still compatible with both grub4dos and syslinux/isolinux/memdisk. http://www.memtest.org/ But again the memtest86+-4.20.iso.zip simply contains an El-Torito floppy image 1.44 Mb (and El Torito floppy emulation images can be easily extracted from .iso with 7-zip among other tools). Not really. Personally it makes little sense to make a CD with a software to emulate another CD (the .iso) that actually emulates a floppy, and I would go "directly" to a CD that emulates a floppy....(actually two) Again NOT really. The Seatools run under FreeDOS and may (or may not) work under DOS but you can have a DOS menu in FreeDOs allright , but Memtest not only doesn't run under an OS, but it also uses NOT a "known" filesystem on the floppy (or floppy image) from which it is booted. jaclaz

Let's open a few scenarios: the unbricked drive is 100% (or 99.99%) functional (percentage of "good" data) and the only issue is a single sector that was corrupted/wiped/whatever the unbricked drive is (say) 55.32% functional and the remaining 44.68% cannot be recovered in any way the unbricked drive is (say) 55.32% functional BUT the remaining 44.68% can be read/imaged BUT NOT fixed (made accessible) while still on the same drive in any of the above, the recovering procedure introduces some "fixes", and either by mistake or by "wrong suggestion/approach" (or by bad luck/Murphy's Law) these "fixes" may cause a chain reaction that deletes (or anyway makes not anymore recoverable) more data in any of the above cases, since the drive has "bricked" itself at least once before, AND we don't know the exact reason why this happened there are MORE probabilities that it will re-brick itself soon, AND, since the unbricking wasn't actually really entirely successful - which could BTW mean that the cure for a "specific" illness by pure luck temporarily and partially cured the actual different unknown illsness the drive suffers from - we have NO idea if a further UNbricking will be possible at all . Obviously if you are in case 1. or 2. having an image is only a precaution and not really *needed* (whilst anyway advised). If you are in case 3. making an image/clone starts to make more sense. BUT since cases 4. and 5. apply to ALL the previous ones the idea of making an image/clone starts to look like a really *needed* step.... Mind you Murphy's Law could well apply to the actual cloning procedure or to the "target" drive that while you are imaginfg to it - for any reason - decides to brick itself (or right after you have concluded the imaging).... ...and it is also possible that the drive has only a total of (say) three hours of life left which could be used more usefully in attempting to recover selected key data instead of "wasting" them cloning an area of the disk that contains unneeded data..... The imaging/cloning procedure is the "standard" one as it has been the one (normally) being the less risky, but there aren't guarantees on any kind that it will work "better" than a "direct recovery" attempt or that it will work at all, if the cloning works, at least you have a "second chance", nothing more. Decisions, decisions always decisions..... While the disk cloning is running you should be able to start getting a few "key" sectors from both the source and the target drive, not knowing the specific software you are now running I cannot swear it will be possible but it should (i.e. the disks should not be "locked"). If you could get by using HDhacker: http://dimio.altervista.org/eng/ the MBR (first sector of the \\.\PhysicalDrive) or alternatively use the rawcopy as mentioned earlier: Actually if you could get with the rawcopy the first 100 sectors of the disks (both source and target disk) by using: (twice once for the target and once for the source) we could have already have some data to look at and also have a way to verify that the cloning is working (at least for the initial 100 sectors) But again it is difficult to say , though UNprobable, it is possible that performing this action may somehow "disturb" the ongoing cloning.... jaclaz

Yep, one of the "key" requirements for disk data recovery is "patience" (the other one being "perseverance" ). BUT do check, by just feeling it with a hand, if the disk is warming up "too much" (a highly specialized technical unit of measure ) and if it does add a fan to help keep it cool. Oww, come on MacGyver wouldn't cry : Link to image (for some strange reason the board doesn't like this image's name) jaclaz

It seems to me like the OP asked a slightly different question , i.e. something like: which the given link also answers , but that was seemingly partially wrongly understood as there are actually TWO "Windows\CurrentVersion\Run", one under HKEY_CURRENT_USER and one under HKEY_LOCAL_MACHINE and BOTH are not within the items said to run entries alphanumerically: So according to the mentioned post there is no way to determine the order of items in 8) or 9) .... as while it is possible to *somehow* give a loading order to: 10) C:\Documents and Settings\All Users\Start Menu\Programs\Startup 11) C:\Documents and Settings\Your Name Here\Start Menu\Programs\Startup it is not possible to give one to: 8) HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run 9) HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run If the scope is to assign a given order of loading I think that the solution is using a third party app, such as (example) oolauncher: http://oolauncher.deskangel.com/ jaclaz

As a matter of fact I think that it doesn't work "at all" unless the keyboard issue has been resolved in the meantime. No. Meaning that there are several way to send a reboot command, it may depend on the particular way/specific tool or command you use to send it, and there is also the issue of "warm" and "cold" reboots. jaclaz

Sure, you need a bootmanager like grub4dos or syslinux (actually isolinux). Normally such dos tools are written to CD as "floppy images" that the bootmanager loads like if they were floppies. If you get the UBCD: http://www.ultimatebootcd.com/ you have a fair example of hhow such a CD works. jaclaz

...which is seemingly the known fake OSCDIMG re-adapted as seen in the thread before mentioned: http://forums.mydigitallife.info/threads/2132-CDIMAGE-2-54-(NOT-Fake)/page2 Everything seems to lead to the conclusion that a CDIMAGE.EXE version 2.55 does NOT exist (the last one - and BTW "reserved for Microsoft internal use" - being version 2.54) and that out of the blue a NEW utility has come to life, OSCDIMG.EXE and it's first version released is ALREADY version 2.55 (and is not anymore "reserved for Microsoft internal use" BUT "Licensed only for producing Microsoft authorized content."). I do love concidences.... jaclaz

Well, ATA means both "PATA" and "SATA", I wouldn't see that as a problem, and anyway a "normal" (P)ATA 133 is comparable with a SATA I (150) when it comes to speed. You never know the speed you can have on a program (unless you are already familiar with it and have some experience). Much more than that, you are doing the first step of data recovery and the source drive is NOT (evidently) fully functional as it was a bricked drive, later unbricked. It is also possible that you are hitting a particular zone with "bad" (or - actually worse for speed - "half bad" sectors) and the tool is slowing down to try (desperately) to read them sectors. There are too many variables in your setup, there is nothing "wrong" at first sight but the interaction of a number of "not known" or "not tested together" items may lead to "whatever". And mind you it is very possible that by using the recommended OS and tools you would have exactly the same speed as the issue is the source drive (or the target one, or a cable or a hardware interface, or in *something else* that I didn't notice ) ... The "advantage" of using a command line tool (over an "easy" GUI one) is that you can try to image a small part of the disk, see what happens, try with another area, stop and resume, etc.. Really cannot give you any meaningful advice . jaclaz

I have NO idea what you are talking about. What do you mean by "jumbper blocks"? The connections for the 7200.11 are CLEARLY pictured in the first post of this thread and on the currently recommended unbricking guide: http://www.mapleleafmountain.com/seagatebrick.html if by any chance you have not a bricked 7200.11, you posted on the WRONG thread, this one is RESERVED to ONLY bricked 7200.11 recovering procedures (and ONLY from a BSY or LBA state), if it doesn't apply to your stuation please start a new thread. jaclaz

Yes/No. It greatly depends on how the recovery cd is made. Generally speaking you have two possible ways: recreate (if possible) a "standard" or semi-standard install CD (and from it create an unattended install) create your own "recovery" CD for your already installed and configured machine BUT, specifically an "install CD" for Windows Embedded (2009 or other release) simply does not exist. Windows Embeeded is a "building environment" in which you "assemble" various components and the result is not an "install CD" but rather a "target image", i.e. the result is an image of the "already installed" system. In many cases the result that you get is a step before a "fully installed system", something that needs a "first boot" to complete configuration. If you need to re-install often, I think your best bet is to make a "recovery image" (i.e. a an image of the running system) and re-deploy it. jaclaz

Good, that was the expected result. Which should mean that what is actually used (and that is confirmed by the log) is the align=4. Now the difficult part is to find where it is (inside .exe/compressed/whatever) I have no way (since as you have find out the documentation is "flaky at best") to confirm what I posted, (re: allowed values) but 0 is NOT among the ones presumably allowed for the align=n, it is very possible that the thingy, finding 0, assumes 64 and "overrides" the offset=m value of 32. Sure, it all depends from the character of the programmer , if I had written that executable, when you would input a non-allowed values a little hand would come out of the screen and slap you hard in the face, and in the meantime the loudspeaker would tell you how you are a moron for not having RTFM!. The usual character of MS programmers (of course there are exception and a lot of nice guys among them) is based on an assumption (actually three of them): we are waaay smarter than you we know better than you whenever you use something that is not documented properly (please read as *anything*) the program will do what is better for you, WITHOUT telling you (otherwise you may learn something) jaclaz

Multibooter with all due respect , you are failing to understand some "basics", a connection is made with two connectors, one female and one male. For the connection to work (i.e. for the two devices at each end of the connector to talk to each other THREE conditions must be met: mechanical compatibility of the connectors electrical compatibility of the cabling protocol compatibility of the devices If any of the three are not met, the assembly won't surely work and additionally, if #2 is not met, it is likely that one or the other or BOTH of the devices will be damaged. A typical example is the RJ11/RJ45 connectors, you are used to see them respecitvely as telephone connectors and ethernet connectors, but a number of ISDN lines will use a RJ45 with a different cabling) and, as another example, most Cisco devices use a RJ45 socket to connect the "console cable" (which is actually a RS-232 serial). http://pinouts.ru/Net/Ethernet10BaseT_pinout.shtml http://pinouts.ru/Net/isdn_bri_pinout.shtml http://www.cisco.com/en/US/products/hw/routers/ps332/products_tech_note09186a0080094ce6.shtml It is not like the first RJ45 socket you see you plug in it a RJ45 cable and connect the other end to any other RJ45 socket equipped device you have around. jaclaz

Yes and no. There is *something* though whether it is working (or will work ) and specifically it will work on a PE (and on a PE 3.x specifically) is very hard to say. Here: http://www.ohloh.net/p/winkexec http://reboot.pro/7391/ https://www.jstump.com/projects/kexec/wiki https://github.com/Sha0/winkexec (different projects/versions/tests/whatever) I do fail to understand the *need* for such a thing in the depicted scenario, WHAT is the problem with rebooting and load the "other OS"? Just the "convenience" of using the HTA menu? Then you can probably tweak it to alter the rebooting (change the item booted by default in the pxelinux .cfg) and force a reboot, but it still seems to me a way to make one's life more complex thean needed... jaclaz

I don't get it. It seems like a nice experiment, though it makes to me little sense (both in the actual contents and in the way the results are presented ). I used a (totally arbitrary ) standard that sets m as the variable for the offset command and n as the variable for the align command and you used n for BOTH? The allowed values m for the offset command are seemingly: What you have found is that if you use any other value it will be rounded up or down to the next allowed value BUT that there are a few allowed values not listed in the above . Here are in green the above "known allowed values" and in red the "additional ones you found": 32 64 128 192 256 320 384 448 512 1024 2048 Most probably there are more such values in the range beyond 512 (that you have seemingly not explored). Why have you not tested m=32 ? Why have you not tested the three lines I posted? (just to see if theory and practice are the same - by pure chance) create partition primary offset=32 align=4 create partition primary align=4 create partition primary align=32 I am pretty sure about the "create partition primary align=32" : http://www.msexchange.org/tutorials/disk-geometry.html resulting in a partition starting on sector 64, the other two are the ones to check. The allowed values n for the aligncommand are seemingly: What you have found is that there are a few allowed values not listed in the above . But you started with a "not allowed" value of m=160 (which probably results in a 128 ), so I don't think that your results are - if not for the "allowed" values - following a "logic", it is more likely that they are a "side effect" of using such non-standard values (if you prefer a "bug" in the parsing mechanism). jaclaz

You seemingly are a rich man , see the price of these (which should be the "equivalent"): http://www.rrdatatelecom.com/cgi-bin/rrdata/L1167 More of the same "kind" (seeemingly called "card edge 34" or "CE34": http://www.rrdatatelecom.com/cgi-bin/rrdata/CE34M-M http://www.rrdatatelecom.com/cgi-bin/rrdata/CE34F This should be the type you have: http://www.rrdatatelecom.com/cgi-bin/rrdata/L1065 If you have some unused cables (female) they could also be of use : http://www.scienceprog.com/sd-mmc-card-fits-in-floppy-connector/ jaclaz

I would think this is a potential problem then, is it? Too bad because I like the fact that the UI gives information about the disk which means that one can easier recognize which disk is which... Not really, really that's the way *all* tools should behave (when dealing with data recovery). Basically when you hit a bad sector, a "normal" tool will throw an error and abort or "insist" trying over and over on that same (bad) sector (and thus "stall"). A recovery oriented tool will try a few times to read the bad sector (let's say 5 times) then will understand that the sector is actually bad and write to the target a sector full of 00's INSTEAD and continue to the next sector. If there is a bunch of bad sectors in some cases it is advised to avoid also the (say) 5 times try on each of them (which will slow considerably the imaging) and simply "jump" a little bit further (and possibly later trying again that zone "backwards"), that is the idea of the DatarescueDD. jaclaz

Opening a command prompt and typing in it: will give you all the information available (which you should anyway test yourself). The syntax is similar (though not identical) to many other programs that do the same thing, the "archeotype" of them is "dd" see (only to learn some history and possibly to get a quick laugh ): http://reboot.pro/15207/ Basically dd takes a source and copies it to a target based on offset/position/address without caring about the contents. The other programs I suggested you before are either "more suited to data recovery" (they use some specific "strategy" to attempt reading the data in case of difficulty and/or "give up" after a number of failed tries and write to the target a 00ed sector instead of throwing an error) or " Exactly. For "normal" use, i.e. NOT for "forensics" or "data recovery", ignoring some data (which are unneeded for these other than foresics or data recovery scopes) will allow a number of advantages, like faster operation, smaller images, etc. a quick sum up is here: You are welcome, actually the fact that you are "new to the field" is a good thing: it means that you never faced a serious case of data loss in these years . The app Kelsenellenelvian posted a link to seems like solving the issue in a better way as it is reported to be working (for sure) on 7 both 32 and 64 bit. jaclaz

I would say that, more than that, by using Vlite in a business/enterprise environment you would violate its (Vlite's) license . In other words, the whole point is that vlite is ONLY for personal use: jaclaz

Therefore, since BlackArmor Backup makes its images/clones/backups/whatever WHILE THE DISK IS IN USE, it was not unreasonable for me to start wondering whether that software would do what I need to have done. S Well, this is flattering you value a single sentence extrapolated from a post of mine in a thread where the issue is "not installed third party" tools more than a whole manual from guys that since several years (I am talking of Acronis, not of Seagate) are among the "top players" in data backup/disk imaging/cloning. When you actually read the manual, you must have missed chapter 3.1: which seems to me like very similar to what I summed up in post #5. Yep , but you cannot play dumb at will . The average Joe would take what the good Acronis or Seagate guys say on the matter as "the one and only thruth" and happily image/backup/whatever his disks, the sheer moment in which you decide to delve deeper, and doubt their word for it, you will need to get familiar with the minutiae . Red pills are better IMHO, but rabbit holes are deeeep : jaclaz

Well NEVER trust anything or anyone! Do a simple experiment. Check the first sector of both the \\.\PhysicalDrive0 and 1 rawcopy 512 \\.\PhysicalDrive0 C:\drive0.bin rawcopy 512 \\.\PhysicalDrive1 C:\drive1.bin Then physically disconnect the "unbricked disk" and redo: rawcopy 512 \\.\PhysicalDrive0 C:\drive0_2.bin rawcopy 512 \\.\PhysicalDrive1 C:\drive1_2.bin If the setup is what you see in disk management you should get two identical files C:\drive1.bin and C:\drive1_2.bin, a file C:\drive0.bin and an error as at the second attempt there should be no drive0 avaialble. As well, to make sure of the n check in disk management before connecting the "target" drive and after connecting it . jaclaz Edit: ERRATA CORRIGE the rawcopy thingy uses bytes and not sectors as "copylength" corrected in the above from "1" to "512"

Then the partition and the bootsector are seemingly OK. Then a good idea would be to image it. The reference app is Datarescuedd, see here: http://reboot.pro/7783/ You might want to do a few tests with "smallish" parts of the disk , see this for a possible approach: http://reboot.pro/15040/#entry133567 I have no idea if it works ok under 7 64 bit, it should, but cannot say. If you have a XP available it should be "safer" (in the sense of "known to be working") Hmmm, strange. It is possible that there is a bunch of bad sectors (or a translation table in the disk that was cleared during the unbricking) but a failed $MFT Mirror should not prevent the filesystem to be recognized . Once you have the image done, we will see what TESTDISK finds about those.... jaclaz

It is "unusual" in the sense that what you report should be related to BIOS drive order (and the way disks are connected to the actual physical interfaces on the motherboard) and normally first disk in BIOS is the "boot disk" and BOTH the "source" (drive to recover/copy from) and "target" (drive used for cloning/copy to) are attached to it "later". The above is the "normal" setup, when you have a fully working machine and you add to it the source and the target disks. On the other hand, if the "bricked" disk "was" a boot disk on that machine and you added a second disk installing to it a "temporary OS" and after the unbricking you placed the "unbricked" disk where it was before, what you report may be "normal". jaclaz