In Vista I partitioned and formatted a brand new 120 GB USB LaCie HD to test Windows 7 USB install on it as per karyonix tutorial.

I created three primary NTFS partitions WIP (20GB), ONE (16GB), TWO (16GB) plus two logical partitions in the extended partition, BACK1 (20GB FAT32) and BACK2 (48GB NTFS).

I used WIP to install Windows 7 on a VHD, ONE and TWO to host two clones of the VHD content which I subsequently personalised with the drivers of two different notebooks, and BACK2 as a backup of WIP.

To enable booting from ONE and TWO I had to fix the MBR created by Vista on the USB HD to make it Windows7 compatible.
I used MBRFix.exe /drive 1 fixmbr /win7. Everything OK.

The way I used this USB HD was:
On Disk Management in the Vista PC marked ONE as active, then successfully rebooted from USB in Windows 7.
On Disk Management in the Vista PC marked TWO as active, then plugged the USB HD to another (WinXP) notebook and booted from USB in Windows 7 there.

Everything worked well till when, working on the WinXP notebook, I used its Disk Management to mark ONE as active to prepare the USB HD to boot the Vista notebook in Windows 7.
At that point all of a sudden BACK2 disappeared and lost everything was in there.
I then replugged the USB HD to the Vista notebook to recreate BACK2 and its content but its Disk Management lost also ONE and BACK1.
I've therefore been obliged to recreate the lost partitions, but Disk Management refused to format them (both the primary and the extended) with an error message.

Besides completely reformatting the whole USB disk, which I can't do before backing up WIP and TWO (and don't have other disk space available right now), I wonder whether something can be done to try and recover what remains of my work.

A similar story happened to me last year when I was playing with multipartitioning a ufd. I can not remember very cleary but I remember all other partitions disappear when I was playing with diskmanagement . Since than I do not use 2nd partitions to store things on ufd.

edit:I guess I was trying to make 2 os boot like the story at first post by activating one and other....

Thanks for your reply!I wish I could solve with TestDisk (which seems a very powerful tool), but I suspect that my attempts to reformat lost partitions may have already destroyed their content.

I've also found this interesting article that describes the problem but doesn't offer solutions to it apart from "for now the best solution is to not let Vista create partitions". It also has links to details that you certainly may understand better than me.

Question is: has this been an unlucky event or is this the way one ends up when using Vista and XP tool on the same disk? In this case the problem is very serious, and undocumented too.

Question is: has this been an unlucky event or is this the way one ends up when using Vista and XP tool on the same disk? In this case the problem is very serious, and undocumented too.

Yes.

You found the right reason.

This is of course a problem generated by Vista. (and caused by the overall utter stoopidity of the approach of the good guys at MS)

Most probably to change one single byte (the 80 to 00 or viceversa in the MBR) the stoopid disk.management re-checks the whole MBR and EPBR's, and being stoopid, wrecks an otherwise perfectly working setup.

Show clearly how the "random access" gets better, expecially with very small sized files.

In the typical usage of a desktop, this won't make much difference (you'd better buy a faster disk), but you effectively REDUCE "burst transfer" in most cases (i.e. your imaging program will take MORE time to image or restore).

In other words and IMNSHO , "server" settings are good for servers, and should not be sneakingly forced upon desktop users, expecially when they introduce a backwards incompatibility, so severe as to potentially cause loss of data.

Back to the specific case, yes it is possible that you already botched your disk beyond repair, but it is also possible that the partitions, or at least their contents could be recovered.

I'm not sure I fully got the significance of the "fix" you suggest.I suppose it is something to apply "before" to avoid the problem rather than something to apply "after" as TestDisk.

I'm particularly interested in a fix, for the reasons explained below.

Back to the specific case, yes it is possible that you already botched your disk beyond repair, but it is also possible that the partitions, or at least their contents could be recovered.

As a matter of curiosity I tried TestDisk anyway and let it analyse the USB. As expected it found a mess, with overlapping partitions. I did nothing to correct the situation at the time, but when I plugged the USB HD to the XP notebook again something strange happened.The two surviving partitons (WIP and TWO) where luckily still there and working. I successfully booted Windows 7 from TWO then attached the Windows 7 VHD that was in WIP, edited the BCD for native-boot from VHD, and marked WIP as active.I then successfully booted from VHD. Perfect!

When rebooted to XP ... Explorer "found" ONE also, which hadn't found before. This second primary partition that I had been forced to remove and unsuccessfully reformat in Vista was there again with all data in it, apparentely in good shape!!!I didn't dare to make it active and test it because I am afraid to lose WIP and TWO before I can back them up (I don't have HD space! for now).

Finally I plugged the USB HD in the Vista notebook, and ONE wasn't there.

To sum up:Partitions were created in VistaA Windows 7 MBR was writtenThey were visible in both Vista and XPWhen changing active partition in XP a logical partition disappearedSubsequentely, I don't recall whether in XP or Vista, another primary partition disappearedThe two were missing in both Vista and XPMissing partitons were removed, recreated and unsuccessfully formatted in VistaA primary partition reappeared in XP, not in VistaThe logical partitions went away and only an empty extended partition remains.

Even when I get another USB HD and back up every surviving partition there, I'd like to play with this one to try adjusting things, if possible.

More than that, I'd like to understand what to do and what not to do to in future to be sure to avoid this mess.

Perhaps a workaround is always partitioning with XP and adjusting the MBR through MBRFix to Vista or Windows 7 when needed???

All you have to do is to insert in the Registry of Vista the keys that "forces" it's stoopid Disk Management/Diskpart to behave like the one of XP (and all the partitioning utilities since the dawn of time) do.

Sorry, my fault. I hadn't got that conclusion from the exhaustive links in your previous post. I've re-read them more carefully together with your observations and the implications are more clear to me.

I've now applied to Vista the registry settings as per the MS article to force it (and Windows 7 too!) to behave properly.

Thanks!

edborg

P.S.
By the way, I don't like Vista's bells and whistles and many of its non standard behaviours; for working seriously I don't need Aero and stay with XP.
I only used Vista as a host for the Windows 7 project.

I knew i saw this values before on boot-land but forgot because of not being a vistape user. http://www.boot-land...?...ost&p=72864Current topic make me understand more clearly and I guess i will (hopefully) not forget again

Are there any rule stating that partition must start and end on cylinder or track boundaries ? If so, why would there be CHS & LBA sector fields in partition table ? Isn't cylinder fields enough ?

I never known such rule exists. It is just common practice not rule. Disk partitioning softwares that assume partition must start and end on cylinder / track boundaries are faulty.

I think this problem is bug in Windows XP not Vista.

You'll have to define "rule".

DOS

FreeDOS

Win9x/ME

NT 3.51/4.00

Windows 2000

XP/Server2003

and AFAIK all Linuxes <- at least last time I checked some , which means that this can be largely inaccurate
adopt this "rule".

If you like to call it "common practice", it's of course allright , and if you only use Vista and Windows 7 you can ignore it allright.

You are perfectly right in saying that in theory there is NO need to respect Cylinder and Head boundary, and most probably it is UNFAIR that such a "non-standard" standard has been forced on so many users, but sometimes reality is unfair.

The standard BIOS settings for IDE/ATA hard disks only allow the specification of a single number for "sectors per track". Since all modern hard disks use ZBR and don't have a single number of sectors per track across the disk, they use logical geometry for the BIOS setup. IDE hard disks up to 8.4 GB usually tell the BIOS 63 sectors per track and then translate to the real geometry internally; no modern drive uses 63 sectors on any track, much less all of them. Hard drives over 8.4 GB can't have their parameters expressed using the IDE BIOS geometry parameters anyway (because the regular BIOS limit is 8.4 GB) so these drives always have 63 sectors per track as "dummy" geometry parameters, and are accessed using logical block addressing.

Vista "broke" traditions with this "feature", but if you want to adopt this new "freestyle" partitioning, you need to update all older Operating Systems that are not compatible with it, if you want to use same disk on different OS, as, as demonstrated by edborg report, in practice it is easy to have problems.

I am not at all familiar with EFI, but I presume that with that kind of booting CHS geometry and "stoopid" boundaries are gone for good.

I tried create logical partition in gparted with 1MB preceding space and 400MB size and uncheck round to cylinder.
In Windows XP's Disk Management that partition is visible.
I use Windows XP's Disk Management to created a new logical partition in remaining free space.
Then the previous partition disappear and become free space.

I guess you missed or mis-interpreted my previous statement , I am saying rather the opposite, the issue is introduced by Vista, but the corruption is caused by the poorly written XP programs:

This is of course a problem generated by Vista. (and caused by the overall utter stoopidity of the approach of the good guys at MS)

Most probably to change one single byte (the 80 to 00 or viceversa in the MBR) the stoopid disk.management re-checks the whole MBR and EPBR's, and being stoopid, wrecks an otherwise perfectly working setup.

The "stoopid" was referred to BOTH Vista (a it seems to me the best adjective to describe this particular OS) and to the XP Disk Management, besides being ALSO, and mainly referred to the good MS guys that introduced incompatibilities with their OWN tools without CLEARLY stating so and WITHOUT immediately providing a "compulsory" fix to at least XP.

For the record, the attribute started being connected in my mind with the guys at MS when they did this:http://www.911cd.net...o...=11383&st=3I lost count of how many systems I had to revive, due to that issue, which was LARGELY undocumented or mis-documented.For the record, even on systems already upgraded to SP4, and after having throwed in the bin the Win 2K 120 day trial, all third party defragging utilities (NT didn't ship with one) would cease to function, were it not for a couple of smart guys named Mark Russinovich and Bryce Cogswell , which found a (temporary) fix for the issue. Even CHKDISK did not work correctly:http://web.archive.o...com/ntfschk.htmhttp://web.archive.o...2399378,00.html

If you prefer, they elevated in XP the "common practice" to "rule", and soon after infringed that same rule they created.

All you have to do is to insert in the Registry of Vista the keys that "forces" it's stoopid Disk Management/Diskpart to behave like the one of XP (and all the partitioning utilities since the dawn of time) do.

Starting from scratch on that USB disk, would be the fastest, unless you have to recover data from it.

In any case that disk is now "wrongly" partitioned and CANNOT and SHOULD NOT be used on different OS, if not "fixed".

jaclaz

Well, apparently the registry edit was not enough to force Vista to partition "righteously" and to eliminate all inconsistencies with previous systems!

The new three primary partitions I created from Vista after the edit (on a new USB HD to recover the content of the unusable disk and to recreate the work that had been lost) did survive after being accessed from XP (and Vista again) , but when I subsequently tried to create other partitions in the unallocated space from XP (the OS I usually work with), its Disk Management refused to do that, leaving me with a partially unusable disk.

To overcome the problem I had to borrow again a Vista PC and complete the partitioning from there.

So, the unacceptable risk of losing data is overcome, but an annoying incompatibility remains between Vista and XP even with that registry edit.

Well, apparently the registry edit was not enough to force Vista to partition "righteously" and to eliminate all inconsistencies with previous systems!

The new three primary partitions I created from Vista after the edit (on a new USB HD to recover the content of the unusable disk and to recreate the work that had been lost) did survive after being accessed from XP (and Vista again) , but when I subsequently tried to create other partitions in the unallocated space from XP (the OS I usually work with), its Disk Management refused to do that, leaving me with a partially unusable disk.

To overcome the problem I had to borrow again a Vista PC and complete the partitioning from there.

So, the unacceptable risk of losing data is overcome, but an annoying incompatibility remains between Vista and XP even with that registry edit.

edborg

Hmmm. Most probably something else got wrong.I need the MBR of that disk (After having been partitioned with Vista, with the "Registry Fix" and before the attempt with XP and after final partitioning, to try and understand what's going on).All that the Registry entries should do is to restrict Vista disk management to the "old" standard of aligning the partitions to Cylinder Boundaries, nothing more, nothing less.If the partitions have been created with "old" standard alignment, they are exactly as they would be if created under XP, so there must be something else.

Hmmm. Most probably something else got wrong.I need the MBR of that disk (After having been partitioned with Vista, with the "Registry Fix" and before the attempt with XP and after final partitioning, to try and understand what's going on).All that the Registry entries should do is to restrict Vista disk management to the "old" standard of aligning the partitions to Cylinder Boundaries, nothing more, nothing less.If the partitions have been created with "old" standard alignment, they are exactly as they would be if created under XP, so there must be something else.

jaclaz

Unfortunately I haven't a backup of that MBR.More than that, something worse happened afterwards.When changing the active partition from XP all logical partitions created from Vista disappeared, as it had happened to the other disk partitioned with Vista before the registry edit.Now I hope I won't lose the primary partitions too. The situation is a real mess (at least to me) and not at all reliable.To try and understand what's going on one probably would need a third HD with nothing to lose on it, which I don't have.

If you're really willing to further investigate (but don't feel obliged to ) I enclose the MBR now, as I don't have the MBR before, plus some info obtained with MBRFix.exe and two screenshots of Vista and XP Disk Management.

As it can be seen, Vista has left 8MB of unallocated space at the beginning of the extended partition although the VDS registry values had been set to zero.This might be the cause of the loss of logical partitions (in XP and Vista) triggered by a change of the active partition in XP (the lost partitions have been accessible in both OSes before that).One explanation of why this happened (but I need your confirmation or otherwise) may be that when substituting Vista's MBR with that of Windows 7 to use primary partitions for Windows 7 installs (MBRFix /drive 2 fixmbr /win7) something was changed in the PT that shouldn't have.This has been done before creating the logical volumes that have subsequently disappeared.

In your opinion would it be possible to fix the situation without losing the content of the primary partitions that I can't easily backup somewhere else?

Yes, somehow the Registry settings didn't worked, but most probably the missing point is that once the Registry keys are applied, you must start from scratch, otherwise the initial offset won't be changed.

Your MBR is a MESS (there is NO other word to describe it).

There are "colliding" and "wrong" CHS data in it.

Attached a PTview of it.

I don't think that MBRfix has anything to do with it, the actual OS that was booted from or accessed the drive may.

In your opinion would it be possible to fix the situation without losing the content of the primary partitions that I can't easily backup somewhere else?

Let me think about it a bit , you will need anyway some "scratch space", and it is however "risky" business.

Cannot say if any of the Commercial or freeware partition resizing apps have the "granularity" features you might need.

jaclaz

Attached Files

Yes, somehow the Registry settings didn't worked, but most probably the missing point is that once the Registry keys are applied, you must start from scratch, otherwise the initial offset won't be changed.

I did start from scratch, on another brand new HD (not the previous one) and after reboot, so I really can't understand what may have gone wrong.

I don't think that MBRfix has anything to do with it, the actual OS that was booted from or accessed the drive may.

Happy about that! I gather that the fixmbr option is supposed to upgrade the IPL, leaving the PT untouched, isn't it? So the mess in the PT must have been created before, right?

Let me think about it a bit , you will need anyway some "scratch space", and it is however "risky" business.

I do have 180 GB of "scratch space" on the disk itself (320 GB) but I'm afraid it couldn't be used, or could it?.As an alternative I could back up at least the most important installation on another USB HD ... but that also has been formatted by Vista. It has had no problems (todate), but I'll have to look better into it's MBR (PT?) to check that it's not another MESS.

I did start from scratch, on another brand new HD (not the previous one) and after reboot, so I really can't understand what may have gone wrong.

Well, then somehow, either the Registry fix didn't work for you (it is reported as working by several people), or the drive was somethow pre-partitioned/pre-formatted (this is normally the case for external USB drives).

Happy about that! I gather that the fixmbr option is supposed to upgrade the IPL, leaving the PT untouched, isn't it? So the mess in the PT must have been created before, right?

Yes and No.I mean, as I see it MBRfix is "innocent" as it only deals with the CODE, leaving DATA alone.What I do suspect is that it is the initial offset of first partition that causes the problme, but only when you use XP disk management to set the third Active.In other words it is not the initial offset the problem in itself, nor is making third partition active (with a simple hex editor or with beeblebrox or from any other non-smart tool that does what it should), it is making third partition active using the XP disk management the problem it is probable that when it accesses the PT finds something "wrong" in it's stoopid smartness and attempts to correct data, failing miserably, it doesn't matter if "before" or "after".

I do have 180 GB of "scratch space" on the disk itself (320 GB) but I'm afraid it couldn't be used, or could it?.

Well, 180 Gb of space is more than enough. And yes, I think it can be used relatively "safely"

As an alternative I could back up at least the most important installation on another USB HD ... but that also has been formatted by Vista. It has had no problems (todate), but I'll have to look better into it's MBR (PT?) to check that it's not another MESS.

Why do you see it as an alternative , backing up should be an additional step.

I did some very quick tests and it seems like allright for the specific tasks, but I need to carry some more tests to make sure.

Am I correct assuming that the Extended partition is "expendable" to make on it a backup of the first three partitions (or, in other words, that all you care about is the data in the three primary partitions only)?

Am I correct assuming that the Extended partition is "expendable" to make on it a backup of the first three partitions (or, in other words, that all you care about is the data in the three primary partitions only)?