jaclaz

Let's see if we can clear the "math" aspects. The partition table in the MBR says that you have two partitions. #0 07 00 0 32 33 12 223 19 2048 204800 #1 07 80 12 223 20 1023 254 63 206848 976564224 The above data is expressed in sectors (i.e. you multiply them by 512 to have bytes). So you have: 2,048 "unused" sectors 204,800 sectors used by first partition 976,564,224 sectors used by second partition 2,048+204,800+976,564,224=976,771,072 sectors x 512 = 500,106,788,864 bytes <-this is the theoretical size of the whole disk (and of the image) Addresses in the MBR are expressed in sectors and relative to the beginning of the disk. Addresses in the PBR or bootsector are expressed in clusters and relative to the beginning of Volume (in your case, like in, say, 99.99% of cases, your filesystesm uses clusters 4,096 bytes in size). This means that a cluster is 8 sectors. On your volume "range of size" the NTFS by default will place the $MFT at cluster #786,432. 786,432 x 8 = sector #6,291,456 but since the volume starts @ (2,048+204,800)=206,848 when you access the whole disk or the image, it will be on sector (206,848+6,291,456)=6,498,304 Still by default, the $MFT Mirror is placed at 1/2 (one half) of the Volume. So - seemingly- @ 976,564,224/2=488,282,112 which corresponds, when you open the whole disk or image to 206,848+488,282,112=488,488,960 But the above is "wrong", because there are two things I omitted: since it is an address inside the volume, it has to be accessed in clusters there is always one sector after the volume but inside the space reserved for it dedicated to the backup of the bootsector In reality, the volume can be at the most 976,564,224-1= 976,564,223 sectors, which, in clusters means 976,564,223/8=122,070,527.9 clusters So, if you do 122,070,527/2=cluster 61,035,263,5, and in bytes 61,035,263 x 8 = 488,282,104 bytes. Consequently the %MFT mirror should be @ 206,848+488,282,104=488,488,952, or, more simply, one cluster before what you would expect by doing the simplified calculation. I hope the above explains it all . I'll check the new file extracted and let you know. Edit: quickly checked, I now see where the problem is . You are continuing to "mix" between the "sectors" and "bytes" fields of the datarescuedd tool. I asked you the SAME range you had already posted that in bytes was (the datarescuedd uses bytes in filenames): [3326976000-3332096000], but what you now posted is: [170341171200-170603315200] You evidently had issues of some kind with datarescuedd. You have a PARTIAL image. We are doing a "Clone", so if the original is 976,768,065 sectors or 500,105,249,280 bytes, the copy, strangely enough, has to be the EXACT same size. Go back to square #7: and this time READ the post and the given links. In explorer the size of the image MUST be (Properties) EXACTLY 500,105,249,280 bytes. Or if you need to do partial images, the re-assembled file MUST have the same exact size.... Still there is an inconsistency with the theoretical size as calculated from the MBR data, but that could be irrelevant or caused by some miscaòculation/corruption, all the other data seems like "consistent". jaclaz

Well , it is entirely up to you, but I would guess that your brain has got to 80 + years in perfect working order EXACTLY BECAUSE you have used it intensively before . Come on, giving up is NEVER an option! You can do it! Go, Roffen, Go! *\O/* | / \ But there is something that does not sound "right". You should have in ROOT (i.e. C:\) : C:\BOOTMGR <- this is a file, possibly around 380 Kb in size C:\boot\ <- this is a folder, containing a file called BCD and other directories/files (local languages) Compare with this: They might be "hidden" files, and you have to set explorer to show them. jaclaz

NO. Please re-read my previous posts. The Windows 7 uses the BOOTMGR/\boot\BCD (that you have now only on the WIndows 7 disk) The XP uses the NTLDR/BOOT.INI that you have now only on the Windows XP disk. Your next step should be to have both disks visible, with the XP boot disk first in boot sequence, boot the XP and from it copy from "drive 1" to "drive 0" (the XP drive is now "C:\" and the Windows 7 will get another drive letter): BOOTMGR <- this is a file \boot\ <-this is a directory containing several files, including one named simply "BCD" Now we need to make an "intermediate" step (to make sure we have a way out if needed ).. Get bootpart from here: http://www.winimage.com/bootpart.htm unzip in a directory like "C:\bootpart", open a command prompt, navigate to it and run just "bootpart" with no arguments. You will get an output similar to this: C:\BOOTPART>BOOTPART Boot Partition 2.60 for WinNT/2K/XP (c)1995-2002 G. Vollant (info@winimage.com) WEB : http://www.winimage.com and http://www.winimage.com/bootpart.htm Add partition in the Windows NT/2000/XP Multi-boot loader Run "bootpart /?" for more information 0 : C:* type=6 (BIGDOS Fat16), size = 1044193 KB 1 : C: type=a (OS/2 Boot Manag.), size = 8032 KB 2 : C: type=5 (Extended), size = 8032 KB 3 : C: type=7 (HPFS/NTFS), size = 8001 KB 4 : D: type=6 (BIGDOS Fat16), size = 261104 KB 5 : D: type=5 (Extended), size = 769024 KB 6 : D: type=7 (HPFS/NTFS), size = 102384 KB 7 : D: type=5 (Extended), size = 369664 KB 8 : D: type=7 (HPFS/NTFS), size = 369648 KB 9 : D: type=83 (Linux native), size = 296944 KB The XP disk will be the one with the asterisk, and the Windows 7 disk will probably be "D: " and the partition something like "D: type=7 (HPFS/NTFS), size = <the size you made it> KB" Jolt down the number on first column correspondent to the volume on which 7 is installed, let's say that this number is 5. Now run bootpart as follows: bootpart 5 C:\Windows7.bin "Windows 7 disk" It should do two things: create a 512 byte file C:\Windows7.bin add in BOOT.INI an entry like "C:\Windows7.bin="Windows 7 disk" Now, if you reboot, you should be able to choose the Windows 7 entry and boot the Windows 7. Please try and report. jaclaz

Doesn't seem the author thought he had succeeded. Yep , but the conclusion is NOT that one, that is a "final question", actually just some poking at the good Linux guys on reboot.pro . The conclusion is ABOVE that. And it says: Curious indeed. The device is needed to zero out any output file of dd. But the simple fact that it's needed to include it makes the executable more complex, and also shows the shortcoming. How about /dev/random? Yes, NT supports piping, and a Windows port of dd likely also. But the ecosystem mainly doesn't. So where can I pipe from/to? A mayor strength of dd (and most commandline tools) in *nix is that it can be piped with many other tools, adding amazingly much functionality. Want to fill a disk with 0xFF?cat /dev/zero | tr "\000" "\377" | dd of=/dev/sdaIt's all just available. About zero and random, see here : http://www.ltr-data.se/opencode.html/#ZeroDrv You can pipe dd to gzip under NT allright, that is what you originally posted . And if you read attentively the thread, you wll also see how I advocate the need of a NT version of mkfifo... Now , this is not intended as a NT vs. Linux debate, rest assured that - limited to dd-like and connected operations, I know enough of both "worlds", and know which environment is "better" or "more convenient " to carry on the small tasks I normally need to do, and use the one or the other as I see fit.. jaclaz

NO nagging at all , I overlooked your previous few replies, so it's a good thing that you bumped this. Let's see waht happens with the 16 Gb card, you said: This may be a piece of relevant info (the different way the card is seen by the BIOS). OT, but not much, years ago there was a tool to change the status of CF cards (at least of some types of it), this is JFYI, do not even THINK of trying that tool (ATCFWCHG.COM): http://www.thinkwiki.org/wiki/Compact_Flash_boot_drive This may well be caused by that "removable" setting (in combination with that pesky BIOS: Now, on the 16 Gb one: But also: 31227840 sectors in grub4dos. 31227840*512/1024/1024=15247,96 31227840*512/1000/1000=15988,65 <- the BIOS is seemingly using x1000 for Kilo and Mega. The fact that the BIOS sees an actual LBA geometry is a good thing, though I would anyway try first with a "wholly inside" first CHS partition at first. A good number could be 1024*16*63=1032192 sectors x 512 = 528482304 <- this is the size of the file to be given to MBRBATCH/MKIMG. Use a FAT 16 (06) type at first, then try 0E (by only changing the relevant byte in the partition table) with a hex/disk editor. Rest of procedure is the same. You may want to get my little spreadsheet here (get the "newish" version attache dto post #10): http://reboot.pro/2959/ and play a little bit with it.... jaclaz

A resource for the good ol' times lovers : http://www.minuszerodegrees.net/ Specifically: http://www.minuszerodegrees.net/images3/floppy_crossover_cable_wiring.jpg jaclaz

To avoid having the filter/driver? NO. To avoid downlaoding 1 Gb to actually a bunch of needed bytes? Yes. Looky here : and another way to do the same: http://reboot.pro/13049/ jaclaz

And this is what is currently escaping me , the sequence of actions that you reported - once reversed - should have no consequences in re-installing the XP (that is if it worked first time). (attempting to do so on the unformatted drive AND with it holding the Windows 7 pageflile may) Yes, we are. What actually happens is that a couple of directories, namely: $WIN_NT$.~BT - the boot folder $WIN_NT$.~LS - installation files folder are created (normally on the Active partition, i.e. C:\) these folders contain the actual installation files. The BOOT.INI file is changed during the installation to boot (for second part) from these folders, a line similar to this is added (and made default). c:\$win_nt$.~bt\bootsect.dat="Windows XP Installation/Upgrade" Now, having formatted (BTW right now you have formatted it from the booted Windows 7, did you do this the first time or from within the XP setup?) nothing in the logical volume may have become "sticky" (and thus change the behaviour of the XP setup). So it must be something on the C:\ partitiion. Either the BOOT.INI or the two folders created by the previous install. Check that you have no $WIN_NT$.~BT nor $WIN_NT$.~LS folder. Delete the BOOT.INI. Try again installing. The fact that you reported having the multi(0)disk(0)rdisk(0)partition(4)\WINDOWS line might mean exactly this. The BOOT.INI was changed to it's "final" version by the initially successful install and for *any* reason, it does not the needed change during subsequent attempts to install, possibly a NTFS permission issue... No, actually it is the newest version among the "release ones", and NOT the latest-latest which is ALPHA. jaclaz

Well, the referenced thread contains links (and also personal opinions ) on several ports of dd for windows, including a few ones MUCH "simpler" (and "smaller") than the CYGWIN version, so, not only it is perfectly possible but it has already been done, by several people, including - curiously a version that includes a /dev/zero device and of course piping is perfectly posible on NT systems. I am clearly missing your point. jaclaz

Normally, yes . But since Multibooter is already on the "dd bandwagon" , he (and you ) might find this thread interesting: http://reboot.pro/15207/ And since you are both very nice guys, a SCOOP : https://github.com/bmatzelle/gow/wiki/ rigorously UNtested by me, though . jaclaz

Well, 13 errors mean little, it is the type and extension of each that may make the difference. I will translate this to plain English for you (two possible alternative translations) : I do work for Seagate, as a matter of fact it is 15 years that I am the delivery boy, what I usually say to my friends is that I am chief engineer at Seagate, and they believe me, I actually hve no idea on how a hard disk is made or how it works, but since also my friends know nothing about hard disks, I'l just tell this guy that there is nothing to do about the disk. I actually am chief engineer at Seagate and I can of course recover any drive, whatever the damage is, but since it would cost me time, dedication and what not, I'll simply tell this guy that there is nothing to do about the disk. Now back to work. What you got now is actually a $MFT and all in all it seems like being in "good shape". So, it is at sector 6498310? There is something that doesn't sound right. The image you posted is called image[3326976000-3332096000].dd. The Datarescuedd names images automatically as image[<bytes_from>-<bytes_to>].dd So 3326976000/512=sector 6498000 (which is "right") BUT I find the first hit within the file at offset 156672, and since 156672/512=306, it seems to me like the $MFT begins at 6498000+306=6498306 (and NOT 6498310). Please, do check that on the image sector 6498306 does begin with "FILE0" and that around the middle you can read "$.M.F.T.m.i.r.r.". If this is the case, it means that *someow* the first entry of the $MFT has etiher been overwritten or is/was unreadable, as the sector that contain the "$.M.F.T.m.i.r.r.". is the "second" entry of a $MFT. And, since both the 6498306 and the 6498310 did not make sense as they would represent (given the offset of the partition) a "fractional cluster", it would make much sense that the $MFT actually started on 6498304 which nicely corresponds to cluster #786432 (which is the actual "right" "standard" value). Your "quest" is not (yet) finished. Since the first record of the $MFT is seemingly missing, we need to find the $MFT Mirror. It is (or should be) at the half of the volume. Theoretically this would be around sector 206848+976564224/2=488488960, possibly the already given 488488952 So you should GOTO sector 488488000 (to be on the safe side) and search again for "46494C4530". Can you also please post the actual EXACT size (in bytes) of the whole image taken (just to make sure I can replicate it "virtually")? The condition of the $MFT is not at all "bad", at least form the set of sectors you posted. If the drive is still functional after the Seagate guy's attempts (if any) a good idea would be to try again imaging a bunch of sectors, trying this time "backwards". The same range [3326976000-3332096000] would do nicely . (the missing two first sector of the $MFT are now filled with 00's or FF's and this may be a sign of a read error, that in some cases can be avoided by imaging "backwards", also, try doing this partial image a couple of times, once as soon as the disk is on - "cold disk" - and once after the disk has been powered by at least half an hour - "hot disk", you never know). jaclaz

@all There is nothing "bad" in having XP (or any other NT based system) on a logical volume inside extended, actually NT was designed to be installed on logical volumes and it is a type of setup that I often recommend. @aniss I would suggest you to re-start from where you early managed to succesfully install XP. Go to System->Advanced options, use this: http://ihaveapc.com/wp-content/uploads/2011/05/pagefile0.jpg as a reference, UNcheck (if checked) the "Automatically manage.....", then set the pagefile on drive H:\ to "none". Reboot. Now re-format the H:\ drive (use "quick format"). You should be now in the same situation you were at the beginning, just after you created and formatted the new volume. So, you should be able to install the XP just like you did the first time. Before doing so, download this file: http://code.google.com/p/grub4dos-chenall/downloads/list http://code.google.com/p/grub4dos-chenall/downloads/detail?name=grub4dos-0.4.5c-2012-06-19.7z&can=2&q= and extract from it just the grldr file, putting it in the root of C:\. Try installing the XP, then, after you have successfully booted XP, do the following (mind you this is NOT the "solution", it is only an "intermediate" step to make sure to be able to boot temporarily both systems). Modify the boot.ini as follows: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(4)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional" /fastdetect multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="This should produce an error" C:\grldr="grub4dos" Reboot. Choose the "grub4dos" entry. You will get to a: grub> prompt. In it type: chainloader /bootmgr [ENTER] and you should boot the Windows 7. If the above works, then we will see how to FIRST add the XP entry to the \boot\BCD, test that it works, and only later change the bootsector to have it load the BOOTMGR instead of the NTLDR. jaclaz

You are doing a SERIES of mistakes . Not a problem this happens all the time, it is "normal" . You take a guide, (*any* guide) and instead of following it "to the letter" you introduce (by mistake, of course) some changes to it, and the result - strangely enough - is that the guide is seemingly wrong. Now, as soon as you get your "first" error, you should STOP §@ç#ing doing random things and ask for help. Once you have asked for help (and somene is willing to proveide it) you should §@ç#ing STOP doing ANYTHING BUT what is suggested to you. You do understand that you post describing a given situation, and as soon as I try giving you a suggestion to exit THAT situation, in the meantime you do something and at your next post the situation has changed? If you sum up the above, you should now STOP changing anything, describe your current situation, then go away, take a walk, get a life, whatever and wait for some suggestion on how to exit from a "now static" situation. Since you are ready to re-format the partition and re-install the XP to it, I can give you EXACT instructions on how to make this, though how the pagefile.sys got to that partition is a mistery to me . jaclaz

NO. Simply because that volume is never actually "booted". The booted volume is the first, active, primary partition (i.e. the "Boot" volume) where NTLDR, NTDETECT.COM and BOOT.INI are. NTLDR then act as a LoaDeR for the NT system on the logical volume, which is the "System" volume. Of course MS has it EXACTLY the other way round , JFYI: http://www.multibooters.co.uk/system.html jaclaz

And most probably you have the "old", "safe" boundaries partitioning. Good, though if you are using the "Old" standard there won't be *any* problem with *any* tool. Well, in this you are perfectly right, not only it is a can of worms, it is an open one! Sure at the most you won't be able to boot an XP. Good, but how exactly did you install/re-install the XP and the 7? If you left both (please read as "all three of them") drives connected and first drive in boot sequence (BIOS) is the "XP one", and you installed first XP and then Windows 7, what should have happened is the following: The XP installs make the first disk have the active, primary partition (which is both "system" and "boot" partition when you boot the XP) with a bootsector invoking NTLDR and copy to the root of the drive NTDETECT.COM and BOOT.INI, writing to it some valid values, such as: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect Then the install of Windows 7 should have created on the same first disk a file BOOTMGR and a \boot\BCD, and it will have modified the bootsector of the partition to invoke BOOTMGR instead, and an entry to boot XP from the BOOTMGR will have been created, BUT the Windows 7 won't get C:\ when booted. On the other hand if you installed by disabling disks as you were used to, the BOOTMGR and \boot\BCD will be on the first partition of second disk, or if you prefer you have two completely independent installs. Is this what you have now? jaclaz

It should be in ROOT of the Active, Primary partition on that disk (should be your C:\ drive "Sistema, Arranque"), as well as a copy of NTLDR and NTDETECT.COM. Mind you that these file are "system" and "hidden" normally and you will need to set Explorer to see those files and use attrib.exe to change the BOOT.INI attributes in order to Edit and save it. From the screenshot, the partitioning is seemingly: Disk 0, Partition 1 - C: Windows 7 - 120GB Disk 0, Partition 2 - H: Windows XP - 25GB Disk 0, Partition 3 - F: My general storage partition - 145GB Disk 0, Partition 4 - D: HP_RECOVERY - 10GB BUT the "XP partition" is a Logical Volume inside Extended. Different OS (and tools) may list a Logical Volume inside Extended differently. The BOOT.INI uses arcpaths as detailed here: http://support.microsoft.com/kb/102873 So, what you really have is most probably: http://www.terabyteunlimited.com/kb/article.php?id=159 Disk 0, Partition 1 - C: Windows 7 - 120GB Disk 0, Partition 2 - F: My general storage partition - 145GB Disk 0, Partition 3 - D: HP_RECOVERY - 10GB Disk 0, Partition 4 - H: Windows XP - 25GB So what you should make sure of is that in the C:\ drive you have: BOOTMGR \boot\BCD NTLDR BOOT.INI NTDETECT.COM The BOOT.INI contents should be: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(4)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional" /fastdetect multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="This should produce an error" Then, you need to re-add /using easyBCD or other tool) the "Windows XP" entry to the \boot\BCD. As soon as you have it working, you can delete last line of BOOT.INI, it is there only to verify that the BOOT.INI is actually loaded. jaclaz

Kelly, the friend of Beeber, of course, you know, the one that has a website but seemingly isn't around there currently. You can send her a post card addressed simply as: and the post office will know what to do. (isn't it the normal way to address Santa Claus? , if it works for him, it should work for Kelly also , and yes, adding to it "North Pole" is pleonastic) jaclaz

Hmm, my memory might be failing me here, but the only things I've seen from them in that era was crappy old BASIC (not sure how far back MASM goes). That's where Borland came in with Turbo C/C++/Pascal/ASM/Vision/etc. Heck yeah. BASIC, COBOL, Fortran, Assembler, C, Pascal, all by the IBM AT era. Probably in that order but I'll be darned if I can find a source (I'll bet Jaclaz can). NOT EXACTLY what you asked for , but, had you asked for: jaclaz may have posted this link : http://oreilly.com/pub/a/oreilly/news/languageposter_0504.html jaclaz

IMHO the "wrong" thing you did was to use EasyBCD at all . Mind you for a number of aspects EasyBCD is an excellent tool , the problem with it is that most people will assume two wrong things about it: that because it has "easy" in it's name it is "easy" to use and that hence RTFM is completely unneeded that because it has "easy" and "BCD" in it's name it represents the "ultimate answer to all questions involving booting matters" EasyBCD is (or should be) simply a "more convenient" (which does not mean in itself "easier") way to edit the BCD (i.e. a GUI replacement to BCDedit). BUT it has a number of additional (again "nice" if used correctly) features. You will be surprised to know that you don't need (at first) *any* of these features. You ALREADY have a valid BOOTMGR and \boot\BCD file (since you have Windows 7 installed and running). The BOOTMGR is invoked by the bootsector (or PBR or VBR) of your active partition. When you install the XP the bootsector (or PBR or VBR) of your active partition is rewritten to invoke NTLDR instead. The MBR has NOTHING to do in this process as normally it does simply load the bootsector (or PBR or VBR) of the partition marked active in the MBR partition table. DO NOT TOUCH the MBR! An HP notebook may have a non-standard MBR code (used to load the Recovery partition), if this is the case and you accidentally overwrite it (unless you have a backup of it) it will be extremely difficult to rebuild it, or replace it with one with a similar functionality, compare with: Open (under Windows 7) Disk Management and verify that your partitions: C: Windows 7 - 120GB D: HP_RECOVERY - 10GB F: My general storage partition - 145GB H: Windows XP - 25GB Are in this order on the disk. This could mean that they are: Disk 0, Partition 1 - C: Windows 7 - 120GB Disk 0, Partition 2 - D: HP_RECOVERY - 10GB Disk 0, Partition 3 - F: My general storage partition - 145GB Disk 0, Partition 4 - H: Windows XP - 25GB (which I doubt). Please post the above partition order with the values you find AND the current contents of BOOT.INI. If I get it right you ALREADY have in the \boot\BCD an entry for the XP (i.e. when you boot you have a choice between 8 and XP and if you choose the latter you get the error "invalid BOOT.INI file booting from C:\WINDOWS\") Or, in other words, describe what you see when you boot now. jaclaz

There is still one litlle point that needs to be decided upon, whether to use the XP partitioning offsets/boundaries or the Windows 7 ones. This is normally very "transparent" to the end user but since it carries with it some possible DANGER and since we are still on the drawing table, it may be relevant. All Operating systems up to XP/2003 used a "convention" stating that any partition should begin and end on a cylinder boundary. Vista and later changed this "basic" and started using a scheme that aligned partition to cluster multiple. The potential issue is that any third party tool made before the Vista advent may threat this "abby" values : http://www.imdb.com/title/tt0072431/quotes?qt=qt0504329 as an error and/or attempt to modify them. Much worse than that , the built-in XP Disk Management will (if certain operations are performed) make some partitions disappear (and though perfectly doable recovering them won't be a "piece of cake"). You can read about the gory details here: http://reboot.pro/9897/ and here: http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm The advantage of using the new "alignment" is to have (theoretically and much to be actually proved in everyday usage on hard disks) faster access times. But if you use it, you must be sure to NOT EVER use the XP Disk Management tool to perform some operations AND know that when using *any* third-party tool made before (say) 2007 or 2008 these may produce errors and/or create issues. Personally, I find that the good ol' method is anyway "good enough" and "safer" (and does not provide on hard disks any really noticeable lag or delay when compared to the new one) but obviously the "new" paradigm is good in itself, once you know the issues with older software. Are you going to start from "wiped" disks? (not really any need to actually wipe them, in this case "wiped" means "unpartitioned" or with just the MBR wiped). jaclaz

Translated in real life terms, this should mean that it will probably take roughly only 12 hours (instead of 20 ) to unneededly wipe Multibooter's 2 TB hard disk. The futility is not in the tool used (though hdparm or HDDerase or Victoria, using the internal ATA commands will be WAAAY faster ) but in the concept itself of wiping. It is UNneeded. It is a source of UNneeded stress for the hard disk. It is taking ANYWAY a lot of time, UNneededly. The good news (for you) are that I was wrong! I probably overlooked Multibooter's posts and did not realize that he is using the 2 Tb hard disk through an USB (2.0) external docking station/converter. This fact grants him ex officio a +1, so you are now BOTH at Level of folly=8 jaclaz

What I miss is whether the XP was ever installed and ran properly. Also, can you provide some exact details on how the disk is partitioned? Normally, when you install XP (I am talking of a "good" install) what happens is the following: the bootsector of the Primary, Active partition is changed to invoke NTLDR (and from it BOOT.INI and NTDETECT.COM) instead of BOOTMGR files NTLDR, BOOT.INI and NTDETECT.COM are copied to the Primary, Active partition ROOT then one uses (even from the booted XP) the command bootsect.exe with the NT60 switch to re-write the original Windows 7 BOOTMGR bootsector (invoking BOOTMGR). then an entry to boot from the BOOTMGR and \boot\BCD the NTLDR/BOOT.INI is added through BCDEDIT or similar tools. What I suspect it is happening to you is that you have a "default" "new" install odf WIndows 7 featuring the ("stupid") windows 7 "100 Mb partition" and this somehow creates the havoc (possibly by writing the NTLDR invoking bootsector ont hat 100 Mb partition BUT writing a "wrong" BOOT.INI pointing to that same partition instead of the "third one" where you installed Windows XP)... jaclaz

This is good . Which could possibly be NOT "stuck heads" as you are now guessing. I mean, if the heads are actually stuck, the arm should not move (nor the motor spinning at all). No, your is the first report of such behaviour on a 7200.11 that I can remember, BUT is quite normal on 7200.11 ES2 and on other models, like the 7200.12 and possibly the "green" ones.. For these latter ones two pins must be shorted to access terminal, but you should anyway get something through the TTL connection, you simply cannot get to the terminal prompt without the quick short of the "read channel". Yes, that is just a matter of the value you attribute to your (lost ) data. Check my signature.... jaclaz

Hmmm. I have one word for you , "Shugart": http://pinouts.ru/Storage/InternalDisk_pinout.shtml jaclaz

Sure why do you think that you were experiencing "lags"? Most probably EXACTLY because you had probably a few hundred entries in the Registry (and it does take some time to delete them). What you should be careful with are those devices - USB sticks usually - (they are quite rare, but you never know) that for one reason or the other do not have a serial number, I seem to remember that those are the ones that may "confuse" Windows and create (or incrase) those lags. For machines to which you connect a great number of different devices, periodically clearing the Registry is usually a good enough preventive measure, you should run the thingy from time to time (if there are not too many registry entries it will be quick ). jaclaz