XP-32 can't read dynamic disk set after Win7 install

[Richard Jones]

I've got XP Pro 32-bit, XP x64 installed and did a clean install of
Win7 Pro. I have a couple of dynamic disks which have stripe and volume sets
on them. Win7 apparently "touched" them in some way and XP 32-bit can't read
them. Trying to "reactivate" in Disk Management produces errors in the event
logs of "Format Error was found in configuration copy" and "Internal Error:
The disk group contains no valid configuration copies".

Now, XP x64 can read the dynamic disks just fine (as well as Win7
which continues to read them). It's only XP 32-bit that fails.

 

[Andrew E.]

In xp,try run,type: cmd In cmd type: DiskPart In DiskPart,type: list disk
type: list volume If the hds are in a readable state,xp should show them.
Type: HELP For all DiskPart cmds

 

[Smiles]

ok depending on raid controller you may not have permission on xp32-bit
to read my only thought ntfs should be the same in both 32 & 64 bit system

 

[Richard Jones]

This is something Win7 is doing to the dynamic disk configuration
data. I backed up the data, then, under XP 64-bit, deleted the volumes
completely, then recreated them (it was two stripe sets, one spanned volume,
and one simple volume on a total of two disks). I then booted XP 32-bit. It
saw the disks as "foreign" as expected, I imported them, and all was well.
Booted back and forth between XP 64 and 32, writing the disks, and all was
well.

I then boot Windows 7 and import the disk set. It sees all the
volumes. Now, I boot XP 32-bit, it sees them as "foreign" again, but the
import operation fails ("no valid configuration copies" in the event log). I
boot XP 64. It sees them as foreign, but it imports them again fine. I go
back back and forth between Win7 and XP 64-bit reading and writing with no
problems. But XP-32 cannot import them.

I did this a second time, deleting the volumes under XP-64 and
recreating. Same thing.

Once Win7 imports them, it "touches" the configuration data in some
way that XP-32 can't handle, but XP-64 can.

 

[Smiles]

ok you have done all I would do I only tried W7 as I do not have it up
and running this is all I can advise.

 

[Richard Jones]

I contacted MS tech support about this, and all they did was deny that
Windows 7 would make any changes to the disk configuration. It obviously
is. I'd like to figure out just what's going on.

 

[Richard Jones]

Well, I solved the problem. Turned out to be a driver problem,
apparently. This IDE card used the HPT 370 chipset (I put in a new
motherboard which had only one EIDE channel onboard and so used this
HPT-base card I had so I could continue to use my old EIDE drives along with
SATA).

Now, HighPoint only put out Vista drivers for 64-bit, and I was
using that for XP 64 as well as Windows 7. The XP 32-bit install was using
the last pre-Vista drivers. Well, on a lark, I decided to try the 32-bit
Vista driver for XP and lo and behold it loaded and worked fine. Then I let
Win7 import the disk sets.

I booted XP-32. Well, it saw them as foreign due to whatever
changes Win7 makes. I crossed my fingers and tried reimporting. It worked.
Success.

Now, I didn't even think about this being a driver issue because the
Logical disk manager is "on top" of the driver, I thought -- it does its
thing at a level about the disk driver. But that was it, and how and why I
don't know.

 

[John John - MVP]

Thanks for letting us know how you fixed it.

John

 

[Richard Jones]

Well, I spoke to soon. After letting Win7 write the disk sets a bit, I
booted back into XP 32 bit, and Arggghhhh! It showed the disk sets as
"inactive" (not "foreign") Trying to reactivate failed with the same "no
configuration copy can be found" error message. And XP 64-bit continues to
have no problem.

Changing the driver did "help". XP 32 bit was able to reimport
what it now saw as foreign disks. With the old driver it couldn't do that.
But still Win7 makes some changes that it still can't handle. :sigh:

It has no problems with basic disks between them. Depending on if I
feel like it, I might try a different EIDE card and see if that fixes it. Or
I might just recreate the partitions as regular ones on basic disks. Or just
forget about Win 7.

 

[Paul]

Well, I spoke to soon. After letting Win7 write the disk sets a bit, I
booted back into XP 32 bit, and Arggghhhh! It showed the disk sets as
"inactive" (not "foreign") Trying to reactivate failed with the same "no
configuration copy can be found" error message. And XP 64-bit continues to
have no problem.

Changing the driver did "help". XP 32 bit was able to reimport
what it now saw as foreign disks. With the old driver it couldn't do that.
But still Win7 makes some changes that it still can't handle. :sigh:

It has no problems with basic disks between them. Depending on if I
feel like it, I might try a different EIDE card and see if that fixes it. Or
I might just recreate the partitions as regular ones on basic disks. Or just
forget about Win 7.

There are a couple things down at the end of the device. There
would be the 1MB database used by the dynamic disk.
There is also the 64KB or smaller metadata used by a RAID
controller, to keep track of disks in an array. There are normally
mechanisms in place to prevent collision. On my RAID controller,
the controller indicates the disk is smaller than it really is, so
that writes to the data portion of the disk, can't touch the
metadata area. The driver is responsible for enforcing this. If
I move my disk to another controller, or change to a non-RAID driver,
I may be able to examine the RAID metadata. I've done that
with my controller, and found a 4KB chunk with 16 data structures
in it. That is the metadata that keeps track of RAID arrays. That
gets written during array setup.

I don't have a "disk editor". Instead, what I do, is use a port of "dd"
to be able to copy small regions from the disk. And then, examine the
resulting small file with a hex editor. My hex editor won't examine anything
larger than 2GB in size, so I have no choice but to "think small".

http://www.chrysocome.net/dd

The command "dd --list" tells me my test disk is 33554432 sectors long.
If I issue a command like this, this copies 16MB from the very end of
the device. I picked that size, as a cylinder is 8MB, and I wanted to
make sure no matter how bad my math, that I got a snapshot of the
1MB dynamic disk database. So I decided to snapshot two cylinders
worth, to cover that area. (In fake geometry terms, a cylinder is
255 heads and 63 sectors, 512 bytes per sector, giving about 8MB or so.)

dd if=\\?\Device\Harddisk2\Partition0 of=big.bin skip=33521664

The "skip" option starts the copy operation near the end of the raw disk.
33554432 - 33521664 = 32768 sectors, times 512bytes = 16MB of data.
The "big.bin" file ends up with that data. I use a hex editor on
that, to find the 1MB dynamic disk database. It is pretty sparsely
occupied, since I have a simple volume with one partition. It didn't
seem to be butted up against the end of that space, and I think I
had maybe 350,000 bytes empty at the end.

So that is an example of a tool you can use, when you can't afford
a sector level disk editor. Maybe you can take a snapshot down near
the end before and after the corruption occurs. Then compare them,
and figure out what changed.

("dd" runs from the Command Prompt, so you type that stuff into
the Command Prompt window.)

Paul

 

[Richard Jones]

Thanks for the suggestions. What I finally did was just give up using
the dyanmic disks and go back to basic disks. It was too easy for Win7 to
mess them up (running setup to reinstall or do another clean install would
always "touch" the dynamic disks).

To make this clear, while I was using an HPT-370 RAID card, the
card was not in RAID mode. It is simply functioning as a regular IDE
controller. The stripe sets on the dynamic disks were done using Windows own
Dynamic Disk LDM, not the RAID card software. So whatever the "corruption"
(well, it was something Win 7 and XP 64-bit had no problem with, only 32 bit
XP -- I'd bet that Win2K3 Server could handle it as. XP 64 is versioned as
NT 5.2 along with Win2K3, while XP 32-bit is NT 5.1 -- I'll bet the 5.2
codebase would all handle it, while it's just the 5.1 that can't, whatever
it is) was, it is with Windows own LDM code.

If I had the time and another machine to play, I'd try to
investigate this further just to see, but this is my main working machine
and I need the data on those disks up.