Gah… I really hate doing windows… June 19, 2005 at 10:48 am
If you have an amd64 based system like I do, and wanted to test out the Windows XP x64 edition, but also realize that it might be a good idea to have the 32bit XP installed too, learn from my mistake. You can dual boot them just fine… _but_ you *have to install x64 AFTER 32bit XP*.
Imaging my surprise when I went to boot back into x64 after installing XP on my 2nd HDD only to be greeted with a “Unable to load %windows%/system32/ntoskrnl.exe file, please replace file” or something similar.
Searching the web and even MS’s knowledge base (which pathetically doesn’t even have the x64 edition listed as a product to search yet… lovely) left me trying my own stuff. Turns out the only fix was to do a repair install. For those that don’t know, that’s not the repair console.. you boot off the cd and go through the steps to install windows, but after you choose the partition that already has x64 on it, it’ll say it sees it. It’ll then ask you to hit R to do the “repair install” or to hit return to do a fresh one. The repair install seems to load the default data off the cd again, but the good news is that you don’t lose anything. Thankfully when I finally booted x64 again, it was just like I left it. Though that damn repair install took a good 1/2 hour, not to mention the 2 hours I spent searching the net and trying things in the repair console like the bootcfg command.
My educated guess is that the bootloader loaded by 32bit XP couldn’t bootstrap into 64bit mode for the x64 kernel.. whereas the x64 one can, and can drop back into 32bit mode when loading normal XP. It makes logical sense once I realized that’s what the problem was.. but I find it frustrating that there’s no info on that on the MS site (at least that any searching I did could find) and that it took such a long run to fix it for the fix that worked. It’s especially frustrating that there’s no data on MS’ site when my searches showed that I’m nowhere near the only person that’s run into this problem either.
Oh yeah.. not to mention that I couldn’t even install x64 origianlly without disabling my onboard sata controller (even though I was installing on PATA disks).. another thing I figured out on my own. If I didn’t disable it, the first boot into the setup program (after booting from CD and watching it copy files to the hdd) would just hang. Pathetic for a brand new windows release.
*sigh* lesson learned I guess…
I found an easy solution myself. Go into the boot list, and there was a new choice after installing x64. It was called L13000. My best guess is this might be the L1 cache for my cpu (3000+). Possibly it caches certain files into there and a bug in x64 forgets about them or something. I am by no means an expert on how software and hardware work together though, so I cannot come to a true conclusion on why this fixed the problem.
P.S. I installed to a SATA drive no problem. The only catch I ran into was needing to alter the boot sequence from my HD to that L13000.