NDIS EnterCriticalSection DEBUGCHK in CE 4.2 - HELP!

Hey guys. I've been dealing with this problem for a while now, hoping that
it would somehow get fixed. Unfortunately, it's still a problem for me, and
it's getting more annoying and more troublesome as time goes on.

Here's my original post on the subject:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm
=3f030f26%241%40news.microsoft.com&rnum=8&prev=/groups%3Fq%3DMurawski%2Bgrou
p:microsoft.public.windowsce.platbuilder%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe
%3DUTF-8%26safe%3Doff%26scoring%3Dd%26selm%3D3f030f26%25241%2540news.microso
ft.com%26rnum%3D8

Here's a post from Steve Maillet where he lists it as bug #7 in his list of
known CE 4.xx bugs:
http://groups.google.com/groups?q=Maillet+group:microsoft.public.windowsce.p
latbuilder&start=90&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&scoring=d&selm=eB72
YpWQDHA.2316%40TK2MSFTNGP12.phx.gbl&rnum=97

Basically, what's happening is this. When I have a PCMCIA card in my device
at cold boot, NDIS occasionally hits a DEBUGCHK in the kernel when trying to
enter a critical section that has never been initialized. Since I don't
have access to NDIS code, I can't really tell what's going on, but the call
stack looks like this:
<stack dump>
COREDLL!EnterCriticalSection(CRITICAL_SECTION * 0x01fd98c0
PcmciaMemListLock) line 90 + 76 bytes
NDIS!mapAllWindowsForHSock(_CARD_SOCKET_HANDLE {...}, int 0x00000001, int
(_NDIS_PCMCIA_WINDOW *)* 0x03d6a954 npwMapToDevice(_NDIS_PCMCIA_WINDOW *))
line 478
NDIS!PcmciaCallBack(unsigned int 0x00000040, _CARD_SOCKET_HANDLE {...},
_CARD_EVENT_PARMS * 0x080afdf0) line 620
PCMCIA!CallClient(unsigned int (unsigned int, _CARD_SOCKET_HANDLE,
_CARD_EVENT_PARMS *)* 0x00000000, unsigned int 0x01fa8aa0,
_CARD_SOCKET_HANDLE {...}, _CARD_EVENT_PARMS * 0x00000000, _CLIENT_DRIVER *
0x2dfa5fda) line 600 + 24 bytes
PCMCIA!CallbackThread(unsigned int 0x00000000) line 910 + 56 bytes
COREDLL!ThreadBaseFunc(void * 0x03a6aecc CallbackThread(unsigned int),
unsigned long 0x00000000) line 418 + 16 bytes
</stack dump>

Unfortunately, this problem is probably much more serious for me than it is
for most CE platforms. Our device ALWAYS has a PCMCIA card in it, and it
goes through a cold boot quite often. I seem to hit this problem almost
every time my platform boots. To make things worse, about 50% of the time
when it happens, and I try to run past the DEBUGCHK, I hit another critical
access violation in NDIS. (I guess there's a critical section somewhere for
a reason!)

Does anyone have any new information on this problem? Any suggestions on
what I should do? I've been dreading trying to call Microsoft about it
directly. I haven't had much luck trying to describe problems of anything
beyond trivial technical complexity with the first one or two levels of
technical support. Should I suck it up and put in a call on this one?

Thanks in advance guys.

Mark Murawski
Vocollect, Inc.

Mark
Tue Jul 29 09:13:28 CDT 2003

Since it just happened to me again, I figure I should include the
"follow-up" exception. Here's what the call stack looks like when NDIS
blows up after the initial DEBUGCHK:
<BOOM>
NDIS!ProcessPcmciaDeviceNotificationMessages(void * 0xadf7a922) line 843 +
4 bytes
NDIS!MonitorPcmciaDeviceNotificationsThread(void * 0x00000000) line 872
COREDLL!ThreadBaseFunc(void * 0x03d6b658
MonitorPcmciaDeviceNotificationsThread(void *), unsigned long 0x00000000)
line 418 + 16 bytes
</BOOM>

It's really hard to tell what's going on, but it looks like NDIS really
isn't ready to handle PCMCIA stuff yet when this happens. Is there some
kind of device.exe startup sequence that I can control? Maybe put a delay
between NDIS and PCMCIA somehow? I think I've got another problem related
to this same issue, too.

Mark Murawski
Vocollect, Inc.

Jeff
Wed Jul 30 15:26:24 CDT 2003

This sounds like the known race condition problem in CE 4.2 NDIS PCMCIA
initialization. You should contact PSS to request a QFE if you have not
already done so. I am somewhat surprised myself that a bug in Steve's list
has not already been QFEd.

--
Jeff Kelley
Windows CE Networking

This posting is provided "AS IS" with no warranties, and confers no rights.

"Mark Murawski" <mmurawski@NO.vocollect.SPAM.com> wrote in message
news:eZOg3gdVDHA.2652@tk2msftngp13.phx.gbl...
> Hey guys. I've been dealing with this problem for a while now, hoping
that
> it would somehow get fixed. Unfortunately, it's still a problem for me,
and
> it's getting more annoying and more troublesome as time goes on.
>
> Here's my original post on the subject:
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm
>
=3f030f26%241%40news.microsoft.com&rnum=8&prev=/groups%3Fq%3DMurawski%2Bgrou
>
p:microsoft.public.windowsce.platbuilder%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe
>
%3DUTF-8%26safe%3Doff%26scoring%3Dd%26selm%3D3f030f26%25241%2540news.microso
> ft.com%26rnum%3D8
>
> Here's a post from Steve Maillet where he lists it as bug #7 in his list
of
> known CE 4.xx bugs:
>
http://groups.google.com/groups?q=Maillet+group:microsoft.public.windowsce.p
>
latbuilder&start=90&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&scoring=d&selm=eB72
> YpWQDHA.2316%40TK2MSFTNGP12.phx.gbl&rnum=97
>
> Basically, what's happening is this. When I have a PCMCIA card in my
device
> at cold boot, NDIS occasionally hits a DEBUGCHK in the kernel when trying
to
> enter a critical section that has never been initialized. Since I don't
> have access to NDIS code, I can't really tell what's going on, but the
call
> stack looks like this:
> <stack dump>
> COREDLL!EnterCriticalSection(CRITICAL_SECTION * 0x01fd98c0
> PcmciaMemListLock) line 90 + 76 bytes
> NDIS!mapAllWindowsForHSock(_CARD_SOCKET_HANDLE {...}, int 0x00000001, int
> (_NDIS_PCMCIA_WINDOW *)* 0x03d6a954 npwMapToDevice(_NDIS_PCMCIA_WINDOW *))
> line 478
> NDIS!PcmciaCallBack(unsigned int 0x00000040, _CARD_SOCKET_HANDLE {...},
> _CARD_EVENT_PARMS * 0x080afdf0) line 620
> PCMCIA!CallClient(unsigned int (unsigned int, _CARD_SOCKET_HANDLE,
> _CARD_EVENT_PARMS *)* 0x00000000, unsigned int 0x01fa8aa0,
> _CARD_SOCKET_HANDLE {...}, _CARD_EVENT_PARMS * 0x00000000, _CLIENT_DRIVER
*
> 0x2dfa5fda) line 600 + 24 bytes
> PCMCIA!CallbackThread(unsigned int 0x00000000) line 910 + 56 bytes
> COREDLL!ThreadBaseFunc(void * 0x03a6aecc CallbackThread(unsigned int),
> unsigned long 0x00000000) line 418 + 16 bytes
> </stack dump>
>
> Unfortunately, this problem is probably much more serious for me than it
is
> for most CE platforms. Our device ALWAYS has a PCMCIA card in it, and it
> goes through a cold boot quite often. I seem to hit this problem almost
> every time my platform boots. To make things worse, about 50% of the time
> when it happens, and I try to run past the DEBUGCHK, I hit another
critical
> access violation in NDIS. (I guess there's a critical section somewhere
for
> a reason!)
>
> Does anyone have any new information on this problem? Any suggestions on
> what I should do? I've been dreading trying to call Microsoft about it
> directly. I haven't had much luck trying to describe problems of anything
> beyond trivial technical complexity with the first one or two levels of
> technical support. Should I suck it up and put in a call on this one?
>
> Thanks in advance guys.
>
> Mark Murawski
> Vocollect, Inc.
>
>