ce6.0 NKwvsprintfW hard locks system

Hello,

On a CE6.0 ARM platform the following issue has come up:

If calling NKwvsprintfW() during OEMInit() the system hard locks. Once
OEMInit() returns, it is possible to subsequently call NKwvsprintfW()
without problems.

Any insights to why this is occurring, or reference to documentation
specifying that this is not legal would be appreciated.

chris

Dean
Mon Mar 24 06:49:39 PDT 2008

OEMInit is extremely early in the boot process; there is almost nothing
initialized yet except memory. You can't make any OS calls or any other
calls that require support from the OS. I suspect this call is making use
of a system service that is simply not yet available.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"chris" <none@nothanks.com> wrote in message
news:1aednb1Czbww33nanZ2dnUVZ_jGdnZ2d@comcast.com...
> Hello,
>
> On a CE6.0 ARM platform the following issue has come up:
>
> If calling NKwvsprintfW() during OEMInit() the system hard locks. Once
> OEMInit() returns, it is possible to subsequently call NKwvsprintfW()
> without problems.
>
> Any insights to why this is occurring, or reference to documentation
> specifying that this is not legal would be appreciated.
>
> chris

chris
Mon Mar 24 09:16:41 PDT 2008

Dean Ramsier wrote:
> OEMInit is extremely early in the boot process; there is almost nothing
> initialized yet except memory. You can't make any OS calls or any other
> calls that require support from the OS. I suspect this call is making use
> of a system service that is simply not yet available.

Yes, this was my assumption as well as that function is located in
coredll. However, do you have any reference documentation to back this
up? This function is used by OALLogSerial()
(PLATFORM/COMMON/SRC/COMMON/LOG/log.c), and OALLogSerial is used by
OALMSGS(). Which in turn is used by OALLogSetZones(), and
OALLogSetZones() is documented to be called from within OEMInit().

So, as you can see the only documented (indirect) use of NKwvsprintfW()
I can find seems to indicate that it is valid to use in OEMInit().

Any further thoughts?

chris


ps. irrelevant aside:

Besides, it would be architecturally poor design if the OAL is passed a
structure of function pointers in OEMInitGlobals that is invalid to use
until some undefined later point. I'd expect that as soon as that
exchange occurs, that at least by the next entry point into the OAL,
that the NKGlobal structure is valid to use. And if the case truly is
that it is invalid to use until some later point then the documentation
should be quite clear regarding this.

Bruce
Mon Mar 24 10:24:01 PDT 2008

You make a good argument that the function is okay to use. Could there be a
problem with how you are calling it?

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"chris" <none@nothanks.com> wrote in message
news:9u6dnb2FGaZ0TnranZ2dnUVZ_jSdnZ2d@comcast.com...
> Dean Ramsier wrote:
>> OEMInit is extremely early in the boot process; there is almost nothing
>> initialized yet except memory. You can't make any OS calls or any other
>> calls that require support from the OS. I suspect this call is making
>> use
>> of a system service that is simply not yet available.
>
> Yes, this was my assumption as well as that function is located in
> coredll. However, do you have any reference documentation to back this
> up? This function is used by OALLogSerial()
> (PLATFORM/COMMON/SRC/COMMON/LOG/log.c), and OALLogSerial is used by
> OALMSGS(). Which in turn is used by OALLogSetZones(), and
> OALLogSetZones() is documented to be called from within OEMInit().
>
> So, as you can see the only documented (indirect) use of NKwvsprintfW() I
> can find seems to indicate that it is valid to use in OEMInit().
>
> Any further thoughts?
>
> chris
>
>
> ps. irrelevant aside:
>
> Besides, it would be architecturally poor design if the OAL is passed a
> structure of function pointers in OEMInitGlobals that is invalid to use
> until some undefined later point. I'd expect that as soon as that
> exchange occurs, that at least by the next entry point into the OAL, that
> the NKGlobal structure is valid to use. And if the case truly is that it
> is invalid to use until some later point then the documentation should be
> quite clear regarding this.

chris
Mon Mar 24 15:29:34 PDT 2008

Bruce Eitman [eMVP] wrote:
> You make a good argument that the function is okay to use. Could there be a
> problem with how you are calling it?

Partly yes. :) As in: the original oal_log library does not use
"OALMSGS" but rather "OALMSG". Apparently I modified it to use
"OALMSGS" at some point. I also increased the output buffer size of
OALLogSerial() which caused problems with the stack as described below.

Please note that, calling OALMSG (vs OALMSGS) works as OALMSG is a
wrapper to NKDbgPrintfW() which contains internal checks to ensure the
necessary initialization has taken place before it directly calls
NKwvsprintfW().

Looking to see what "work around" is necessary when initialization has
*not* been completed; it is to declare the output buffer passed to
NKwvsprintfW() as static so as to avoid the stack. I tested this, and
as long as the buffer is static, then calling NKwvsprintfW() works just
fine from within OALLogSerial() when called from OEMInit(). The other
option is to use a very small (and worthless) output buffer and hope the
stack can hold it (which is the solution Microsoft chose for their
common code implementation of OALLogSerial)

So, ignoring my change to OALMSGS vs OALMSG and the buffer size, it
still remains that OALLogSerial() (as provided by Microsoft in the
common library code) can not be used *safely* until IOCTL_HAL_POSTINIT
is called. (Based on the fact that the kernel's internal work around is
itself disabled just before it calls into the OAL with IOCTL_HAL_POSTINIT)

Anyway, I still assert that the issue remains, just in a slightly
different use case.

Regardless, I've understood what the issue is, thanks for the responses.

chris

Dean
Tue Mar 25 05:57:15 PDT 2008

On a somewhat related note, it is useful to know that the kernel stack is
only 2K. So you must be careful about what you place there. This applies
to the OAL, not to other modules that are loaded into kernel space.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"chris" <none@nothanks.com> wrote in message
news:TZOdnSAUrbzTtnXanZ2dnUVZ_qOdnZ2d@comcast.com...
> Bruce Eitman [eMVP] wrote:
>> You make a good argument that the function is okay to use. Could there
>> be a
>> problem with how you are calling it?
>
> Partly yes. :) As in: the original oal_log library does not use "OALMSGS"
> but rather "OALMSG". Apparently I modified it to use "OALMSGS" at some
> point. I also increased the output buffer size of OALLogSerial() which
> caused problems with the stack as described below.
>
> Please note that, calling OALMSG (vs OALMSGS) works as OALMSG is a wrapper
> to NKDbgPrintfW() which contains internal checks to ensure the necessary
> initialization has taken place before it directly calls NKwvsprintfW().
>
> Looking to see what "work around" is necessary when initialization has
> *not* been completed; it is to declare the output buffer passed to
> NKwvsprintfW() as static so as to avoid the stack. I tested this, and as
> long as the buffer is static, then calling NKwvsprintfW() works just fine
> from within OALLogSerial() when called from OEMInit(). The other option
> is to use a very small (and worthless) output buffer and hope the stack
> can hold it (which is the solution Microsoft chose for their common code
> implementation of OALLogSerial)
>
> So, ignoring my change to OALMSGS vs OALMSG and the buffer size, it still
> remains that OALLogSerial() (as provided by Microsoft in the common
> library code) can not be used *safely* until IOCTL_HAL_POSTINIT is called.
> (Based on the fact that the kernel's internal work around is itself
> disabled just before it calls into the OAL with IOCTL_HAL_POSTINIT)
>
> Anyway, I still assert that the issue remains, just in a slightly
> different use case.
>
> Regardless, I've understood what the issue is, thanks for the responses.
>
> chris