On Fri, Oct 04, 2013 at 03:13:47PM +0000, Subramanian, Hari wrote: > Rich, > > Our workflow is something like this: > > 0. Start with a fresh copy of windows server 2k8 > 1. We read the system hive and then write to it a bunch of times > 2. Boot windows > 3. Read from the system hive > > Hivex reports the failure at step #3. I also noticed that the size of the > registry hive observed in step #3 is the same as step #0. Is it possible > that hivex issues write that cause a hive file to shrink in size and while > compacting the hive file, it retains the size but zeroes out the end of > the file?
Ah so hivex wrote the hive? That could indicate a bug in hivex or perhaps some synchronization issue when uploading it into the guest? Anyway hivex itself never shrinks the hive. In fact it only ever appends to the end of the hive, extending it if necessary (it's not always necessary). When it extends the hive it's supposed to be initializing the hbin correctly. On the other hand it's anyone's guess what Windows does to the hive in step 2. BTW the source is all open ... https://github.com/libguestfs/hivex/blob/master/lib/write.c > That would point to the trailing zeroes getting introduced in > step #1 > > It's also possible that windows is padding those zeroes in step #2. I'm > adding some instrumentation to confirm this A good start would be logging the size and MD5 checksum of the hive before and after each step, and also from within Windows (IIRC there is an MD5 checksum program in PowerShell). That would rule out some sort of non-hivex-related corruption when you're downloading or uploading the hive. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
