DEBUGCHK while entering a critical section

I'm getting a DEBUGCHK firing at line 4861 of
private\winceos\coreos\nk\kernel\schedule.c. This is inside function
SC_TakeCritSec and the line concerned reads:

DEBUGCHK(!pCurThread->lpProxy)

I am using PB 4.2.

Any ideas on what could be causing this ? The DEBUGCHK appears on the serial
output so I can't resume execution. If I run the system in release mode it
seems to be OK, i.e no crashes or instabilities although I have not run a
full test suite on it.

Steve
Wed Nov 12 08:05:49 CST 2003

In the debug build what do you end up with for a call stack? That debug
check indicates the use of an uninitialized critical section.

--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com

Dan
Wed Nov 12 10:04:41 CST 2003

I can't get a stack trace because the debugger hangs.

The problem I have is that I'm trying to synchronize access to PCI IO space
using a critical section. Basically I can see 2 clients of my code: KITL and
the OAL via IOCTL_HAL_DDK_CALL.

KITL seems happy enough grabbing and releasing the critical section on its
own. However when PCIBus.dll loads and makes an IOCTL_HAL_DDK_CALL into the
kernel is when the DEBUGCHK and subsequent hang occurs. I noticed that
placing DEBUGMSGs in oemioctl.c can sometimes cause the problem to go away,
suggesting a timing issue.

I'm pretty sure the critical section is initialised as I set a global in
IOCTL_HAL_POSTINIT right after calling InitializeCriticalSection. I won't
attempt to enter or leave it without checking this global. Plus like I say I
know it's been entered and left a few times before by KITL. It's only when a
second thread comes into play.

bmhsieh
Fri Feb 06 17:40:41 CST 2004

If the code is being used by KITL, you cannot call ECS/LCS. The reason
being that DEBUGMSG can be called from anywhere in the system and there are
certain places in the system where ECS/LCS cannot be used (KCall, the CS
code itself, for example) and can result in undefined behavior.

The particular debugchk below means that the thread has just got the CS,
but it it still blocked on another CS, which I can only guess that CS code
is being re-entered.

-- Bor-Ming


This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2004 Microsoft Corporation. All rights
reserved.

--------------------
| From: "Dan" <nospam@nowhere.com>
| Newsgroups: microsoft.public.windowsce.platbuilder
| Subject: DEBUGCHK while entering a critical section
| Date: Wed, 12 Nov 2003 11:01:00 -0000
| Organization: CanPixa
| Lines: 14
| Message-ID: <bot46q$nl2$1@kermit.esat.net>
| NNTP-Posting-Host: 193.120.60.199
| X-Trace: kermit.esat.net 1068635162 24226 193.120.60.199 (12 Nov 2003
11:06:02 GMT)
| X-Complaints-To: abuse@esat.net
| NNTP-Posting-Date: Wed, 12 Nov 2003 11:06:02 +0000 (UTC)
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-onlin
e.de!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.esat.net!news.esat.net!no
t-for-mail
| Xref: cpmsftngxa06.phx.gbl microsoft.public.windowsce.platbuilder:41988
| X-Tomcat-NG: microsoft.public.windowsce.platbuilder
|
| I'm getting a DEBUGCHK firing at line 4861 of
| private\winceos\coreos\nk\kernel\schedule.c. This is inside function
| SC_TakeCritSec and the line concerned reads:
|
| DEBUGCHK(!pCurThread->lpProxy)
|
| I am using PB 4.2.
|
| Any ideas on what could be causing this ? The DEBUGCHK appears on the
serial
| output so I can't resume execution. If I run the system in release mode it
| seems to be OK, i.e no crashes or instabilities although I have not run a
| full test suite on it.
|
|
|