In This Issue: If your Windows 7 Upgrade from Vista keeps inexplicably failing, check for a setup crash dump file that points to DLARTM_N.SYS - a part of Roxio or Sonic's DVD building tools. For more details on how I got to that point, read on.
First, sorry for the long delay in updates. Blame it on busy kids, busy family, and just flat not getting around to it. But here we are.
Speaking of "getting around to it," I finally did just that regarding the migration of my laptop from the infamous Vista OS to Windows 7. Given that I had installed a ton of small video editing and developer tools that I really didn't want to blow away and rebuild, I took the potentially painful option of in-place upgrade rather than clean install.
In short, I got it to work, but not immediately. It took a little investigation, combined with three tries at the upgrade before I had success. Fortunately, the tracks left behind by the Windows 7 installer gave me enough information to figure out what was the culprit preventing my installation. I thought I'd share the info here.
First, some basics: My laptop is a Dell XPS 1530 with 3GB and a slot-load DVD burner. I had previously set up this box to dual-boot Vista and XP, and had to reconfigure partitions to allow for at least 20GB of free space on the boot partition where the in-place upgrade would occur. Fortunately, the latest copy of GPARTED handled this task with aplomb; however, be aware that moving and/or shrinking VISTA partitions arbitrarily can wreak havoc! (More on that...)
With partitions happily resized, I set out to run the upgrade. I plopped in the Windows 7 DVD, ran Setup, and chose the "Upgrade" option. After telling me that I had to upgrade my BIOS from its stock A05 revision to later A12 (which was easily down via a quick download from Dell), I retried the upgrade. As things seemed to progress, I left the machine to grind until it needed my input. How surprised I was to find, about two hours later, the scren saying "The upgrade was not successful. Restoring your previous operating system." When Vista was restored, I was confronted with a rather terminal error message, saying "This version of Windows could not be installed."
Period. Like "that's it." You're toast.
Which, of course, I didn't believe.
In most cases, I suspect you shouldn't, either.
Unfortunately, Setup leaves virtually no obvious, intuitive pointers to any kind of information about the "tracks" it leaves behind in a failed installation to tell you what's going on, where things died, or how to fix problems. Obviously, the full upgrade/installation process goes into the deep, dark bowels of your system in ways the Windows Upgrade Advisor doesn't, and thus it encounters problems the Advisor couldn't possibly predict. After some Googling and snooping on my own, I found some important files that should probably be your first stop in investigating any failed Windows 7 installlation or upgrade.
Check out \$WINDOWS.~BT\Sources\Panther\Setupact.log!!!
The Windows 7 Setup engine creates a "$WINDOWS.~BT" folder (among others) at the root of the boot partition as a bit of a "staging" area for various portions of the upgrade. Drill down from here to "Sources\Panther", and look for "SETUPACT.LOG". This little gem seems to record darned near every thing the setup engine does in the course of an upgrade - including logging (sometimes) explicit, detected failure of the upgrade. Now, with so much information, this file was close to 75MB in my case, so wading through it was no small task. Yet, my Google and Microsoft research showed that there were numerous instances where a hard failure WOULD be logged here; yet the only thing I could see was a sudden call to the ROLLBACK mode - no reason, just an out-of-the-blue call to roll back to Vista.
Although it seems the log failed, it actually helped in that I was able to determine was there were no immediate, obvious sources of failure - none that could be caught and logged. Among the myriad details in the log, including confirmation of my eligibility for the upgrade, the validity of my license, the points of reboot, there was no one, single line that said "Upgrade Failed," or words to that effect. Search your log for phrases like "Install Failed," "Upgrade Failed" (or similar words). This kinds of phrases may lead you to error codes or other possible sources of your upgrade failure. The absence of any of these strongly suggested to me that a non-loggable event killed the upgrade, such as a crash. Exploring that theory is the next step.
Despite the lack of hard error information, this remains the first file you should check in the event of a failed upgrade, and be prepared to spend some time searching it for various failure modes that you can, in turn, throw at Google for more detailed analysis and resolution.
Check for setupmem.dmp!
If you see no hard error explaining an upgrade failure in SETUPACT.LOG, the next step is to determine whether there was a hard crash or effective BSOD during the Windows 7-mode portion of the upgrade. Crashes here often occur due to disk problems, driver incompatibilities, or memory issues, none of which can be anticipated and logged in the SETUPACT.LOG.
When Setup gets beyond the point where it can run as a child process under Vista, it reboots itself into a "mini Windows 7" mode, where questionable previous system drivers get loaded into what is now an alien OS environment, creating the risk for a hard crash. This setup environment is configured to create a mini dumpfile named SETUPMEM.DMP that essentially captures the state of the system in the event of a crash (bugcheck), and which can be analyzed to review the state of the system at the time the crash occurred.
Don't be intimidated. You can likely perform a basic analysis without fully understanding what a dump file truly is. To try, you'll need the Windows Debugging Tools (available here. Do understand that crash debug tools are generally reserved for developers and tech geeks, but if you're lucky, only a basic analysis of the dump file will point to a specific driver causing the problem.
A complete crash dump analysis requires the full set of what are called "debugging symbols" that translate symbols within the dumpfile to addresses that allow the dump analysis tool to match up crash information with the module where it occurred. Fortunately, you don't have to install them - if you install the debugger tools, a command-mode kernel debugger "KD.EXE" can be invoked that can access the Microsoft Symbol Server and grab the proper symbols dynamically via the Internet, and analyze your dump file as I did:
kd -y srv"c:\symbols*http://msdl.microsoft.com/downloads/symbols -z c:\$WINDOWS.BT~\Sources\Panther\Setupmem.dmp
With the dumpfile loaded into KD, the complete analysis requires only the following:
!analyze -v
And, for me, the last two lines all-but confirmed my theory:
"Fault bucket: VISTA_DRIVER_FAULT"
"Probable cause: DLARTL_N.SYS"
We now had hard evidence that a driver designed for Vista running in Windows 7 setup was causing a crash. I made a guess that DLA was Drive Letter Access, and RTL was Run Time Library. A quick GOOGLE of the file showed in just a few seconds that the beast was, indeed, part of the Roxio CD/DVD Creator software, specifically for drag-and-drop CD creation. Even though I (thought) I had disabled Roxio prior to the upgrade, I soon discovered that this Vista-designed driver was still being loaded into the Windows 7-mode portion of setup, and causing a crash.
I finally realized Roxio wasn't going to work under Windows 7 anyway, so I went into Vista and set out to purge all forms of Roxio from my system, uninstalling close to a dozen or so different components. When that was done, and I visually inspected the drivers\etc folder for any DLA*.SYS remnants, and found none, I decided to roll the upgrade dice again late in the evening, and once it was past the user interaction steps, I let it roll overnight.
And the reward for my efforts as I rolled out of bed the next morning was a happy Windows 7 dialog asking me for a product key, which it took, and finally let me into the world of Windows 7 goodness. My theory had panned out, and my problem was solved. Roxio was, indeed, the culprit.
The info here may or may not help any given upgrade issues, because there are infinite combinations of hardware, software, and relative humidity that can conspire to cause grief, but hopefull this little assmbly of information might help *someone* out there wade through their little corner of Windows 7 Upgrade Paradise.
Blessings, all.
P.S. One more thing about moving/resizing Vista partitions: I promised a bit more about how moving/shrinking Vista partitions was a dangerous task, and here's why. With the advent of Vista, Microsoft is laying the groundwork to get away from BIOS-based interrupt services to decode boot-time drive information, which means (in turn) getting away from what most of us old-timers know as cylinder-head-sector (CHS)-based definition of drive partitions. For reasons I won't go into in detail here, the Vista Bootloader expects to see a bootable Vista partition on a sector boundary that corresponds to exactly one-megabyte. Since sectors are 512 bytes, it'll take any multiple of 2048 to land exactly on a one-megabyte "boundary." If you move an established Vista partition anywhere else, the Vista bootloader won't find it, and you'll have to use other tools to move the partition back where it can be seen....repartitioning tools like GPARTED don't know about the Vista Bootloader or its boundary rules...so will move a boot partition wherever you tell it.
No comments:
Post a Comment