Problems with corrupted hv-files generated from regcomp during makeimg

Hello together,

we have serious problems with corrupted hv-files generated from regcomp
during makeimg. For building our Windows CE 4.2 image we call cepb from a
batch file during our automatic build process. For a couple of builds (about
30%) the resulting nk.bin does not boot correctly on the target device (the
filesystem does not start up correctly and the device hangs). The difference
between a "good" and a "corrupt" image is only within the .hv-file within
the flat release directory (boot.hv, default.hv and user.hv). These are
generated from regcomp.exe during makeimg from the reginit.ini file.

The difference of the binary hv-files is not only in the beginning part of
the file (where there seems to be some random information (mostly the
environment variables from the build machine), which are used for padding
the files) but also in the back of the file, where the essential information
seems to be.

We have this difference even if we call regcomp.exe in the flat release
directory ("regcomp reginit.ini .") as opposed to calling makimg (from the
same build command line).

Anyone ever had similar problems? Any idea on how to avoid these problems?
In the meantime we have changed the registry settings a little bit, so that
we have a different reginit.ini as input. The first tries worked, but who
knows if the problem appears again.

We can provide our reginit.ini and even the whole flat release directory to
Microsoft for further investigation.

Regards,
Thomas Hensler

BTW: We use PB 4.2 with the QFEs installed (which once patched regcomp.exe
already).

Sue
Tue May 16 10:17:47 CDT 2006

Is it too much to hope that you can hook up a kernel debugger and figure out
why the device is not booting?

Try running the hive dump tool on
http://blogs.msdn.com/ce_base/archive/2006/01/30/Dumping_Registry_Hives_and_CEDB_Database_Volumes.aspx
to determine what's different between the hives that are in working and
nonworking images.

Good luck,

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

Thomas
Thu May 18 00:49:05 CDT 2006

As soon as I include kernel debugger in the image the problem does not occur
of course. I can only see it with retail release images, where I cannot
debug and only see on the debug console that the system does not load the
filesystem drivers.

But I will try the dump tool.

Thanks,
Thomas

"Sue Loh [MS]" <sloh@online.microsoft.com> wrote in message
news:%23neCkvPeGHA.4276@TK2MSFTNGP03.phx.gbl...
> Is it too much to hope that you can hook up a kernel debugger and figure
> out why the device is not booting?
>
> Try running the hive dump tool on
> http://blogs.msdn.com/ce_base/archive/2006/01/30/Dumping_Registry_Hives_and_CEDB_Database_Volumes.aspx
> to determine what's different between the hives that are in working and
> nonworking images.
>
> Good luck,
>
> Sue
> sloh@microsoft.com (remove "online" from reply-to address)
> http://blogs.msdn.com/ce_base/
> _____________________________________________________________
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> _____________________________________________________________
>
>

Thomas
Thu May 18 01:05:58 CDT 2006

I've tried the dump tool and compared 2 boot.hv. There are a lot of
differences in the "addresses" and "binary data" in the beginning of the
file starting with fsmemblk[0]. The registry keys in the back of the output
are the same for both files. What does that mean? Can this be the reason for
our problems?

The differenes are e.g. as follows:

boot.hv:
...
fsmemblk[0]: startptr = 0xFDE0D165
length = 0xBDD0A851
extension = 0x63727B2B
fsmemblk[1]: startptr = 0xFF2D9153
length = 0x00000000
extension = 0x00008000
pFSList = 0x006F0070
pKList = 0x00740073
database/registry data:
guid = 0xFDE0D165 0xBDD0A851 0x63727B2B 0xFF2D9153
...
pwhash = 0x00720070 0x0063006F 0x0064005C 0x006F0063
...
0: START 0x00320034 0x005C0030 0x00550050
1: RESTORE 0x00B7600C 0x0000007A 0x00000002
2: RESTORE 0x00B751F4 0x01EC0000 0x00000004
3: RESTORE 0x00B779A8 0x00000029 0x00000004
4: RESTORE 0x00B779AC 0x005C006E 0x00000004
5: RESTORE 0x00B77998 0x00000000 0x00000004
6: 0x00660063 0x0072002E 0x00670065 0x00440020
...


boot2.hv:
...
fsmemblk[0]: startptr = 0xF5A9E564
length = 0xA993A4FE
extension = 0xA75C9E7E
fsmemblk[1]: startptr = 0x314B2BA4
length = 0x00000000
extension = 0x00008000
pFSList = 0x006F0063
pKList = 0x006D006D
database/registry data:
guid = 0xF5A9E564 0xA993A4FE 0xA75C9E7E 0x314B2BA4
...
pwhash = 0x006E006F 0x006F005C 0x006B0061 0x0042005C
0: START 0x00450043 0x00320034 0x005C0030
1: RESTORE 0x00B7600C 0x0000007A 0x00000002
2: RESTORE 0x00B751F4 0x01EC0000 0x00000004
3: RESTORE 0x00B779A8 0x00000029 0x00000004
4: RESTORE 0x00B779AC 0x00410050 0x00000004
5: RESTORE 0x00B77998 0x00000000 0x00000004
6: 0x0044003B 0x005C003A 0x00490057 0x0043004E
...

There are lot of differences in the binary dumps until the following output:

Out of range now. : 0x00348000

-------------------------------------------------------------------------------
DATABASE DUMP
-------------------------------------------------------------------------------

Then the files are the same.
I
n the meantime we changed our reginit.ini for the boot hive a little bit
(added a dummy registry key within the boot section). Now the problem did
not occur for 3 automatic overnight builds anymore.

Regards,
Thomas

"Thomas Hensler" <thomas.hensler@newsgroups.nospam> wrote in message
news:O0OqK7jeGHA.2416@TK2MSFTNGP03.phx.gbl...
> As soon as I include kernel debugger in the image the problem does not
> occur of course. I can only see it with retail release images, where I
> cannot debug and only see on the debug console that the system does not
> load the filesystem drivers.
>
> But I will try the dump tool.
>
> Thanks,
> Thomas
>
> "Sue Loh [MS]" <sloh@online.microsoft.com> wrote in message
> news:%23neCkvPeGHA.4276@TK2MSFTNGP03.phx.gbl...
>> Is it too much to hope that you can hook up a kernel debugger and figure
>> out why the device is not booting?
>>
>> Try running the hive dump tool on
>> http://blogs.msdn.com/ce_base/archive/2006/01/30/Dumping_Registry_Hives_and_CEDB_Database_Volumes.aspx
>> to determine what's different between the hives that are in working and
>> nonworking images.
>>
>> Good luck,
>>
>> Sue
>> sloh@microsoft.com (remove "online" from reply-to address)
>> http://blogs.msdn.com/ce_base/
>> _____________________________________________________________
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> _____________________________________________________________
>>
>>
>
>