Report on retromigration installations (x64 to x86)

July 13, 2008

I am not troubleshooting here so please don't rush to tell me how to fix it.

I am just reporting. (I have filed appropriate bug reports with MS.)

Charlie has commented once or twice about the advisability of always doing a

clean install when retromigrating (my term) from x64 to x86. I ran a number

of tests of this.

I consider a clean install to be the deletion and recreation of the target

partition followed by the installation of Windows. A Custom install does

not do that. It does result in a clean installation of the operating system

in cases excepting retromigrations.

I used VMWare Workstation 6 to host a Vista Home Basic x64 guest installed

from scratch and then retrograded with an OEM (System Builder) Vista Home

Premium x86 dvd. I then performed a second Custom installation over the

first result. The problem cannot be resolved with a second Custom

installation. It can only be resolved with a clean installation to begin

with.

I have validated with:

1. A native installation of XP Pro x64 retrograded with a Vista Ultimate

x86 retail standard dvd using an upgrade product key.

2. A native installation of Vista Ultimate x64 retrograded with Vista Home

Premium x86 retail dvd using a standard product key.

3. A virtualized installation of Vista Ultimate x64 retrograded with a

retail VHP x86 dvd using an upgrade product key (twice).

There is no difference arising from the use of OEM or retail dvds or OEM,

upgrade, or standard (aka "full") product keys.

The easiest point to look for is the presence of a Program Files (x86)

folder. Keep in mind that you are looking at 32bit Windows which should not

have such a folder. There will be a windows.old folder (resulting from the

Custom install). It will remain fully populated. It appears that x86 Setup

is able to copy the entireity of the old Windows to windows.old but is

unable to make the corresponding deletes, thus the continuing existence of

the Program Files (x86). This is not the whole problem but it is sufficient

not to do a retromigration with other than a clean install.

A second Custom installation does not help even though it is being done

within an x86 OS by an x86 OS. Even going from x86 to x86 cannot correct

the situation once the user has gone from x64 to x86 with a Custom install.

This is a variation of the old problem of installing two copies of Windows

in the same partition.

A user with a standard product key can always backtrack and do a clean

installation because he can run Setup by booting with the x86 dvd. But a

user with only an upgrade product key cannot without going outside the

bounds of MS PSS supported installations (the famous workaround is not

supported). It does not appear that an upgrade edition user has the means

to resolve by a fully supported method unless he has a Windows 2000 or XP

installation cd, which if he had migrated to x64 originally from

preinstalled Windows, he might not. I doubt that MS wants this kind of user

experience.

July 13, 2008

Re: Report on retromigration installations (x64 to x86)

Colin:

Thanks for refreshing my memory on problems that were created during

beta but never addressed. Have a great day.

--

Dennis Pack

XP x64 SP2, Vista Enterprise x64 SP1

WHS, Office Professional Plus 2007

"Colin Barnhorst" <c.barnhorst@comcast.net> wrote in message

news:A5F64B81-2673-4771-964E-CBB161CE2B20@microsoft.com...

>I am not troubleshooting here so please don't rush to tell me how to fix

>it. I am just reporting. (I have filed appropriate bug reports with MS.)

>

> Charlie has commented once or twice about the advisability of always doing

> a clean install when retromigrating (my term) from x64 to x86. I ran a

> number of tests of this.

>

> I consider a clean install to be the deletion and recreation of the target

> partition followed by the installation of Windows. A Custom install does

> not do that. It does result in a clean installation of the operating

> system in cases excepting retromigrations.

>

> I used VMWare Workstation 6 to host a Vista Home Basic x64 guest installed

> from scratch and then retrograded with an OEM (System Builder) Vista Home

> Premium x86 dvd. I then performed a second Custom installation over the

> first result. The problem cannot be resolved with a second Custom

> installation. It can only be resolved with a clean installation to begin

> with.

>

> I have validated with:

> 1. A native installation of XP Pro x64 retrograded with a Vista Ultimate

> x86 retail standard dvd using an upgrade product key.

> 2. A native installation of Vista Ultimate x64 retrograded with Vista

> Home Premium x86 retail dvd using a standard product key.

> 3. A virtualized installation of Vista Ultimate x64 retrograded with a

> retail VHP x86 dvd using an upgrade product key (twice).

>

> There is no difference arising from the use of OEM or retail dvds or OEM,

> upgrade, or standard (aka "full") product keys.

>

> The easiest point to look for is the presence of a Program Files (x86)

> folder. Keep in mind that you are looking at 32bit Windows which should

> not have such a folder. There will be a windows.old folder (resulting

> from the Custom install). It will remain fully populated. It appears

> that x86 Setup is able to copy the entireity of the old Windows to

> windows.old but is unable to make the corresponding deletes, thus the

> continuing existence of the Program Files (x86). This is not the whole

> problem but it is sufficient not to do a retromigration with other than a

> clean install.

>

> A second Custom installation does not help even though it is being done

> within an x86 OS by an x86 OS. Even going from x86 to x86 cannot correct

> the situation once the user has gone from x64 to x86 with a Custom

> install.

>

> This is a variation of the old problem of installing two copies of Windows

> in the same partition.

>

> A user with a standard product key can always backtrack and do a clean

> installation because he can run Setup by booting with the x86 dvd. But a

> user with only an upgrade product key cannot without going outside the

> bounds of MS PSS supported installations (the famous workaround is not

> supported). It does not appear that an upgrade edition user has the means

> to resolve by a fully supported method unless he has a Windows 2000 or XP

> installation cd, which if he had migrated to x64 originally from

> preinstalled Windows, he might not. I doubt that MS wants this kind of

> user experience.

>

July 14, 2008

Re: Report on retromigration installations (x64 to x86)

IOW, do a clean install. <G>

seriously, does the "upgrade" SKU allow you to do a custom install that then

gives you the ability to format the partition? I honestly haven't run it,

but it seems like it should. This would allow you to get a clean install

even in this scenario.

--

Charlie.