This thread may help:

https://www-secure.symantec.com/connect/forums/ghost32-crc32-fails-consistently-winpe-20

Otherwise, please indicate what aspect of the CRC check you need help with.

Essentially, this is just a switch which was used internally by the QA folks as a cheap way to verify Ghost restores without needing any additional tools; it doesn't have any practical end-user application beyond warm fuzzies.

As a side note, Ghost internally doesn't *actually* use CRC32 internally on the image despite what the manual says and never has (which is a long story; I discovered this and explained it to Murray when I was first transferred to Binary Research in 1997, but as it was already out in the field no-one wanted to bother to replace the broken code, which has less error-checking power than CRC-32, with a correct version).

In essence, if you want some kind of reassurance that Ghost has put the volume down accurately then you can use an external tool to gather MD5 or SHA-1 hashes of the original volume content before imaging and then after restore; it's no slower than CRC-32 on modern hardware and there are endless free implementations of MD5 or SHA-1 to choose from, and these provide a better independent check on Ghost (and in forensics applications, where they are interested only in bit-for-bit equivalence of the raw disk surface, only a secure hash of that tends to be used).

However, given that doing a full verification like this requires reading the entire volume again, which will typically take just as long as it did to clone it, it's hard to argue that it should be a part of a regular process given that it'll never tell you anything useful. It's there for an independent check but Ghost's internal checksums already catch every external error in the transport of the image (especially with high compression, which is done with zlib code and thus adds an additional layer of Adler-32 checksumming on top of everything else, which is already more than enough in practice).

Essentially, the only two things these external double-checks could potentially reveal are a) a developer fault in Ghost32 itself, which you won't ever see because it's already tested this way far more thoroughly than you can accomplish or b) a hardware fault in the chipsets you are using which corrupts data in the path from memory to the bus (again, vanishingly rare in real life and not worth the large amount of time it takes to test for).