mOS for Vista: WinPE, WinRE and Bart

With Vista, one loses some friends and gains others, with Vista-64 being particularly challenging. You can use XP-based Bart to do many things in Vista (especially hardware diagnostics) but nothing has the ability to redirect registry access on the fly as RunScanner does for XP on Bart, which is a significant limitation for Vista maintenance.

The players are:

• MS WinPE 2.0 for XP, 2003 and Vista
• MS WinRE for XP, 2003 and Vista
• Bart PE, current XP/2003 version
• Bart 4 for Vista, XP, 2003 etc.?

Bart 4 is but a rumor at this time, and may stay that way awhile. As MS WinPE 2.0 is now available to general users, and as Bart has experience with earlier MS WinPE, he may develop a GUI front-end for that instead (I'm just guessing here, but that's what I'd do).

My Vista Curve blog will cover WAIK, WinPE 2.0 etc. as I grow my Vista maintenance skills. There are also walk-thoughs for building MS WinPE 2.0 solutions, and blogs from the Microsoft WinRE and WinPE teams.

I was going to develop MS WinPE 2.0 as a separate mOS project, but a better way might be to cross-develop Bart PE to be used as an extension of the MS WinPE environment. This is suitable for techs with an \i386 file set, but is tricky otherwise. On the other hand one could easily build a gutted Bart with no bootability, no OS, and just the nu2menu interface to collected tools.

MS WinPE 2.0 seems harder to build and use than Bart PE. The Bart equivalent of those 4-page walk-throughs is "install Bart PE builder, run it, and follow the UI that pops up". Once you have the skills, similar things should be possible in MS WinPE 2.0, but those who find the Bart skills investment too high will bounce off WinPE.

MS WinPE runs in RAM, allows the boot CDR to be removed, and allows arbitrary CDs and USB sticks to be hot-swapped - so the potential is there to launch your Bart CDR from a MS WinPE boot via an accessible "pull tab". On the Bart side, you'd either have a Vista-specific nu2menu, or logic within the menu and/or plugins that filters and modifies things to work (or not be offered) in Vista.

My Bart project is already down this road, built for compatibility with...

• Running from output subtree on the build PC
• As accessed from DOS diskette boot
• Autorun from Windows 2000, XP
• Autorun from Windows 9x
• Booted into Bart mOS

...so adding "run from MS WinPE boot" is just an extra step.

You can already manually run a Bart PE CDR's menu from an MS WinPE boot session. Some tools don't work as needed code files or registry settings aren't present in the WinPE runtime, and that may be a ball-breaker to fix. Some tools don't run due to permissions issues, and may run if it were possible to do the equivalent of right-click, Run as Administrator within the WinPE environment. Others work just fine.

The nu2menu system has some breakage when run from an MS WinPE 2.0 boot. So far, one issue I've picked up is that the very useful GUI file/folder selector feature fails to populate the namespace tree, so you can't use that to set Temp etc.

As an MS WinPE builder, you'd likely have or will soon build skills in XML. The nu2menu system is XML-based, and could be used in two ways (as I do in Bart):

• UI front-end for the build process
• UI front-end or shell for the mOS runtime

The MS WinPE build process would benefit greatly from some sort of GUI front end, and nu2menu would be useful for that. It runs as an unobtrusive button in one corner of the screen, and from there it fans out like the traditional Win9x Start menu, but with a lot more power and logic.

HD Replacement and Bad Cluster Markers

This is a common scenario...

• Hard drive develops bad sectors
• File systems have some clusters marked as Bad
• You image partition(s) from old hard drive to new replacement
• New hard inherits bad cluster markers that are now inappropriate

...that can present in interesting ways, if file system is NTFS:

• BING images the sick hard drive OK
• BING images the contents to new hard drive OK
• You use BING to shrink the partition
• BING checks the file system OK
• BING shrinks the file system OK
• BING re-checks the file system, and fails!

The FATxx equivalent is more like this:

• BING images the sick hard drive OK
• BING images the contents to new hard drive OK
• You use BING to shrink the partition
• BING checks the file system, fails!
• You manually clear bad cluster markers
• You use BING to shrink the partition
• BING checks the file system OK
• BING shrinks the file system OK
• BING re-checks the file system OK

What is going on here? Well, it depends on the file system.

With FATxx, BING sees the bad cluster markers when it checks the file system before it attempts the resize, "sees" the bad cluster markers inherited when the file system was imaged off the old hard drive, and backs out of the resize. Only when you clear these bad cluster markers (as you should) will BING attempt the resize, and will then generally succeed.

With NTFS, BING fails to see the bad cluster markers and is happy to resize the volume, which is dangerously inappropriate if the volume is still on the sick hard drive. NTFS points to bad clusters by cluster address; if these point beyond the end of the file system after the partition is shrunk, they are seen as invalid by BING's post-resize file system check.

Clearing Bad Cluster markers in FATxx

If there's a better way, I haven't found it! What I do is edit the file system on the new hard drive using ye olde Norton Disk Edit, selecting the two FATs in different panes, searching these for the raw byte sequence that marks a bad cluster, and editing these to 0 (free cluster available for use). When done, a file system check can be expected to detect FAT32's boot record free space value to be incorrect, and I allow that to be fixed.

Obviously this is serious caveat territory, and I look up FAT details to see what the Bad Cluster value is, and then run into byte-order toe-stubbers while searching for these. Norton Disk Edit runs from DOS or a Win9x DOS mode, and DOS can't safely "see" beyond 137G, so more caveats there.

Clearing Bad Cluster markers in NTFS

I haven't found an easy way to do this, but the process is documented at Katy's Homepage - so if you know of any free tools that can automate this, please comment with details!

If the Bad Cluster pointer is invalidated by shrinking the NTFS volume or partition, as described above, then the invalidated pointer will be "fixed" (cleared?) by ChkDsk /F

The problem is those Bad Cluster records that remain valid, and thus are not cleaned up by ChkDsk /F, or (if marked clusters are not re-tested) by ChkDsk /R.