Stuck on "Preparing Your Desktop" after removing old HDD

EvilIguana said:

I recently bought a SSD and used Acronis TrueImage to clone my old windows install onto the new disk. So long as I leave the old HDD installed I have no issues booting up on the new lightning fast SSD. If I unplug the old HDD, however, I run into problems. In that scenario, after inputting my password, the system spends several minutes stuck on "Preparing Your Desktop" after which I get a blank, light blue screen with the words "This copy of windows is not genuine" in the bottom right part of the screen.

This is an issue because my plans have been to eliminate the old drive and replace it. I have some concerns about its reliability due to its age and at any rate I shouldn't have to have an extra HDD plugged in just to use my main OS install on the SSD.

It sounds like there is a problem with the way it was setup. Post a screen shot of your Disk Management with the columns expanded so we can read the print. Disk Management - Post a Screen Capture Image

When you were setting up your SSD, you had the other drives connected to the Motherboard and the boot manager got copied to D: drive. You always need to unplug all drives when doing this or you can see what might happen. == You need to get the files from D: to C: so you can boot from the SSD. Use this tutorial to copy the files. Bootmgr - Move to C:\ with EasyBCD If you have any problems, check back. I am not sure if the files (System, Boot, Active) will be gone from D: or not, but we can tackle that later.

I have solved my issue by using the info in this thread. As a public service I shall now explain what I think went wrong and how I think I fixed it.

This story starts about two weeks ago. There are two relevant HDDs, WD black 640 GB models both, that we will call alpha and beta. Alpha was my system disk and beta was an older no longer completely functioning (due to hardware change) Win7 install. Both were relatively old disks and I felt that it was a good idea to have a backup of my main windows install. So I copied everything I needed off beta onto alpha and proceeded to wipe beta with EaseUS partition master. Then when I restarted my system would not boot.

This is how I discovered that when you install Windows 7 from the DVD it will always write part of the boot data to the first HDD in the SATA order regardless of which drive happens to be the one it is installing to. After a few hours of fruitless attempts to get drive alpha fixed so that it would be bootable, I gave up and just reinstalled Windows 7 on drive beta, but only after moving it to the first SATA slot on my motherboard.

I was still a bit concerned about the age of and some of the sounds made by the drive that I was using. I decided that this was the perfect opportunity to upgrade to a solid state drive. So I ordered a 512GB Crucial MX 100 as well as a 1TB WD Black for general storage purposes. I used Acronis TrueImage to make an exact clone of my system drive, drive beta, on the new SSD. Here is where I think I may have caused a problem: Before I started my PC for the first time after the clone, I switched the SATA cables around so that the SSD was in slot 1. I did this because my experience of the previous week had made me paranoid about having the system disk in any other position. The other drives remained plugged in but in different SATA slots than previously. I made sure that my BIOS was set for boot off the SSD and then started, and things appeared to be in working order.

The issue that I made this thread about is what happened when I unplugged drive beta. Apparently by reconfiguring the SATA slots I had confused windows. I was booting off the SSD but still running windows, at least partially, off of drive beta. That explains why I saw speed gains in the boot process but no noticeable decrease in load times for my software. And since I had created an unholy FrankenSystem running off of two drives, that probably explains why Windows would not properly load when I removed one of them.

Ultimately I fixed it by changing the drive letter assignments in the registry as suggested in the thread I linked a few paragraphs up. There is one more thing to note. Before I performed this fix last night, I installed EasyBCD onto drive beta as suggested in bigmck's last reply. It put a shortcut on my desktop. After the fix, the EasyBCD shortcut was on my desktop on the SSD install, but shortcut was nonfunctional as the program data was not installed on that disk. So I'm guessing that when I was running with drive beta as system drive C: it was using the desktop folder on SSD drive D:, providing further evidence of the FrankenSystem hypothesis.

So hopefully that will prove edifying or at least interesting to someone. I honestly had not not realized that this type of thing was possible. So at least I learned something.