I have manage to create the backup image using dsfok: dsfo \\.\PhysicalDrive1 0 0 DsImage.img

I am using a Win 7 PC for my efforts so I had to use LockDismount to allow me to write to the new CF card with: dsfi \\.\PhysicalDrive1 0 0 DsImage.img

Both seemed to work fine and I noticed the same error reported in the aforementioned thread.

I tried to boot the computer with the new copied drive and it hangs at the Verifying DMI Pool Data.... as in the other thread.

I tried to step through post #13 of that thread and I was able to create the bstestmod.bin and modify the original image file as described but it still does the exact same thing as before where it gets hung at the Verifying DMI Pool Data...

The mentioned thread DOES NOT mention an issue at "Verifying DMI Pool Data", the OP had a different kind of issue and a specific solution (or workaround) has been provided for that specific diagnosed issue, a mismatch on CHS geometry on differently sized CF cards is a common enough issue, but usually it does not cause as symptom (and at least did not in the given thread) a "Verifying DMI Pool Data" hang.

Let's diagnose your specific problem first, then we will see if that same solution can solve it or if something else is needed.

Thanks for your response and sorry if I gave any incorrect information or I misunderstood something.

To start from scratch... I have little embedded PC's that boot that have Win XPe installed on them. The currently used CF cards are iCF 4000 made by InnoDisk. The PC has a push-button on the side of an attached display that should be used to shut the PC down correctly, but either due to operator error or loss of power, the Windows file structure becomes corrupted. I would like to make a backup image file that I can use to reload the entire disk and change from the currently used iCF 2 GB industrial cards to a more available SanDisk Ultra 4 GB CF card. The reason I want to do this is two-fold... The current OS and all programs consume about 1.8 GB of the card, leaving very little space and obtaining the other cards is cost/time prohibitive.

So basically, I want to take a bootable 2GB iCF CF card and create a backup that can be loaded onto a 4GB SanDisk CF card and make it boot so that if the OS fails, I can simply swap out the card to get the machine back up and running quickly.

I used DSFOK to create an image of the disk after locking the drive with LockDismount; the following is the results from the command prompt:

Next I placed in the new SanDisk 4 GB CF Card and formatted the card with HP USB Stck Format Utility and ran chkdsk on it:

F:\>chkdsk

The type of the file system is NTFS.

The volume is in use by another process. Chkdsk

might report errors when no corruption is present.

WARNING! F parameter not specified.

Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...

256 file records processed.

File verification completed.

0 large file records processed.

0 bad file records processed.

0 EA records processed.

0 reparse records processed.

CHKDSK is verifying indexes (stage 2 of 3)...

274 index entries processed.

Index verification completed.

0 unindexed files scanned.

0 unindexed files recovered.

CHKDSK is verifying security descriptors (stage 3 of 3)...

256 file SDs/SIDs processed.

Security descriptor verification completed.

9 data files processed.

Windows has checked the file system and found no problems.

3903456 KB total disk space.

21568 KB in 5 files.

8 KB in 11 indexes.

0 KB in bad sectors.

22356 KB in use by the system.

21568 KB occupied by the log file.

3859524 KB available on disk.

4096 bytes in each allocation unit.

975864 total allocation units on disk.

964881 allocation units available on disk.

Then I used LockDismount to lock the drive then ran dsfok as below:

C:\dsfok>dsfi \\.\PhysicalDrive1 0 0 Backup.img

OK, written 2096889856 bytes at offset 0

I unlocked the the F: drive and ran chkdsk on the new card:

C:\dsfok>chkdsk f:

The type of the file system is NTFS.

WARNING! F parameter not specified.

Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...

7104 file records processed.

File verification completed.

20 large file records processed.

0 bad file records processed.

0 EA records processed.

2 reparse records processed.

CHKDSK is verifying indexes (stage 2 of 3)...

9328 index entries processed.

Index verification completed.

0 unindexed files scanned.

0 unindexed files recovered.

CHKDSK is verifying security descriptors (stage 3 of 3)...

7104 file SDs/SIDs processed.

Security descriptor verification completed.

1112 data files processed.

Windows has checked the file system and found no problems.

2015968 KB total disk space.

1445020 KB in 5715 files.

1948 KB in 1114 indexes.

0 KB in bad sectors.

19744 KB in use by the system.

12128 KB occupied by the log file.

549256 KB available on disk.

4096 bytes in each allocation unit.

503992 total allocation units on disk.

137314 allocation units available on disk.

From everything I can see... It appears to have duplicated the card... The only apparent issue being that it has lost the extra 2 GB of storage.

Next I put the newly created card into the PC and tried to boot it up. After the Verifying DMI Pool Data... I get an error in German as this is where the PC's originate: "fehler beim lesen des datenträgers" Which is a Disk Read Error...

I think this may be due to the different size/manufacturer of the CF Card... Your thoughts on the next steps?

But (just like the OP in the original post you referred to) you are "mixing things" (don't worry, it is also "normal").

The chkdsk you ran is (no offence intended) "irrelevant", as well as the formatting with the HP USB tool (which besides being a tadbit oldish today is unneeded as when you later restore the backup.img you overwrite anything that it did).

By using DSFOK you duplicated to the backup image and then restored it back to the new card the "whole thing" the DISK or \\.\PhysicalDrive, rest assured that your backup image is EXACTLY the same of the original and that the new card contents (up to the size of the original one) are EXACTLY the same.

BUT the actual cards are of different size and as such they are very likely to expose a different geometry (you have the same contents on different media, and the media may expose a differently "indexed" device).

A 2 GB device may (example) expose a HS geometry of 64/32, your partition layout (as seen in a partition table editor) may look *like*:

07 80 0/1/1 2.048/0/32 32/4.194.304

and in the bootsector you will have the values 64/32 as Head/Sectors, the bootsector code checks that the disk geometry is reported as 64/32 and boots.

A 4 GB device may (other example) expose a HS geometry of 255/63, so when the control passes to the bootsector code and the reported geometry is different form the 64/32 stored in the bootsector data, it panics and throws an error.

All volume access under NT and later substantially ignores CHS geometry and uses instead it's LBA translation, with an EXCEPTION which is the code (in the bootsector) that actually allows booting and that makes use and checks the actual HS geometry as sensed by BIOS.

In the above examples, once you will have restored the 2 GB card "whole device" image, there are two solutions (or way outs) for this:

1) modify the code in the bootsector in such a way that the check for consistency with HS geometry is not used, which is what worked for the OP on the other thread, using the KILLCHS tool to remove the check

2) fix (correcting/adapting it) the data in BOTH the MBR and in the bootsector as to reflect accurately the geometry of the actual media/device, nothing particularly complex, but you have to understand the concepts before going on.

Normally this should work (though it is well possible that for one reason or the other we will need to use solution #2 instead, adapting to a given geometry and recreating a "balanced" CHS/LBA situation respectful of the "sensed" geometry).