Hi,
i'm working on a x86 system based on VIA CX700 chipset under Windows CE 
6.0, this system work correctly but sometime during startup doesn't 
arrive to the desktop remaining into the black screen.
I discovered that the problem is in system.hv file, being replaced with 
a backup copy, the problem disappears.
The file doesn't seems corrupt but probably it contain a 'wrong' key 
that prevents the proper boot.
I tried in vain to edit the two files to compare them, so I want to 
block calls to 'RegFlushKey' to create a sort of 'Registry Write Filter' 
and enable it through a flag.
At this point my problem is to find 'RegFlushKey' code to recompile it,
I've find a 'NKRegFlushKey' into 
C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\fscall.c but using 
additonal DEBUGMSG it seems that the code does not move from there.

Can someone may refer to the portion of code to change or any 
suggestions to prevent system block.

Thanks,
Massimo

That is unusual, could you have a problem with the disk that you are using? 
Seems like you are trying to mask a bigger problem.  Where in the boot 
process does it stop?

I suspect that even though you changed that file, you didn't actually build 
it.

-- 
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT Eurotech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

Eurotech Inc.
www.Eurotech.com

"Massimo" <massimo@fake.it> wrote in message 
news:hjmtnl$c2u$1@speranza.aioe.org...
> Hi,
> i'm working on a x86 system based on VIA CX700 chipset under Windows CE 
> 6.0, this system work correctly but sometime during startup doesn't arrive 
> to the desktop remaining into the black screen.
> I discovered that the problem is in system.hv file, being replaced with a 
> backup copy, the problem disappears.
> The file doesn't seems corrupt but probably it contain a 'wrong' key that 
> prevents the proper boot.
> I tried in vain to edit the two files to compare them, so I want to block 
> calls to 'RegFlushKey' to create a sort of 'Registry Write Filter' and 
> enable it through a flag.
> At this point my problem is to find 'RegFlushKey' code to recompile it,
> I've find a 'NKRegFlushKey' into 
> C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\fscall.c but using additonal 
> DEBUGMSG it seems that the code does not move from there.
>
> Can someone may refer to the portion of code to change or any suggestions 
> to prevent system block.
>
> Thanks,
> Massimo 

Hi Bruce,
I excludes the disk because replacing system.hv 'bad' with a 'good' one 
the system works, if we replace it again with the 'bad' the system 
return not working.

Unfortunately, my nk.bin is a release version with a few debug messages 
also do not have the network do not have the chance to do much more, 
this is the log:

-----------------------------------------------------------------------
Debug Serial Init

SysInit: GDTBase=81dc2000 IDTBase=81dce3a0 KData=81dc9800
Windows CE Kernel for i486 Built on May  9 2008 at 10:19:17
INFO:OALLogSetZones: dpCurSettings.ulZoneMask: 0xb
SECO Settings -> Keyboard PS/2 Enabled
[VIA BSP CEPC:x86] BSP version: 3.41 for WINCE6.0 Jan 30 2009 
11:56:57RTC - Status Reg B - 0x02
Disable VIA EHCI Legacy
MainMemoryEndAddress = 0x8c000000
VIA PowerSaver: Jan 30 2009, 11:56:57VIAPWM.LIB 4.22, Nov  3 2006, 11:35:48
Error Reporting Memory Reserved, dump size = 0004b000
Booting Windows CE version 6.00 for (x86)

Old or invalid version stamp in kernel structures - starting clean!
Configuring: Primary pages: 41418, Secondary pages: 0, Filesystem pages 
= 20709

Booting kernel with clean memory configuration:
Memory Sections:
[0] : start: 81dd6000, extension: 00015000, length: 0a1ca000
X86Init done, OEMAddressTable = 80225520, RAM mapped = 20000000.
OSAXST0: Platform Name = CEPC
Override Serial Driver: No COM port selected for serial KITL transport, 
no override necessary.
Kernel DLL 'msg711.dll' needs thread creation/deletion notification
Kernel DLL 'imaadpcm.dll' needs thread creation/deletion notification
Read IoBase value for serial IOBase = 0x03320
Read IoBase value for serial IOBase = 0x03300
Read IoBase value for serial IOBase = 0x03328
Read IoBase value for serial IOBase = 0x03308
Kernel DLL 'vialh.dll' needs thread creation/deletion notification
Read IoBase value for serial IOBase = 0x03338
Read IoBase value for serial IOBase = 0x03318
Read IoBase value for serial IOBase = 0x03310
Read IoBase value for serial IOBase = 0x03330
Read IoBase value for serial IOBase = 0x03220
!Kernel DLL 'pegassdn.dll' needs thread creation/deletion notification
[UAM HD Audio driver] Driver version: 1.2, May  7 2008, 10:17:36[UAM HD 
Audio driver] Registry version: 1.2
                   [VIAFET] version : 3.65, Dec 12 2006, 16:53:29
                                                                 Kernel 
DLL 'fetce6b.dll' needs thread creation/deletion notification
Kernel DLL 'usbtouch.dll' needs thread creation/deletion notification
SECDisable = 1
Kernel DLL 'k.ws2.dll' needs thread creation/deletion notification
DDI_VIA.DLL  Version 6.0.0.33.40905 , May 16 2008 , 12:20:45

Unhandled exception c0000005:
Terminating thread 87083b00
-----------------------------------------------------------------------

The problem probably is inside video driver registry key but i don't 
know how find it.

Massimo





Il 26/01/2010 15.58, Bruce Eitman [eMVP] ha scritto:

> That is unusual, could you have a problem with the disk that you are using?
> Seems like you are trying to mask a bigger problem.  Where in the boot
> process does it stop?
>
> I suspect that even though you changed that file, you didn't actually build
> it.
>

Hi,
Did you considder using RAM based registry ?
That way your OS will always boot "clean".
You might need to make some customisations if you use persistent data (like 
touch-calibration)

Kind regards,
Rob.
www.robtso.nl




"Massimo" wrote:

> Hi,
> i'm working on a x86 system based on VIA CX700 chipset under Windows CE 
> 6.0, this system work correctly but sometime during startup doesn't 
> arrive to the desktop remaining into the black screen.
> I discovered that the problem is in system.hv file, being replaced with 
> a backup copy, the problem disappears.
> The file doesn't seems corrupt but probably it contain a 'wrong' key 
> that prevents the proper boot.
> I tried in vain to edit the two files to compare them, so I want to 
> block calls to 'RegFlushKey' to create a sort of 'Registry Write Filter' 
> and enable it through a flag.
> At this point my problem is to find 'RegFlushKey' code to recompile it,
> I've find a 'NKRegFlushKey' into 
> C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\fscall.c but using 
> additonal DEBUGMSG it seems that the code does not move from there.
> 
> Can someone may refer to the portion of code to change or any 
> suggestions to prevent system block.
> 
> Thanks,
> Massimo
> .
> 

Hi Bob,
Unfortunately the registry requires a 'dynamic' customization also 
during the life of the system, so i must use hive regisry.

Massimo

Il 27/01/2010 12.04, Rob ha scritto:

> Hi,
> Did you considder using RAM based registry ?
> That way your OS will always boot "clean".
> You might need to make some customisations if you use persistent data (like
> touch-calibration)
>
> Kind regards,
> Rob.
> www.robtso.nl
>
>
>
>
> "Massimo" wrote:
>
>> Hi,
>> i'm working on a x86 system based on VIA CX700 chipset under Windows CE
>> 6.0, this system work correctly but sometime during startup doesn't
>> arrive to the desktop remaining into the black screen.
>> I discovered that the problem is in system.hv file, being replaced with
>> a backup copy, the problem disappears.
>> The file doesn't seems corrupt but probably it contain a 'wrong' key
>> that prevents the proper boot.
>> I tried in vain to edit the two files to compare them, so I want to
>> block calls to 'RegFlushKey' to create a sort of 'Registry Write Filter'
>> and enable it through a flag.
>> At this point my problem is to find 'RegFlushKey' code to recompile it,
>> I've find a 'NKRegFlushKey' into
>> C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\fscall.c but using
>> additonal DEBUGMSG it seems that the code does not move from there.
>>
>> Can someone may refer to the portion of code to change or any
>> suggestions to prevent system block.
>>
>> Thanks,
>> Massimo
>> .
>>

No you don't. You can persist a RAM based registry as well, and
protecting that from RegFlushKey is easier that with the hive based
registry because you have full control over the flushing-to-disk code.

See http://msdn.microsoft.com/en-us/library/aa910517.aspx

Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

 GuruCE
 Microsoft Embedded Partner
 http://GuruCE.com
 Consultancy, training and development services.

Massimo wrote:
> Hi Bob,
> Unfortunately the registry requires a 'dynamic' customization also
> during the life of the system, so i must use hive regisry.
> 
> Massimo
> 
> Il 27/01/2010 12.04, Rob ha scritto:
> 
>> Hi,
>> Did you considder using RAM based registry ?
>> That way your OS will always boot "clean".
>> You might need to make some customisations if you use persistent data
>> (like
>> touch-calibration)
>>
>> Kind regards,
>> Rob.
>> www.robtso.nl
>>
>>
>>
>>
>> "Massimo" wrote:
>>
>>> Hi,
>>> i'm working on a x86 system based on VIA CX700 chipset under Windows CE
>>> 6.0, this system work correctly but sometime during startup doesn't
>>> arrive to the desktop remaining into the black screen.
>>> I discovered that the problem is in system.hv file, being replaced with
>>> a backup copy, the problem disappears.
>>> The file doesn't seems corrupt but probably it contain a 'wrong' key
>>> that prevents the proper boot.
>>> I tried in vain to edit the two files to compare them, so I want to
>>> block calls to 'RegFlushKey' to create a sort of 'Registry Write Filter'
>>> and enable it through a flag.
>>> At this point my problem is to find 'RegFlushKey' code to recompile it,
>>> I've find a 'NKRegFlushKey' into
>>> C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\fscall.c but using
>>> additonal DEBUGMSG it seems that the code does not move from there.
>>>
>>> Can someone may refer to the portion of code to change or any
>>> suggestions to prevent system block.
>>>
>>> Thanks,
>>> Massimo
>>> .
>>>
> 

>i'm working on a x86 system based on VIA CX700 chipset under Windows CE
>6.0, this system work correctly but sometime during startup doesn't
>arrive to the desktop remaining into the black screen.

Hi Massimo,

I had the same problems with my ICOP eBox4300 based on the VIA BSP.

After removing the "VIA WCE X86 System Control Interrupt (SCI) Handler for Persistent
Registry & Power Management" out of "%_TARGETPLATROOT%\SRC\X86\COMMON\OTHER\HALSCI.c"
this file has some bugs (non initiated variables).

Change this lines

WORD   dwGPIOSTS,dwSusTo;
DWORD  AutoConfig=1, IrqSetting, dwSLPBTN;

to

WORD   dwGPIOSTS = 0, dwSusTo = 0;
DWORD  AutoConfig = 1, IrqSetting = 9, dwSLPBTN = 1;