In the process of trying to get a driver (object form only, no source)
running on my ARMV4-based platform, I get a "First Chance Exception
0xC000001C, Invalid System Service" window pop-up. When I click "ok"
on the pop-up, the debugger stops at a DEBUGCHK(0) on line 1167 of the
objdisp.c file, in the ObjectCall function. The stack at this point
is full of PreFetchAbort entries. When I posted about this a month
ago, Andrew Pearson said I might have a cache clearing problem, but
our platform is simply using the pbuilder-supplied version (presumably
in public\common\oak\csp\arm\sa11x0\cfw.c), as opposed to providing
our own. The rest of our application and drivers and code which run
on this same platform never run into this error, so I'm hesitant to
think it is a cacheFlush issue. Any suggestions on what to try to
figure this out?

Not quite sure how to explain the PreFetchAborts in the stack, but
another possibility is that the driver is trying to call a method in
coredll.dll which isn't there. I have looked in the coredll.def to
try to determine if the methods the driver dll needs (determined with
the use of dumpbin) are there, but am having trouble sorting through
all the conditionals there to determine if each item is actually in
the final dll. Is there some easy way to look at the coredll.dll in
the release directory to determine exactly which methods are really
included there, since a dumpbin /exports on it seems to indicate that
everything is included, which I think is incorrect?

Arthur McNair

RE: Debugging PreFetchAbort and First Chance Exception 0xC000001C by ghogdal

ghogdal
Wed Oct 08 16:10:02 CDT 2003

The reason for which the callstack is messed up is that the exception is
raised in the middle of a PSL call and calling conventions are not
respected in PrefetchAbort().
This can happen for example when trying to call the GWES before it is
loaded.
To diagnose the problem, you should find the offending calling function at
pth->pcstkTop->retAddr (in the context of the exception).

--
Greg Hogdal
Microsoft Corporation
Development Lead - Windows CE Core Diagnostic Tools

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



--------------------
| From: Arthur McNair <amcnair@vocollect.com>
| Subject: Debugging PreFetchAbort and First Chance Exception 0xC000001C
| Date: Tue, 23 Sep 2003 10:20:22 -0400
| Message-ID: <gjk0nvk2e5aobl998g8i1qk5urkbaner2m@4ax.com>
| X-Newsreader: Forte Agent 1.93/32.576 English (American)
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| Newsgroups: microsoft.public.windowsce.platbuilder
| NNTP-Posting-Host: 209.166.178.1
| Lines: 1
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.windowsce.platbuilder:39595
| X-Tomcat-NG: microsoft.public.windowsce.platbuilder
|
| In the process of trying to get a driver (object form only, no source)
| running on my ARMV4-based platform, I get a "First Chance Exception
| 0xC000001C, Invalid System Service" window pop-up. When I click "ok"
| on the pop-up, the debugger stops at a DEBUGCHK(0) on line 1167 of the
| objdisp.c file, in the ObjectCall function. The stack at this point
| is full of PreFetchAbort entries. When I posted about this a month
| ago, Andrew Pearson said I might have a cache clearing problem, but
| our platform is simply using the pbuilder-supplied version (presumably
| in public\common\oak\csp\arm\sa11x0\cfw.c), as opposed to providing
| our own. The rest of our application and drivers and code which run
| on this same platform never run into this error, so I'm hesitant to
| think it is a cacheFlush issue. Any suggestions on what to try to
| figure this out?
|
| Not quite sure how to explain the PreFetchAborts in the stack, but
| another possibility is that the driver is trying to call a method in
| coredll.dll which isn't there. I have looked in the coredll.def to
| try to determine if the methods the driver dll needs (determined with
| the use of dumpbin) are there, but am having trouble sorting through
| all the conditionals there to determine if each item is actually in
| the final dll. Is there some easy way to look at the coredll.dll in
| the release directory to determine exactly which methods are really
| included there, since a dumpbin /exports on it seems to indicate that
| everything is included, which I think is incorrect?
|
| Arthur McNair
|
|