.NETCF 2.0 app abruptly exits without any exception info

G

Guest

I'm seeing a weird problem in a .NETCF 2.0 application running on a HP hw6515
(PPC 2003 SE Smartphone edition). Sometimes, the application suddenly exits
without (apparently) an exception occuring. The application itself is
moderately heavy (uses a few native DLLs) but usually when a problem occurs
in one of the DLLs, I get an exception message. In this case, I get nothing.

I'm starting to suspect an issue with the .NETCF runtime. Did anyone see
something similar? Unfortunately, the problem seems erratic. My app can run
for hours without crashing, and sometimes after a few minutes (without
touching the device) it will just ... poof! vanish.

Any lead on this? Could this be related to a memory shortage on the device?
 
G

Ginny Caughey [MVP]

Florent,

Is anything else happening on the device like other apps or receiving a
phone call? Is your app in the foreground or the background when this
happens?
 
I

Ilya Tumanov [MS]

PPC/SP could terminate applications any time if OS is running low on
resources.

That's probably what you're observing.


Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
G

Guest

Ginny Caughey said:
Florent,

Is anything else happening on the device like other apps or receiving a
phone call? Is your app in the foreground or the background when this
happens?

The app is always on the foreground, and there is nothing else running on
the device at that time (no SIM card therefore no phone calls). The only
other app running is File Explorer which I use to start the app when I'm not
debugging (out of cradle).

BTW, to date I have never seen this issue occur while debugging (I use
VS2005). This seems to happen only when the device is unplugged. The battery
is always in full charge, and I made sure there is enough memory left of the
device. Profiling with the .NETCF perf counters shows that the app allocates
around 2.5Mb.

Note that the unmanaged C++ code does some moderately heavy things like
memory-mapping a couple large files (a few megabytes) stored on the SD card.
In total, the app eats around 9Mb on the device, and there are always several
MBs left as shown briefly in the Today screen when I leave the app.

The weird part is the complete lack of any exception dialog which would
indicate a bug in my code. Usually when something goes wrong (i.e. in the
unmanaged code) I get an Exception dialog. In the case I'm describing,
nothing happens. The app just goes away.

Florent
 
G

Ginny Caughey [MVP]

Florent,

Ok we've eliminated most of the normal things. Do you have a Closing event
handler, and if so, is it called?
 
G

Guest

Apparently not. There is only one exit point in the application (a Quit
button on the main form). All forms are maximized without any title bar /
close button. I added a MessageBox.Show() in the code that quits the
application to make sure it's not being called in my back -- though this
seems unlikely as it is the Click handler of a buton.

Florent
 
G

Ginny Caughey [MVP]

Florent,

I'd suggest adding a Closing event handler then so you can trap when the app
is mysteriously shutting down. As Ilya says, the OS will ask apps to close
when resources are low, so this would give you a chance to do any cleanup,
etc.
 
I

indiekiduk

Hi since your app is in the foreground its unlikely its being closed to
free up resources, sounds more like a segmentation fault, check any
threaded code you have. Anyway this is how I prevent the OS closing my
app:

bool reallyClose;

protected override void OnClosing(System.ComponentModel.CancelEventArgs
e)
{
if(!reallyClose)
{
e.Cancel = true; // OS can't close this app
}
base.OnClosing (e);
}

private void exitMenuItem_Click(object sender, System.EventArgs e)
{
reallyClose = true;
}
 
G

Guest

Thanks for the tip. I confirmed that the abrupt exit isn't occuring because
of a normal Quit (using the Quit button). Now I just managed (no pun
intended) to reproduce the issue while debugging. The last output message
from the debugger was:

The program '[7281efda] MYAPP.exe: Managed' has exited with code 0 (0x0)

Then the debugger said it "lost the connection". Therefore, something fishy
is happening. I'll add a Closing handler to see if it goes through it before
leaving.

Florent
 
G

Guest

Another idea comes to mind about this mysterious crash. In my application, I
have a few delegates (4) that are being passed to a native thread and kept by
it. The native thread then calls the delegates when it needs to.

Now I made sure that these delegates are never left alone with any reference
to them in my managed code. But thinking about it, what may happen is that
the GC goes off and maybe moves memory. In this case, is it possible that the
function pointers kept by the native code become invalid ?

And if yes, does this mean I need to encapsulate my delegates in a GCHandle
with the pinned attribute?
 
R

Robert Simpson

When you create an instance of your delegate, your managed code needs to
keep hold of a reference to them, otherwise they'll be GC'd. It's a lot
easier to just hold them in a member variable of a class than to try pinning
them or doing any other workaround.

Robert
 
G

Guest

The delegates are always referenced from the managed code. But since they
were not "pinned", I suspect that when the GC decides to move things around,
it may very well move the actual function pointer that was previously passed
to the native code (and kept by the native code). It is my understanding that
delegates can be moved around by the GC like any other object, though the
documentation is not exhaustive on this point.

For the time being, I did this (we'll see if it solves my mysterious app
exit):

private GCHandle pinDelegate;

private void InitCallback()
{
myDelegate = new CallbackHandler(myHandlerFunc);
pinDelegate = GCHandle.Alloc(myDelegate, GCHandleType.Pinned);
NativeCode.SetCallback(Marshal.GetFunctionPointerForDelegate(myDelegate));
}

This works fine, and hopefully will solve this random issue.

Thanks to all for your answers and help, I'll come back if the crash still
occurs :)
 
G

Guest

Ginny,

I managed to reproduce the issue more often than not and after a lot of
traces, it appears that the OS or framework is Closing my form for some
reason (I don't exactly understand why it decides to do so, but my OnClosing
handler is being called). As this is not a normal situation for my app, I'm
following indiekiduk's advice and set the cancel flag. That should do it.

Thanks to all for your answers!
Florent
 
G

Guest

indiekiduk,

Would you mind to post this code in VB.NET? I'm having a nearly same issue
as Florent.

Thanks in advance.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top