Hello everybody,

First of all, sorry for the long post but we'd like to describe the
problem in as much detail as possible, so it's perhaps easier to help
Also, if this post is not particularly suitable for this group,
please point me to the most appropiate one. Thanks.

We have developed an application in .NET Compact Framework 2.0 which we
are running currently under Windows CE 4.2 (the device is a Qtek 2020,
which says it runs Windows Mobile 2003) . The application has to manage
a number of forms, some of which can get a bit crowded sometimes,
communications with a server (done via Socket objects) and a couple of
databases (SQL Server CE).

The problem we are facing is that sometimes (we haven't yet been able
to exactly determine when) the application quits unexpectedly leaving
no trace of the possible error whatsoever. No exceptions that can be
caught in a managed try-catch block, no system window informing that an
exception has occurred... nothing. It just shuts down silently.

If we attach to our process in the smart device via Visual Studio 2005
(debugging native code), at some point a native "Illegal instruction"
exception with code 0xC000001D is thrown. This seems to happen more or
less arbitrarily, and doesn't necessarily happen all the times the
application is run. This exception is not caught by any try-catch block
that we have in our managed code. We have implemented a handler for the
AppDomain.CurrentDomain.UnhandledException event, but it isn't able to
stop this "Illegal instruction" exception. We have also tried to use
the Remote Process Viewer that comes with Visual Studio 2005, but it
has been of little help so far.

We have tested the application under several conditions, using up all
the available memory (32 MB) or using as little memory as possible,
running it for long periods of time, using GPRS, Bluetooth and
ActiveSync as the transport mechanisms for the communications with the
server... but we haven't been able to find any correlation between any
set of certain testing conditions and the crashes. Sometimes it exits
just after starting, sometimes after a long run, sometimes it works
fine...

We have enabled the interop and loader logs that the compact framework
provides us with, but haven't been able to find much interesting in
them. We do get usually an unresolved error of the type "Missing type.
Class xxxxxx" in the loader.log file, but not always (in many cases we
get this message but the app runs fine, in other cases we might not get
the error but the app would quit unexpectedly anyway).

At this point we are somewhat stuck with this problem. We have found
that another application, similar to this one but perhaps a bit less
complex, ran in a much smoother way under Windows CE 3.0 (Pocket PC
2002). We have been able to test our current app with CE 3.0 as well,
but not as deeply as we would have liked, and we have found it is also
more stable. We tried to follow this path and found this KB article at
microsoft:

http://support.microsoft.com/kb/835932

This article points out that under Windows CE 4.2 the same symptoms we
are having can occur with C++ dlls. Is it possible that this is our
problem? Our code is entirely managed, so I'm not completely sure about
how the problem described in that article could apply to us.

Last, the application was previously done in .NET CF 1.0 SP3, but we
moved to 2.0 as soon as we could since it did solve some other issues
we had. However, we were hoping that this problem of the vanishing
application would also disappear, but it didn't.

Again, sorry for the long post and thanks a lot for any help, ideas,
pointers to additional info, etc. that you can provide with.

Marcelo
msoria --nospam-- at movelis.com

Hi,

I recently found a post in this newsgroup pointing out, that WinCE4.2
is not a currently supported platform for the CF2.0.

See

http://groups.google.de/group/micros...c8e15789b2f28e

for more information.

Florian

CE 4.2 isn't but Windows Mobile 2003, which he is using, is supported.


Alberto Silva
MS Mobile Devices MVP
http://msmvps.com/AlbertoSilva

Ugh, every programmer's nightmare.

This might be a stupid question, but have you tried going back to
earlier versions of your source to see if those builds exhibit the same
problem. (Hopefully you're using a source database so you can do this
easily...)

-Dan

vachesacree (AT) yahoo (DOT) com wrote:

I've sent this thread to the internal debugger folks. Will post back
here if they come up with any suggestions

--
Sriram Krishnan
http://blogs.msdn.com/sriram
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi there,

Regarding Dan's suggestion: we did have the same issues in earlier
versions of our source. Actually, we've been able to more or less
reduce the frequency of the "vanishing" episodes as we've moved on with
our versions. But all we've done is tidy up the code a bit, remove
conflicting networking issues, etc. and as a side-effect we've achieved
a bit more stability. However, the real problem is still hiding
somewhere. But thanks a lot for your suggestion; there are no stupid
questions, only stupid answers...

To Sriram: thank you very much for your help. Like I've said, we're
still stuck with this, so any kind of suggestion, recommendation, etc.
is more than welcome

We've been able to track another exception that is being thrown and not
dealt with by the .NET CF try-catch blocks. It's an "access violation"
exception, code 0xC0000005. We are still unable to determine where it
happens. Sometimes we've seen that this exception or the "illegal
instruction" 0xC000001D was being thrown in "tshres.dll"... Also, using
the remote process viewer we've gathered that in some cases, when our
application goes away, our application owns a window called
"ms_sqlce_se_notify_wndproc" which is not visible at all (however, the
remote process viewer insists that this window is there and attached to
our application...).

Thank you all for your help.

Best regards,
Marcelo
msoria nospam --at-- movelis dotcom

Dan McCarty ha escrito:

vachesacree (AT) yahoo (DOT) com wrote:


One of the suggestions I got after running your post past internal folks
is to turn on JIT debugging (instructions at
http://blogs.msdn.com/srini/archive/...19/482597.aspx ) and see
whether you can get more info out of the crash. If that doesn't work for
you, see whether you can send me some code that repros the problem (or
repros the problem frequently)

Send it to sriramk at microsoft dot com

--
Sriram Krishnan
http://blogs.msdn.com/sriram
This posting is provided "AS IS" with no warranties, and confers no rights.

vachesacree (AT) yahoo (DOT) com wrote:
Actually I've managed to ask a few pretty dumb questions in my day.
I still cringe when I think about them. ;-)

-Dan