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? 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
Thanks for your help!
~ Hari
On 10/4/13 11:01 AM, "Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Fri, Oct 04, 2013 at 02:12:08PM +0000, Subramanian, Hari wrote:
> To respond to you question about "whether it fails", hivexsh is unable
>to
> open the hive file and it prints this message and exits. I've attached
>the
> verbose logs as requested
OK, I understand it now. It is in fact failing, setting
errno = ENOSYS and returning an error.
> This extract from the logs shows that the hivexsh complains content
>after
> file offset 0x77c000 is garbage
>
> hivex: badsys: trailing garbage at end of file (at 0x77c000, after 1849
> pages)
>
> So, I went ahead and truncated the contents of the file after that file
> offset and hivex was able to successfully open the new hive file
I guess if the hive comes from a real guest we can change this to warn
but not fail.
Should be a pretty simple patch.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/