Bad block on source

[lensv]

When I try to make a P2V with VMware Converter it fails with the message that the source drive has bad blocks. I have run chkdsk.exe on the computer in question and it has "fixed" the problem (no more bad blocks on the volume), but VMware Converter still seems to see the disk as faulty. Is there a way to get around this... or am I f*cked?

[victorg]

Are you using version 4.0 or 3.X ? Please attach your logs.

[lensv]

I use 3.0.3 (didn't know there was a newer version out there). Log files are coming up...

[continuum]

You could do a manual filecopy using a tool like "unstopable copier"

___________________________________

description of vmx-parameters:

VMware-liveCD:

[lensv]

I'm not sure I understand what you mean by copying... Anyway, I prefer using supported tools when doing this. Hopefully those log files may contain something useful...

[continuum]

If you ever find a vertsion of Converter that supports importing corrupt disks please tell us all

___________________________________

description of vmx-parameters:

VMware-liveCD:

[lensv]

I sure will... Since Victorg (who obviously is working for VMware) asked for the logs I assume that this should be possible.

[R-Sommer]

How about creating a new virtual disk of the same size, booting your VM with Knoppix, GRML, TrueImage, BartPE or any other suitable Live CD and finally copying the files/partitions from the faulty disk to the new disk?

[lensv]

No success with Ghost either

-> Victorg! Have you found anything in those log files yet?

[R-Sommer]

So Ghost failed to create an image of your physical pc, right? If so, you have to fix this problem first and not try to use VMware Converter. I mad lot of bad experience with Ghost, maybe you should use a IMHO more functional SW like Acronis TrueImage.

[lensv]

After several tests I'm no longer sure that the problem really arises from the bad block. When running the converter it stops at different percentage levels each time and the real error message actually says "Unknown error returned by VMware Converter Agent". The "Bad Block issue" is only a warning...

Therefore I'm really curious about those log files. Please take a look at them and please respond to this thread as soon as you find something...

[xe]

"Unrecoverable error 2 reading 65536 bytes starting from 0x00000001aaf8b000 from the source volume"

Not sure if this is a bad block or a controller failure? According to your logs the source has a lot of bad blocks that appear in groupings at regular intervals. If there's a problem with either the controller or disk, the hardware may 'stall' while it attempts to recover from the error. The OS may see this as an I/O error or bad blocks, usually a whole bunch in a row while the hardware is unresponsive to the I/O request.

Check the system's Event Logs for errors from source "Disk". If the source is actually a hardware RAID it's more likley to be a controller problem or an inconsistent state in the array. This is very likley a hardware problem. If your vedor has diagnosticsoftware you can run this may be of some assistance in pinpointing it.

You can try Ghost, setting it to ignore bad blocks. However if this is a controller problem you'll likley see the issue with Ghost also.

[continuum]

I would use BartPE and do a filebased copy with "unstoppable copier"

___________________________________

description of vmx-parameters:

VMware-liveCD:

[victorg]

I would suggest using Converter 4.0. It handles bad blocks better (normally ignores them). You may want to try file-based cloning (change the target volume size). It's a long shot, but it may help. And you definitely need to run chkdsk /f before conversion.

[lensv]

Now I've tried VMware Converter 4 and things actually went a litte bit better this time (ít didn't fail until 75%). These logfiles seems to be quite different, so I upload them here and hope for some more responses. Maybe someone can find out what is really stopping the conversion...

I have run checkdisk several times and after repairing the bad block it doesn't find any more errors. In the system event log I can find a couple of VolSnap entries though (containing the info. "The shadow copy of volume C: was aborted because of an IO failure"), but I don't know what that really means or if it affects this job in any way.

[victorg]

Looks like you have a serious disk problem. We rely on VSS snapshot when doing hot-cloning and apparently the snapshot fails due to bad blocks. You may want to try chkdsk /R if you have not done so already, or you can try to image your disk with third-party software.

[lensv]

Alright, now I have actually managed to successfully make a clone of the "corrupt" disk with Converter 4, even though lots of disk error entries were written in the system log. I switched back to block-level cloning (changed the target disk to become just slightly larger than the original disk) and that did it. I don't know if I was just lucky, but shame on those who gives up easily

unfortunately there is still a problem... When starting up the new VM it hangs with a blue screen showing the message "Configuration file is not unicode". I can start and log on in Safe Mode and I have also tried to upgrade/repair the installation with a Windows XP SP3 CD, but when staring up normally the system still hangs at the same point. Does anyone know what "Configuration file is not unicode" means and how to get passed it?

*Edit: The installation of WXP SP3 doesn't really finish. It stops after the first reboot (with the blue screen error mentioned above). After this I can no longer enter Safe Mode either since the installation needs to be completed...

[xe]

Does the virtual machine boot into graphical mode? A real "blue screen" should have a STOP error code on it and no mouse pointer.

If you're getting something about Setup when starting in Safe Mode it sorta sounds like its going into mini-setup or something?

Either way this means a critical file is corrupted on the virtual machine.

You said you resized the hard disk during conversion (this puts it in volume-based cloning, not block-cloning). That would have been my only other suggestion. Can you check the Converter logs for skipped files? There will be a message in the log if it had to skip a file. You might have more success with the Cold clone CD.

[lensv]

It's not a "real" BSOD... It is just a blue colored screen With a Windows XP logotype showing the message "Configuration file is not unicode". I have no idea what this means, so if anyone knows please let me know.

Concerning the conversion... I first switched to file-level cloning by making a major change of the disk size, but when I went back to almost the same size as the original (49.9 GB -> 50 GB) it actually made a block-level cloning (at least that's what the app. stated).

[victorg]

lensv, can make a snapshot of the screen with "Configuration file is not unicode message"? can you attach the log bundle for that conversion? I have a sneaky feeling it has to do with sysprep. Regarding the conversion mode, we fall back to file based cloning only when you shrink the volume.