jaclaz

Well, that is your fault. Windows 7 booted from a VHD is in no way different from a Windows 7 booted from a "real" partition. It will attempt to take possession of your PC (all your base are belong to us ), it is your duty - and you should know that by know - to keep it busy/entertained in such a way that it doesn't get bored and starts doing random maintenance tasks. jaclaz

See: http://www.msfn.org/board/topic/107504-integration-of-intels-sata-ahci-and-raid-drivers/ jaclaz

Basically. A FAT32 table is nothing but a "sequence of groups of 4 bytes, each pointing to the next group in a chain, and each representing a cluster". Each sector of 512 bytes contains thus 128 of such "groups" A valid bootsector contains (related strictly to the filesystem) 6 pieces of info: how many sectors are before the beginning of the volume <-this is the same info that you can get from the MBR, i.e. 63 how many sectors are reserved <- this are the very beginning of the volume and correspond to the bootsector itself, plus "auxiliary sectors", like the backup of the bootsector, code (in the case of a bootable volume) exceeding the bootsector, etc. the cluster size <- number of sectors that are indexed "together" i.e. 64 how many FAT tables there are <- normally 2, in some rare cases 1 how many sectors are "dedicated" to the FAT table <-these need to be "enough" to index the whole amount of clusters in the volume how many sectors are in the whole volume <- i.e. "size of the volume", this is the same info that you can get from the MBR, i.e. 1953520002#1 and #6 are not a problem (as we got them from the MBR) #2 is a guess, but a - allow me - very educated one, as when a volume is "large enough", 32 reserved sectors are common AND we found what has the aspect of a second sector of a FAT on sector 96. #3 is also a guess, but also a very educated one #4 is one of the problems, as a "normal" Windows Format won't allow to create a FAT32 volume larger than a relatively small size and while almost all third party programs also use 2 FATs, it is possible that a "custom" programs creates just one #5 is the biggest problem You have a volume that has a sector size of 1953520002, of these 32 are reserved, so you have left 1953519970 sectors. Of these we know that a (second) part is addressed in clusters of 64 sectors, and that before them there are a number of sectors, each addressing 128 clusters, times 2, and that these sectors must be enough to address each of the clusters in the second part. So you have an equation *like*: 2x+y=1953519970 Where y should be in theory a multiple of 64 and x=y/128 The problem is with the "rounding". I resolved (actually simulated your disk using a tool I have) the equation as: 2*238409+1953043152=1953519970 the 238409 sectors are enough to index 238409*128=30516352 clusters and 30516352*64=1953046528 (more than the 1953043152 remaining), BUT 1953043152 is not exactly divisible by 64. On the other hand, with 238048 sectors I would have not enough "space" i.e.: 2*238408+1953043154=1953519970 238408*128*64=1953038336 (LESS than the remaining 1953043154 sectors). BUT there is no actual "law" preventing me from allocating a slightly larger amount of sectors for the FATs, and use not *all* of them. In other words, I could decide to solve the equation as: 2*238417+ 1953043136=1953519970 and in this case I would have 1953043136 that is perfectly divisible by 64 (and I would simply have a few sectors of the FAT tables that will be never used) Different formatting programs may use one or the other "strategy" or use a different "rounding" algorithm. I hope that the above is clear enough, it's a bit complex, and it is not easy to "compact" this kind of info in a forum post. Please try posting: the sector 238503 some 100 sectors starting from 238895 (or from the first sector after 238895 which is NOT empty) some 100 sectors starting from 238895-238409=486 (or from the first sector after 238895 which is NOT empty - 238409)Maybe I can detect the "increasing number" pattern I was early referring to and be sure about the "sync" of the 2 tables. I am still believing that there were originally 2 FAT tables, it is possible that just like the area from the bootsector to the first sector of the first FAT was wiped (or defective) a number of sectors from the second table were also in the same condition. If there was only 1 FAT, the sectors that you scanned and found 00's, around 238505 and up to 238895 would belong to the first file or directory on the volume, There is another possibility, which is that is possible that the cluster size was, instead of 64 sectors, 128 (and thus the FAT size would be halved) but it would be "non-standard", compare with: http://support.microsoft.com/kb/140365/en-us jaclaz

Is there a particular *need* for having the XP in the VM "fully updated"? If not, it would be simpler to get a pre-made .vhd from MS, there are the "testing IE" ones that are normally "good enough": http://www.microsoft.com/en-us/download/details.aspx?id=11575&ppud=4 jaclaz

OK, the whole thing seems to make sense. I am attaching a file 100 sector in size with a rebuilt bootsector (not bootable, just the BPB) and a rebuilt first sector of the FAT. You should apply it to the image and then run again TESTDISK on the image. Please run TESTDISK with the LOG option, so that if needed you can post the log I can possibly understand what is happening. The file is made in the hypothesis that 2 copies of the FAT were there AND that I assumed/calculated the correct number of FAT dedicated sectors But you could verify if the assumption is correct, before even doing the test. You do have a disk editor/viewer, and know how to use it? (DMDE would do as well, but it is not very "friendly" as "pure" hex editor/viewer) If you check the image sector 96, you will see how it starts with: 81 00 00 00 82 00 00 00 83 00 00 00 84 00 00 00 and sector 97 starts with: 01 01 00 00 02 01 00 00 03 01 00 00 04 01 00 00 etc. The data in the bootsector I re-built uses: 63 "sectors before" <- these come from the MBR and are surely correct 32 "reserved" sectors <- these are more or less a "standard" 238409 sectors per FAT <- these are "calculated" and they may be incorrect In theory, you should have on sector 96+238409=238505 the same data as sector 96, on sector 97+238409=238506 the same data as sector 97, etc. It is possible that this won't happen, if the 238409 is wrong or if the second copy of the FAT has "larger" damages than first copy. You could try going a few tens sectors back or forward and visually check if you see a similar pattern. A contiguous file larger than a cluster is represented in a FAT32 table as a set of numbers (4 byte values) that are each the one before +1. I hope I was clear. jaclaz 100sect2FAT.zip

The good news are that the data you posted is not that bad. At first sight it seems like there are remainders of the FAT table (at a more "normal" sector 95 - i.e. 63+32). More exactly it seems like sector 96 is actually the 2nd sector of the FAT table (and 97 the 3rd, etc.) The exceptionally good news are that from what I can see the first entry in the FAT was (hopefully) a single file, contiguous, around 13 Mb in size. It is possible that there is a "way out" rebuilding the first sector of the FAT. I need to understand however if there was just 1 FAT (which is improbable) or 2 (which would be "normal"), and have to check a few values/make a few calculations/experiments. Give me some time and I may come out with a possible solution. jaclaz

Only for the record: 07 means NTFS (or HPFS or exFAT)17 means the same HIDDEN27 means Windows "RE partition" (or PQService one)http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Whilst also a type 27 is not assigned a drive letter, it may be interpreted "strangely" by setup , and I would personally use type 17 for hiding a partition. jaclaz

For no apparent reason this thread is interesting : http://windowssecrets.com/forums/showthread.php/157657-Skype-password-reset-token seemingly if you sign in Windows 8.1 with MS account, you can't log off Skype anymore, the "solution" provided by the good MS support is: http://windowssecrets.com/forums/showthread.php/157657-Skype-password-reset-token?p=928741&viewfull=1#post928741 And it is actually the "official" stance, see: https://support.skype.com/en/faq/FA12199/can-i-sign-out-of-skype-windows-8-or-above ... and to be fair, is not even "news" (Windows Phone 8 doees the same): http://forums.wpcentral.com/windows-phone-apps/203679-dear-skype-please-let-me-log-out-skype-windows-phone-8-a.html jaclaz

@NoelC No, I was saying that what the good MS guys call "features" are the things that you (nicely ) removed, while the only "real feature" (the mounting of the .iso) that you listed is not really-really "news", as it was available (via third-party tools/drivers, and JFYI also through MS's own VSS driver) since a long time. As dencorso suggested - it would be very nice if you could provide a list of the add-ons/third party tools that you "adopted" in your setup and I am sure that a lot of people would be interested in more details on the exact procedure you followed to have the install result as a "better" Windows 7 or Windows 7.01. : jaclaz

Well, for the record third party tools (that you seemingly use for removing "features" of Windows 8.1) and BTW more thatn one Freeware, exist to mount/access .iso since the dawn of time and suitable to all recent NT based systems, surely including XP and - if I remember correctly - even 2K. jaclaz

Well, JFYI a non-written Rule of data recovery is that when you set a machine to do something like that (imaging, scanning, etc.), you disconnect it form the internet/local lan (and possibly also disable any service not really-really needed). I am sorry for your misadventure , but that is the essence of Murphy's Law, of which you provided an excellent example . jaclaz

You are very welcome, I am sure . Just to clear the matter re: Clonezilla, one must understand that each tool has it's own little "quirks" (and a designed scope) and every situation is a bit different. In your particular case you had not a "failed/corrupted" filesystem, but rather you had a perfectly sound FAT32 filesystem (and you had it on an perfectly working disk). Clonezilla, is designed for cloning of valid filesystems, and among it's features is to copy only used (meaning filled with data AND properly indexed by the filesystem) sectors, this is among it's "features" as it speeds sensibly the copy. the "mistake" or the "misleading" is to call this procedure a "clone" (as it is not, or better it is a clone at filesystem level, but not at physical disk one). But Clonezilla does contain also dd and ddrescue, so you can use it as well to make such a copy, only you won't be "guided" by the scripted interface. Still for the record, what you found was the actual $MFT (not the $MFTMirr), the $MFTMirr is a copy of the first four sectors of the $MFT and it's location is - in my experience - "variable", as such it is not easy to find without having a valid bootsector. The location of the $MFT is on the other hand "almost always" (i.e. for any partition/filesystem) bigger than around 5-6 Gb in a given location on cluster 786432. The bootsector on NTFS is actually a file, called $boot, 16 sectors in size that is at the very beginning of the filesystem. The only part really needed to access a filesystem is it's first sector which is mirrored in a bootsector mirror. This mirror of the bootsector was once (NT3.5 and 4.0) placed in the middle of the filesystem, on "modern" NTFS it is on the last section of the partition space (first sector outside the filesystem/volume) and as such normally easily found. Using a disk editor (personally I use the good ol'Tiny Hexer on windows) or a "low level" tool like DMDE is of course not the easiest thing to do and a background on the innards of the filesystem that you want to recover are needed. Free tools (like the mentioned TESTDISK, which is an exceptionally good/useful program) or Commercial tools like the one you used (which does have a "good reputation") are obviously much easier (though in some occasions more seemingly easy that what they actually are) but, on the other hand, they tend more or less to be targeted to "more common" situations. TESTDISK was probably tricked by the fact that you had a perfectly good MBR and FAT32 filesystem (or possibly you were tricked by it's seemingly "easy" way of use), as it is most peculiar that there was a valid $MFT and TESTDISK was not capable of detecting it . In any case it is obvious that if it was "so easy" to recover data with manual, free tools, Commercial "advanced" tools would have no reason to exist, the choice of using the simpler free tools comes at the price of needing to know what exactly to do with them, and such knowledge does have a cost (but is also, in my perverted mind, "fun" ), on the other hand Commercial tools are often a quicker way, the essence is however that of first thing making the clone/image, this way if one tool fails, you can always restore the image and try with another tool, (and if you fail anyway, this gives you anyway an option to have an untouched copy to give to a professional data recovery service). Some time ago I jolted down my personal "rules" : http://www.msfn.org/board/topic/84345-data-recovery-tool/#entry572375 jaclaz

Not really-really AFAIK. But it seemingly does write to the "hidden sectors" (that are AFTER the MBR and BEFORE the "bootsector"). The good linux guys call this area "embedding area" (for no apparent reason if not for using some even more confusing terminology) http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html http://ubuntuforums.org/showthread.php?t=1661254 The technology used by some Adobe products (but not only) is called "flexnet", it is made by these guys here (just to know who is the actual responsible for messing with your hidden sectors): http://www.flexerasoftware.com/ jaclaz .

Anyway, should you not be able to recover the data this way, we can still try assuming that your previous DMDE scan for FAT was accurate and recreate a new bootsector with the relevant BPB data on it. You can also use DMDE (or any disk editor) to look manually in the disk to check for the FAT start. Typically it is a few sectors after the bootsector (8 according to your previous DMDE scan) and basically it is the first sector that starts with the F8 FF FF 0F FF FF sequence. The previous scan of DMDE says that the FAT size is 122065408, the "sectors before" from your initial posts are 63 and the partition size is (still from there) 1953520002 sectors. The only thing that is not clear or "queer" is the number of FAT's, from the DMDE scan you reported it may be that there is only one table (and DMDE assumes that a part of the FAT1 is actually the FAT2) but this is "uncommon" as normally there are two copies of the FAT table. If you want, you can dd the first 100 sectors of the disk, compress them in a .zip file and either attach them to your post or upload to any file hosting service and post the link. From Linux, that would be: dd if=/dev/sdb of=100sects.bin bs=512 count=100(of course the command must be run from RW mounted filesystem or anyway the of= file must be on such a filesystem, i.e. include a path to it) It would be easy if the data is confirmed to prepare a couple bootsectors, one with just one FAT and the other with two FATs. jaclaz

Yep. If the DMDE found FAT table has not errors, as it seemed, now that you have the data on a surely working device, you can try also re-running TESTDISK, if it now can write to the bootsector, most probably it can fix the filesystem enough to acess the data "normally". But can you post the actual recovery log? BY checking the location of the chunks that errored out it is possible to see if they beloong to filesystem data or to the actual data, as this makes a big difference (between being unable to access some 16,000 entries or being unable to access - or get corrupted - 1 or two files) In any case usually the idea is to re-run the tool a couple more times with the "-C" option to see if it can recover the "errored" areas, possibly by using a smaller block size: and/or using the "reverse" approach: jaclaz

Maybe Microsoft sold the patent rights for that system to Yahoo... --JorgeA Good one! Just for the record, bell (or Gauss) curves are a good instrument when production or constance of quality are the scopes, and never a good one where research and innovation are. They tend to heighten the relevance of average, and while they may be useful to "cut" the bad out, they also cut the "exceptionals" or the "geniuses" out. By re-sampling data over and over, the result is always tending to be "average". jacla

Again, it depends. If you plan to use them only on newish MS OS's, you should go for exFAT which is faster and allows for large files. (but you loose compatibility with older systems). If you need the wider compatibility, FAT32 is better, and you can (if you want) partition it and optimize the placement of the filesystem to gain some beter performance, but you won't be able to host on that filesystem files larger than 4 Gb (yes, of course you can have more than 4 Gb in different files, but the size of any single file must be smaller than 4 Gb). If you want large file and "wide enough" compatibility, and overall a "more solid" filesystem[1], go for NTFS. Always use "safe remove" or equivalent before removing a USB stck from a running PC. jaclaz N.B.:[1] the attribution of "more solid" in this context does NOT mean that I want to initiate the usual FAT32 vs. NTFS, Dracula vs. Mickey Mouse, Godzilla vs. King Kong flamewar , it is only meant to highlight some features of the NTFS that make in certain circumstances easier to recover data from a crashed filesystem .

It depends on a number of factors. "stock" flash USB stick normally come formatted as "super-floppy" (i.e. NOT partitioned) and FAT32. FAT32 cannot host files larger than around 4 Gb. To boot from the stick it is usually needed to have it partitioned. If you plan to boot from it some Linux OS, some of them do not have kernel level (or initial) support for NTFS. FAT32 drivers have been dumbed down by MS, so NTFS is generally speaking, better performing, and it can host files larger than 4 Gb BUT, depending on some settings may wear out the device prematurely, see: http://www.msfn.org/board/topic/125116-fat16-vs-fat32-vs-ntfs-speed-on-usb-stick/ BUT there are strategies to format the stick providing a slightly better performance: http://www.msfn.org/board/topic/151798-does-fat32-align-its-clusters/ http://reboot.pro/topic/16775-discover-allocation-unit-and-other-information-of-ufd-under-windows/ http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/ Finally newish USB 3 "high end" USB sticks are not anymore flash dries, but rather (small) SSD's with a USB3 to SATA bridge. jaclaz

Good. The disk is seemingly one of those with the "newish" 4096 bytes per sector "advanced" format: http://www.storagereview.com/samsung_spinpoint_m8_review but as a mattter of fact it seems like it "exposes itself" as a conventional 512 byte/sector device. As such the offset of 4096 bytes for the start of the FAT1 seems like "possible or probable". Quite surely the good guys at ADATA have created the FAT32 filesystem with a "cusstom" app (the "standard" Windows format won't deal with such a large disk or will create a "huge" cluster size, but in any case it would create a higher number of "reserved sectors"). I didn't think it was a 2.5" drive, and yes, I have seen how those are often formatted as FAT32 even if very large, in factory, so that the "common" user can use them on Windows, OSX and Linux "as is". As well, the size of the found FAT seems like "right", 122065408/4=30516352 (roughly) indexable clusters, and if you divide 1953520002 (total sectors - these are 512 bytes ones) by 30516352 you get roughly 64 which makes sense for a 32 Kb cluster FAT filesystem. It is possible (but I doubt it) that the "custom" format had only one FAT table, but in any case the FAT1 that the tool found - according to the data posted - sounds like "the right one". : jaclaz

What's this ? Quote day? http://en.wikipedia.org/wiki/Bartleby,_the_Scrivener jaclaz

Well, as a matter of fact - and just for the record - the mentioned DMDE has a free edition and at least in it's Windows version (which you excluded using) is normally capable - believe me - to find a $MFT, and also as said, I already provided the actual addresses where to check (based on the data you provided). So there was not - specifically - any need to "search", only to verify if those addresses were correct. In any case, happy that you managed to recover your files . jaclaz

WHICH "quote balloon" is missing? That sentence is by Douglas Adams and I correctly put it inside QUOTE tags referencing him. jaclaz

Yep jaclaz

Not really, we have been there (and read that): http://log.nadim.cc/?p=78 http://withinwindows.com/2012/08/24/thoughts-on-the-windows-smartscreen-scare/ jaclaz

These results are not that bad: BUT they are not "normal". I mean it seems like the two copies of the FAT are overlapping. If you choose the "do not use FAT tables" the filesystem will be read as "RAW" and as such only files that are contiguous and in any subdirectory may be recovered (BUT, IF the FAT tables - even if "OK" - do contain invalid or incomplete data, this option may allow to recover MORE files than when using the supposedly "100% OK FAT table", on the other hand, it is well possible that the second FAT table, though not "100% OK" may contain "different" - possibly "more valid" data. The "standard" procedure when you know WHAT you are actually looking for is to try checking the files/directory tree once for each option and then choose the one that shows the needed file(s). If you don't know what you are looking for, the procedure is to run the whole recovery process three times, and then compare results. The real issue here is that - depending on the reason that caused the sector level errors - it is possible that each read operation/movement of the head on that disk makes things worse, and - besides - working on an even partially defective disk will slow down operations to a level that is almost unbearable. That's another reason for making the image, it may take a lot of time to create (hopefully) a valid image, but the imaging tool can be run "unattended" at night, and once you have the image on a "good" disk, the interactive part of the recovery (analyzing/searching/copying/etc.) will be faster. I would no doubt have the image made next thing. (better be safe than sorry ) Can you post the EXACT model of the actual disk drive? I want to check it's actual sector size and number of sectors as something - instinctively, but I have do make some calculations - doesn't "sound" right to me about the FAT size found. jaclaz