Camera Snap on start app.

SDK docs do say for this panic that: "This panic is raised when a timer event is requested from an asynchronous timer service, an RTimer, and a timer event is already outstanding. It is caused by calling either the At(), After() or Lock() member functions after a previous call to any of these functions, but before the timer event requested by those functions has completed. "

So do see that you never activate it twice, or simply cancel previous request when making new one. i.e. in your CamExTimer implementation, inside the At/After/Inactivity, add [B]Cancel();[/B] line in the beginning of the function.

But it has a cancel function.
This is After Function.
[CODE]
void CamExTimer::After(TTimeIntervalMicroSeconds32 aInterval)
{
Cancel();
iInterval = aInterval;
iTimer.After(iStatus,aInterval);
SetActive();
}
[/CODE]

Excuse me. KERN-EXEC 15 it gives me when I'm using Inactive function.
[CODE]
void CamExTimer::Inactivity(TTimeIntervalSeconds aSeconds)
{
Cancel();
iTimer.Inactivity(iStatus,aSeconds);
SetActive();
}
[/CODE]

When using After() it gives me KERN-EXEC 3

Cancel() calls DoCancel(), is that implemented already?

This is DoCancel :
[CODE]
void CamExTimer::DoCancel()
{
iTimer.Cancel();
}
[/CODE]

Can you paste the complete code as at what instances you are calling Inactivity() & After(). Might be an issue of two async requests at same time or something like that.

Yes, this is the whole project [url]ftp://fukatoki.dyndns.org/S60_Camera_Example.rar[/url]

I would suggest now finding the last line executed. The panic KERN-EXEC 3 indicates that you are using invalid pointer.

and forgetting to implement DoCancel() would not cause this panic. In that case the default empty implementation would be called.

Ah, it is your RunL. TimerExpired re-schedules the timer correctly, however after that RunL re-schedules it without any Cancel attempt.
(Side note: this passing void* and casting it to CamExTimer is not safe, in fact I do not see the need for passing the timer object around, for normal use cases it is owned by the called object anyway. And the complicated, extremist use cases are just not needed here)

Is there some way to track whole execution proccess, without emulator, but on real device or directly in Carbide?. I Want to now what steps passing
through my program?

You can use On Device Debugging.
This could be a starting point, but I don't know how up to date it is:
[url]http://www.developer.nokia.com/Community/Wiki/Carbide.c%2B%2B_On-device_Debugging_Quick_Start[/url]
For Symbian3 devices:
[url]http://www.developer.nokia.com/Community/Wiki/Debugging_Symbian_C%2B%2B_application_with_CODA_for_Symbian_OS[/url]

there were also some videos on youtube... feel free to search "symbian on device debugging" with your preferred search engine (or search facility here on the forum) :-)

regards
pg

ODD with Symbian has been always a bit tricky at best, anyway, I would suggest using file logging, its easy to use and often enough good for finding where the crashes are coming from.