jaclaz

Yes, that is the problem when searchig for "FILE" or "46494C45". On second thought, you could change the hex string to "46494C4530" (same as "FILE0"), it would avoid false positives. If you get t the "right" sector, the string "FILE0" will be, see the mentioned thread: in the top row of the viewed sector. jaclaz

Yes . http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html only you won't like it . The "best" way is to recreate a "plain" XP install CD by "assembling" toghether files that you have either in the \I386 or in the \I386DIST (or possibly, if you have access to the hard disk, on the hard disk). Then you try slipstreaming a servicepack that will hopefully fill any "gap". It is normally perfectly possible and here is a (long and wordy ) thread about a success with this approach and some very detailed steps: http://www.911cd.net/forums//index.php?showtopic=24161&hl= jaclaz

My bad , I was not clear enough. You are now searching for a "hex string", so you need to DE-select the "Find text" checkbox. Sorry for the misunderstanding , you'll need to redo starting from 20848 . At first sight the only thing that may have caused a serious data corruption is the Windows 7 bootrec command (I am not familiar with it, but - as a general rule - never use a tool designed to recover a given OS or another OS), but this does not yet explains the kind of issue you are having. If all the thing that needs to be recovered are the photos, you may ( if nothing works) still try Photorec, but from what you posted about the "poor" quality of the recovered files by the other application, I cannot swear that it could be any better for a "file recovery" approach. HP normally does use a recovery partition, but cannot say right now if this could have influenced anything, I mean that partition, if it was before the "mian" one would probably have been bigger than the current stoopid WIndows 7 partition, so the $MFT should have been at the most "after" the calculated addresses. If there was a HP recovery partition and it was before the main partiton and it was less than 100 MB, then the addresses calculated woould be wrong. Let's see what happens with the search..... jaclaz

Does this HAVE to be done after booting with the card connected on the VL400? I checked the signature and it is 0000 but perhaps this get's changed when booting with the card connected? Also, can I test boot the CF on my PC just to check it's working here or is it important that I only boot it on the VL400? I tested it with MobaLive (Qemu) anyway and that worked fine, so it's probably OK. It doesn't really make any "real" difference. Mkimg/mrbatch were designed to be a helper for further "customizations", and it leaves the disk signature "blank". Such a device won't boot (fully) a NT system (but it should have no problem whatsoever in booting up to the BOOT.INI choices). As soon as a device with a 00000000 signature is connected to a NT running system, at mount time the NT system will write one. You can try booting from it on *any* system, at the most it won't boot, the need to have any non 0 signature is only for later when you will actually try booting a NT system from it. You can either connect it to a system that boots (from another media) a NT based system or write manually any non 0 value to it. Till now we are experimenting only in the "real mode" part of booting, the need for the disk signature is when NTLDR will "switch" to "Protected mode". jaclaz

Personally I would NOT take the car market as very good example of either "intelligent" or "customer driven" or "good" (in the sense of "good for the customer" or "giving freedom to the customer") "marketing strategies". I will cite myself http://www.911cd.net/forums//index.php?showtopic=20983&st=37 The only BIG difference is that on the example car, after you have unneededly payed money for a feature that you will never use, you get for your wasted money AT LEAST a §@ç#ing switch, so that you can keep the "feature" TURNED OFF! jaclaz

I would be less pessimistic than you are, in the sense that from the few sectors you posted I don't have the feeling of a "toasted" disk, sure it may have had a few bad sectors but since the datarescuedd thing got to the end of the disk, it should be substantially "sound". It seems to me like more probable that most of the "damages" have been made (for *any* reason) by the failed attempts at recovery, this is actually the reason why one should always - unless he/she is 100% sure that it is a trivial thing and he/she is positive that it can be solved with little effort - image the disk first thing, as in case of issues there is always a "way back". I am not (yet) convinced that "everything" is lost. You are now mentioning "password", I sincerely hope that you don't mean - by any chance - that the volume was encrypted . I think I am missing something , a $MFT is a "not so little" amount of sectors, it would be queer it has been completely wiped. The "786432*8" is the "default" address for it, if the disk was partitioned/formatted with the "standard" tools. If it is possible that some "non-standard" tool has been used, it may be at another address. If I get right, you have now scanned starting from sector 6293504 all the way to the end of the disk. The settings you have in Tiny Hexer seem correct . Try this before giving up. Do the scan from sector 20848 up to 6293504. Try this time for the hex characters "46494C45" (they are the same as "FILE" in text). Also, it may help me if you could gather (from your cousin) as many details on the "story" of this disk as you can get (like which OS was there, how many parittions, if he changed something, etc, etc.) and if you would provide a (synthetic) list of the actions you attempted on the disk (again with as much detail as you can remember) before making the image with datarescuedd, including the actual name of the apps you have used, and anything that you can remember about what they did or how they behaved. Also, you should check the USB enclosure, it is possible that the "always lit" is the symptom of a problem . But you can do the scan on the image, now that you have it . Instead of File->Disk->Open Drive use File->Disk->Open disk image or large file as drive.... jaclaz

NO, you have NOT followed the instructions (or they were NOT clear enough ). the mkimg batch after the above (the snippet was posted UNIQUELY to let you see easily which values you should have used, that are bolded for your convenience) , continues, and prompts to format the partiton and will also mount it, opening it in Explorer, ready to copy to it the bolded files. Since you were EITHER PROMPTED to format the partition (and you declined the "offer" to format the partiion) OR you got an ERROR of some kind, you should have posted how you had some issues or asking what to do when prompted, wouldn't have this been more logical that "going ahead" and end up with an unformatted partition? BTW, you seemingly already ran this batch successfully, here: http://reboot.pro/16737/page__st__25#entry154146 so I cannot but assume as given that you know how it works jaclaz

Sorry, but is it stronger than me it sounds to me very like : http://www.imdb.com/title/tt0074860/quotes?qt=qt0247572 Seriously now , what do you mean by "safe"? I am really failing to understand the question . I mean, IF the GPU (whatever brand model it is) on your motherboard (whatever brand model it is) has a removable cooler/heatsink AND you removed it AND you want to reassemble it, THEN you MUST use some thermal compound or a "thermal pad". It's not a matter whether it is "safe", it is "unsafe" to not put some thermal paste (or similar "contact media") between a chip and it's heatsink. Or is the question something like is "Ultra Thermal Compound" , I presume this one: http://www.ultraproducts.com/applications/SearchTools/item-details.asp?EdpNo=3298395&Sku=ULT40124 good/better/worse than <<put here another product>>? Maybe if you explain your question a bit more, providing some background ad details, you will get a "bettered targeted" answer . jaclaz

It depends on BOTH printers and drivers , in my experience: "basic" drivers (like the ones that already ship with the OS) can be installed allright with no printer connected. a number of "manufacturer" printer drivers require (not the actual drivers in themselves, but rather the completely senseless install programs and "add-ons" and "advanced control panels" and "complimentary apps") to have the printer connected (some go into the perversion of needing to be starting the install WITHOUT the printer connected BUT asking you to connect the printer at mid-install ) I seem to remember a printer, of which I won't mention the brand name if not to say that it was (almost surely) an Epson that had issues in installing the drivers because it "sensed" that one of the colour catridges was empty , cannot obviously remember the model. jaclaz

I Have Many More Goals Than You Have, Among Them, Ranked Like 287th , To Show People How CAPITALIZING The First Letter Of Each Word Looks Silly And Disturbs The Reading. English is a very "plain" language, there are only a few words that should be Capitalized: http://en.wikipedia.org/wiki/Capitalization all the others should be not. To become (hopefully) an employed computer/network security expert, you may want to to start taking good writing habits, it's a little thing, but I know many people (myself included) that won't even consider someone that produces a Capitalized text. let alone hire a free-lance with the same writing approach. But Welcome Anyway On MSFN . jaclaz

Please allow me to put "comparative terms" into perspective. let's say that in year 2000 I had *some* activity, let's say a line producing bowling balls that had a cost of energy that (net of inflation, depreciation or whatever) can be ranked as 100% let's also say the producer of the bowling balls machinery tricks me in updating the line in 2001 and that the new line after n months of lesser productivity finally gets to have a 105% cost of energy BUT that actualy produces 111% of bowling balls. after n*m years I may become "even"with the lost production in the initial months, thank to the increased features of the new production line let us also assume that in 2006, while I was away for (a long sought after after 5 years) six day vacation my partner in the bowling ball business is tricked by the same guy into updating to a new production line, that after n months of lesser productivity, continues to provide lesser productivity all year round AND has a cost of energy of 125% let us then say that in 2009, with the firm on the verge of default, I am again tricked by the same guy into updating the machinery (yeah, I am gullible ) ,but this time from day one production increases and soon returns to 2005 levels with a cost for energy of 124% now, three years have passed and the same guy tells me that a new update to the production line may produce the same but have a relevant saving in energy, for which not actual real estimation has been done, but that is presumed to be something like 105%. This is a dramatic decrease of the cost of energy, as 1-1.05/1.24=15.33% but, what I actually am at is the SAME production level and SAME energy cost of years 2002÷2005, and a WORSE ratio cost of energy/production rate than I was in 2001 BALLS, BIG BALLS (of steel or other hardish materials): jaclaz

NOT only elementary, also much VAGUE if not plainly WRONG. There is NO DIFFERENCE whatsoever in the BPB between a bootsector created on the SAME device by the SAME OS by any "proper" tool, on partitions marked with ID 0B or 0C, http://www.win.tue.nl/~aeb/partitions/partition_types-1.html this is still connected to the PLAINLY WRONG idea that a Partition ID is anything more than a Partition ID, see: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/determining-filesystem-type.html and - if we are talking of actually booting from that partition - the H and S correct values are VITAL on Windows NT systems, because of some "botched" or "relic of good ol' CHS days" in the actual bootsector CODE (and this applies to NTFS too). See: http://www.911cd.net/forums//index.php?showtopic=21702&st=129 The whole idea of calling a FAT32 "FAT32X" is "botched", there is only a FAT32 filesystem, that can be accessed through BOTH CHS and LBA if below the CHS limit or only through LBA if over it (both in size and position on disk). But the question by pointertovoid was about "FatX", which is a particular filesystem for the Xbox: http://en.wikipedia.org/wiki/File_Allocation_Table#FATX that has clearly nothing to do with FAT32 (and with this thread) and FAT64 does not simply exist, it is the WRONG name given sometimes to exFAT: http://en.wikipedia.org/wiki/ExFAT jaclaz

Hmmm. One of the sectors is all 00's that may mean almost anything including the effect of the same thing that wrote B702 that could have wiped it, but the other one does contain some binary data (though not a $MFT mirror) it is unprobable that the whatever happened wiped one sector and wrote garbage to it's mirror. It is much more likely that we are going to a wrong address. Could it be that the first "100 Mb" partition is an artifact (of some kind) created by any of your previous attempts? If this is the case, than logically there was before a "single" partition and then it would have started at the "default" (for Vista ) 2048. Try again with sectors: $MFT: 2048+786432*8=6293504 And it's Mirror at: 2048+61035263*8=488284152 Otherwise, a good idea could be to open with Tiny Hexer the disk, goto sector 6280000 then Edit->Find/Replace->input "FILE0" (please note that tis is CaSeSeNsItIvE), make sure that you have Text mode checked and "Dos 8 bits", then click on the "Find" button, at the prompt click on "Yes to all". This might be a very looong step before you get a "hit". Compare with this thread: jaclaz

Yes , problem being at WHICH end? This may help (this is how a floppy cable looks like and which end is which ): jaclaz

I don't see any senceful question, elementary or not. What the heck is "FatX"? jaclaz

Yep . The backup sector is completely wiped and a "queer" B702 is written to it at the beginning. Also the "main" bootsector has this strange B702 "incipit". I wonder what the heck may have caused it. DId the image complete successfully? This is "vital" since we will start actually writing to the disk, and if the image is not good we will have "no way back" . At this point easier would be to try writing a BPB, but before it I would try two things: check if the $MFT main record is "where it should be" check if it is valid (or if it has been overwritten) The main $MFT should start at: 206848+786432*8=6498304 And it's Mirror at: 206848+61035263*8=488488952 So, open the disk in Tiny Hexer, open the Physicaldrive, goto sector 6498304, it should begin with "FILE0". Goto sector 488488952, it should also begin with "FILE0". IF (and ONLY if)the above is correct, then goto sector 206848 and overwrite it with the sector in the attachment (with the physical drive open, goto sector 20848, open file 206848mod.bin, "select all", copy, select the physicaldrive sector, select all, paste, then close the physical drive, and say yes to the prompt to save the change). Now if you try opening the drive in Explorer, you should be able to browse it's contents (if there are not any further damages). Report. If you have ANY doubt, ask for clarifications BEFORE doing anything! jaclaz 206848mod.zip

Well, as I see it we miss a "core" requisite in computing, which is "repeatability". We have *any* number of different people that use (very often for the first time in their life) *different* or *slightly different* sets of instructions to do some *magic* on different disks (different serial/models, different period of manufacture, different factory, different firmwares, different PCB's versions and much more than that possibly different "root" issues) and that normally report (WHEN they report some details) only partially the info about the recovery they succeeded with, and in many cases this info is missing alltogether or plainly wrong. Now if there was a repeatable way for a same experimenter to "intentionally" brick a number of *same* disks (same model, same period of manufacture, same factory, same firmware, same PCB version) in EXACTLY the same manner, and the results of these tests were confirmed by another independent experimenter, then we would have some certainties. As a matter of fact we are currently (at least I feel like being) much more near to http://en.wikipedia.org/wiki/Traditional_medicine than to: http://en.wikipedia.org/wiki/Medicine Not completely unlike a tribal wizard or sorcerer, we provide our experience on similar cases, not really knowing what the heck happens when we apply the "cure" nor what has happened before (the cause or origin of the illness), only knowing that in some, similar cases with similar symptoms this particular spell has produced a positive effect . The disagreement was only related to the fact that both of you presented your opinions or (educated ) guesses, as "only and undeniable truth", while they are - at the most - the (diverging) results of your experience and/or observations. http://en.wikipedia.org/wiki/I_know_that_I_know_nothing jaclaz

MInd you this is my PERSONAL view on this (so take it as a simple comment) : Office 2000 is a bettered Office 97. Office XP (2002) is a bettered Office 2000, only more buggy. Office 2003 is a bettered office XP, only worse. (but you will get by default the new .docx and .xlslx formats without needing an add-on) Office 2007 is a bettered office 2003, only worse. (and you will get the nice ribbon interface with it, i.e. your pre-existing productivity will drop by at least 80%) Office 2010 is simply "senseless". Also (and as a side note): http://reboot.pro/8898/ http://www.oooninja.com/2008/05/openofficeorg-microsoft-office-moores.html in my experience I have rarely seen bulky and bigger *whatever* move swiftly and faster than lean, smaller *whatever*. Now you know what to do: http://www.imdb.com/title/tt0097216/quotes?qt=qt0362962 jaclaz

@BlouBul @smandurlo It is so RARE an occasion to be able to disagree with BOTH of you that I cannot miss it . You seem to forget how the "solution" is actually the solution to an original quite "narrow" problem, or actually is/was a cure for a single, specific "illness" that presents/presented with two specific symptoms (LBA0 and BSY). At the beginning of this story, we knew for a fact that these Seagate disks had this "congenital" disease, that presented itself with these symptoms. But the cure was intended for the illness, NOT for the symptoms (if provoked by another illness). Let's take Aspirin as an example. http://en.wikipedia.org/wiki/Aspirin#Medical_uses Aspirin is good for "common cold" and consequent fever. Aspirin is also very good for "rheumatic fever". BUT it is NOT a cure for *any* fever and actually doses to cure the two different kind of fevers above are VERY different AND the time needed to have a positive effect varies. A patient having a "common cold" will be threated with Aspirin for (say) three days with relatively low dosage. A patient having a "acute rheumatic fever" will be threated with Aspirin for one, two or more weeks with relatively high dosage. If you prefer the same "cure" when applied to different illnesses will produce beneficial results in different times. We know (or presume to know) that when we apply the "solution" to a disk that is in either BSY or LBA0 BECAUSE of the original log position issue, the message comes out in a few seconds. We also know that in some cases the time needed to get to that message is much longer. This could well be because these latter disks (expecially if recent and not being affected by the congenital "factory + SD15" issue) have another illness, let's call it "rheumatic fever", that - by pure chance - has the same symptoms of "fever", BUT that is NOT caused by "common cold". It is also well possible that the "optional power down" is not-so-optional when curing "common cold", but it is vital (or completely unneeded and possibly counter-productive) when curing "rheumatic fever".... jaclaz

Strange. Maybe it is a USB 1.1 port? The difference would be bigger, I think, as 480/12=40 It is very possible that the "progress bar" or "remaining time" (or whatever) of the *whatever* copying app you are using is inaccurate, like: http://windows7professional.wordpress.com/2010/01/06/windows-8-lets-fix-time-remaining-on-file-copy-once-and-for-all-it-is-about-bloody-time/ Also strange. Once you have finished the image/copy of the file, do post the MBR and VBR, as per the other thread, you can use Hdhacker for this. jaclaz

That is strange (250 GB in 12 hours is SLOW). A "normal" imaging/copying rate on modern hardware is usually above 20 Mb/s, i.e. around 120 Gb/h. HOW (through which means) are you doing the copy? If you are not using an extremely slow connection/bus (maybe you are doing it through the lan/network?) it could be a sign of possible issues. Normally there is no risk to lose data, but if not otherwise justified it may mean a sign of some issues with the actual disk(s). Naaah, we do it for the glory . But of course, you would be very welcome (of you want/can afford it) to contribute to the "forum bandwidth/hosting/etc. costs): http://www.msfn.org/board/index.php?app=donate&do=setup_donation (though appreciated you won't have a "better" treatment, though ) No, if it is - as I presume - a "hardware RAID". Should it be a "software" one, it may . jaclaz

We are doing something very similar right now here: From the screenshot you posted, you are NOT having a "partition table" issue, so "write" will simply write the SAME (already valid) values (no difference). What you should check, like on the mentioned thread, is the bootsector or PBR/VBR of the parition/volume, either manually or following this: http://www.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair#Rebuilding_An_NTFS_Boot_Sector_On_An_NTFS_Partition Recovering An NTFS Boot Sector On An NTFS Partition Using Its Backup jaclaz

The good news are that now that it s the "right" MBR, we have some data to check #0 07 00 0 32 33 12 223 19 2048 204800 #1 07 80 12 223 20 1023 254 63 206848 976564224 The bad news are that you are not (yet) doing EXACTLY what you are told to . What I said: what you did: Of course there is no consequence in this instance, you just got more data than what were needed , but when you will get to direct disk access through Tiny Hexer or Testdisk, doing thing EXACTly or "almost exactly" may make a difference . Now you need to access the disk with Tiny Hexer. File ->Disk->Open drive -> (select the RIGHT PhysicalDrive) -> OK File ->Disk-> Goto sector/position-> (enter 206848) ->OK File ->Save as->Sector206848.bin File ->Disk-> Goto sector/position-> (enter 976771071) ->OK File ->Save as->Sector976771071.bin Tools->Compare->Compare (You should find a number of bytes highlighted as different at the beginning of the sector) In case you are wondering, 976771071 comes from 976564224+206848-1=976771071 the NTFS filesystem stores normally a backup of the first sector as last sector of the Partition/Volume allocated space or - if you prefer - as first sector after the end of the filesystem, which is always one sector less than the Partition/Volume allocated space. Compress Sector206848.bin and Sector976771071.bin and post the .zip jaclaz

These could actually be "good" news, in the sense that if the MBR (as seen in diskpart and in disk management) contains "valid" data, it should be easier to find the backup bootsector... BUT, there are some strings attached IF (as it seems now) the disk has two valid partition entries, the "single" VBR you posted is only one half (which one? ) of the story: 1 disk drive=1 MBR 2 partitions/volumes/drives on it = 2 VBR's Actually I was wrong (but not on the main issue ) I checked and while: Hdhacker Tiny Hexer Diskpart Disk Management number disks starting from 0 Datarescue does number them starting from 1 so the 4 that becomes 5 is OK . STILL, one MUST be careful with the math : jaclaz

Again, NO. The MBR you posted DOES NOT contain info about two partitions, one around 100 Mb and one around 465 Mb, the one you posted, that I have NO WAY to verify it belongs to the "problematic" disk, has a SINGLE partition, evidently with a wrong size (around 2 Tb) OR it is the MBR of ANOTHER DISK! I cannot say if the disk that ddrescue is imaging is the SAME disk that you accessed first with diskpart and then with disk management, what I can tell you is that these latter tools BOTH show a VALID partition table WHILST the MBR you posted did not. You have right now: too many OS's (XP and 7) too many disks (seemingly 8 of them) and you are using too many different tools (possibly under the two different OS's) this is likely to create confusion . Let's do it like this : STOP whatever you are doing. (of course let datarescuedd finish the image) use ONLY the XP (and NOT the Windows 7) run again Hdhacker to save the MBR (first sector of PhysicalDrive) of the disk that you think is the failed one, save it like MBR_disk_n.hdh run ddrescue on the disk that you think is the failed one, saving only 1 sector (lower fields Start=0, Size=1, End=1) to file image[0-512].dd run tiny hexer, use the file->disk->open drive to open the disk that you think is the failed one (it will auto-set to load one sector at the time and will open on the first sector) choose File-> Save as and save it like MBR_disk_n.thx compress the three resulting files into a zip and post it as attachment. (if the three files are not IDENTICAL there is an issue of some kind) jaclaz