Friday, 25 September 2009

Windows Embedded CE: “We call it a Klassiker” part V:

Hi Folks,

when bringing up a Windows Embedded CE device, you might have come across the following “Faulted in KCall” Error:

Faulted in KCall, pCurThread->dwStartAddr = 40263d10, PageFreeCount = 00014937!!
Original Context when thread faulted:
Exception (3): Thread-Id=03d4000a(pth=8994bb4c), Proc-Id=00400002(pprc=8239bc80) 'NK.EXE', VM-active=017b0002(pprc=9e62861c) 'udevice.exe'
EIP=80260911 Flags=00003246 EA=00000000
Eax=00000000 Ebx=82359800 Ecx=00000000 Edx=d24ff8d0
Esi=d24ffbfc Edi=80273ed0 Ebp=d24ff864 Esp=d24ff860
CS=0019 DS=0040 ES=0040 SS=0021 FS=0060 GS=0000
Context when faulted in KCall:
Exception (3): Thread-Id=03d4000a(pth=8994bb4c), Proc-Id=00400002(pprc=8239bc80) 'NK.EXE', VM-active=017b0002(pprc=9e62861c) 'udevice.exe'
EIP=c0d912c0 Flags=00003286 EA=00000000
Eax=00000000 Ebx=82359800 Ecx=898036f0 Edx=c0d912c0
Esi=80228e10 Edi=82359720 Ebp=823596f0 Esp=823596d8
CS=0008 DS=89920040 ES=80270040 SS=0010 FS=82350060 GS=0000

This normally indicates some sort of memory problem which could have multiple causes for instance accessing unmapped memory. But figuring out the exact cause in any particular case is the second step.

Let’s focus on the first step, namely figuring out in which module the error occurred.

It doesn’t really help knowing the problem occurred in a user-mode driver (udevice.exe), as we normally have multiple user-mode drivers running in our system. Same of course goes if the problem would have occurred in a kernel-mode driver or a service which of course would run in nk.exe or servicesd.exe respectively.

Let’s have a look at the next clue then: pCurThread->dwStartAddr (here: 40263d10). Although you will not encounter a single hit (other than the error message) when searching your debug output, pCurThread->dwStartAddr is the solution to our problem. But how can that be?

All you have left to do in order to find the perpetrator is to find the module with the appropriate address range in you debug output. In order to do so, just look for the process context (in this example 9e62861c). Eventually you will arrive at the module that has the correct address range where pCurThread->dwStartAddr resides within:

>>> Loading Module 'softkb.dll' (0x894C7364) at address 0x40260000-0x4026A000 in Process 'NK.EXE' (0x8239BC80)
>>> Loading Module 'softkb.dll' (0x894C7364) at address 0x40260000-0x4026A000 in Process 'udevice.exe' (0x9E62861C)

As you can see in this case the exception was raised in the module softkb.dll.

Now you can hunt for the cause of this problem in the correct module. Sometimes you have to be a real detective when tracing bugs.

Have fun!

1 comment:

Shai said...

This is good to know, I hope that next time I encounter such a crash I will be able to spot the criminal.