none
Prefetch abort in explorer.exe for WinCE 6.0 RRS feed

  • Question

  • Hi All,

       We are ported WinCE 6.0 R3 on our target board and tested it for whole night.

       In the morning we have seen the following debug message on hyper terminal:

    Exception 'Prefetch Abort' (3): Thread-Id=032a0002(pth=820a0a28), Proc-Id=00400002(pprc=81299308) 'NK.EXE', VM-active=033e0002(pprc=820a6a90) 'explorer.exe'

    PC=00000001(???+0x00000001) RA=00000001(???+0x00000001) SP=d0a8fca8, BVA=00000000

       After this error our target board is working fine except the touch screen functionality.

    Wednesday, September 15, 2010 10:02 AM

All replies

  • Prefetch abort means a problem executing code, as opposed to accessing data.  This can happen with bad function pointers (or corrupted RAM).  Run this with a debug image and see if you get any more information.  You can try to match up the thread id in the abort message with a thread ID in previous debug messages (PB prefixes debug messages with a timestamp, process id and thread ID) to get a clue as to which thread failed.
    Dean Ramsier eMVP BSQUARE Corporation
    Wednesday, September 15, 2010 1:05 PM
  • Thank you Dean.

    We have read Bruce Eitman article for prefetch abort and confirming that it's a Stack overrun, or corrupted stack based on PC and RA values.

    It's obvious that the touch screen functionality will be disabled because of explorer.exe is crashed.

    Our BSP won't run properly in debug mode which works fine in release mode only.

    Our concern is to know where the prefetch abort occurred...

    Wednesday, September 15, 2010 1:14 PM
  • So you should know that finding where it occurs is going to be difficult.  This line:

    PC=00000001(???+0x00000001) RA=00000001(???+0x00000001) SP=d0a8fca8, BVA=00000000

    says a lot.  The Program Counter (PC) and Return Address (RA) are both set to 1 which should not occur.  (I know that you know this, but I put it for others who may be reading along.)

    Do you have any software running on the board in your test?  Does that software call any shell APIs?


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

    Eurotech Inc.
    www.Eurotech.com
    Wednesday, September 15, 2010 1:31 PM
    Moderator
  • we forgot to inform while posting the problem, Yes our target board is running the application which calls different WinCE APIs, we don't know exactly which shell APIs are used.
    Wednesday, September 15, 2010 2:00 PM
  • No problem, but you probably want to watch what your application is doing.  I would suspect that it may call a shell API in with some bad parameters.
    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com
    Wednesday, September 15, 2010 2:26 PM
    Moderator
  • You need to fix your BSP so that it *will* run properly in DEBUG mode.  This will not be the last time you need to do kernel debugging.  You're needlessly handicapping yourself by just dismissing the need for DEBUG...

    Paul T.

    Wednesday, September 15, 2010 2:49 PM
  • Thank you paul. The BSP we got from a vendor who has the problem in running in debug mode.

    Any how once again we will try in debug mode.

    Thursday, September 16, 2010 2:15 PM
  • Any chance you can change vendors?  If not, *demand* the source for the BSP and get DEBUG mode fixed yourself. What you have there is a car with only three wheels (and a bad valve in the engine), not a commercial product that you should be paying money for.

    Paul T.

    Thursday, September 16, 2010 3:25 PM