Re: Application xxx has encountered a serious error and must shut



Dean,

Thanks for the response - had a look at the compiler option you mention and
it refers to errors in buffer management code - functions like strcpy etc.
Well - as I use purely managed code I would 'expect' that the .Net wrappers
would ensure this does not occur :-O.

It did however made me look at my code even more critically - and I have two
areas (both in the serial interface) where I do an 'Array.copy' to move
incoming data into my own buffers. In both instances I do NOT adequately
check the returned data length against my own remaining buffer space :-O - so
this 'could' well be the root of my problem. I will be beefing up that code
at the very least - even though .Net should NOT be allowing me to do that -
or even if it does happen - it should exit gracefully and throw me an
exception I can (and would!) catch.

Pity that MS doesn't seem to be monitoring this thread - as we are
potentially exposing an underlying problem in the .Net CF 3.5 layers here
:-O. I thought that such errors should not be able to occur in 'managed code'.

Thanks again....

Regards

Graham


"Dean Ramsier" wrote:

I believe the message is getting triggered by the C run time library after
an error was triggered by its buffer overrun checking code. This is
controlled by the /GS compiler option, see the docs for more details.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"GrahamS" <GrahamS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3ACD8546-4A75-4713-AFFC-35194D4675AE@xxxxxxxxxxxxxxxx
Hi,

I have a CE application which runs pretty well on a number of embedded
PC's
(eBox 2300sx).

I am experiencing seemingly random failures however - some appearing days
after the application is started. These put up a dialog with the above
message (xxx is my app name).

Similar messages have also reported this as being in 'udevice.exe'.

My app is a Managed C# CF3.5 app and makes extensive use of a TCP Socket
and
a serial port (Com2).

My app has a full set of exception handlers - with some wrapping threads,
and one wrapping the whole app - but none of these are triggered when this
dialog pops up.

1. How do I identify what is causing this dialog ??.

2. How do I prevent it from occurring. There is no user - its a remotely
located device with no screen, keyboard or mouse and MUST run 24x7
completely
unattended. There is a UI but for 'diagnostic' purposes only - plug in a
screen and see what the device is doing.

I would make it a full 'windows service' if this were a PC - but its CE
:-O.

My app is run from within a command file so that IF it were to crash out -
it just gets restarted - this all works until the OS puts up this dialog
box
:-O - then one of my threads stops (serial port) until the OK button is
pressed.

This is making me wonder if I really should be using CE for this project
at
all :-((.

I cannot really 'instrument' this any further as adding KITL prevents me
from using the serial and ethernet ports - on which my app is based. It
also
completely changes the footprint of the device and thus may even mask the
issue anyway ??.

It 'looks' to me like an exception outside of my own code - maybe in the
'managed wrappers' ??.

This one has been driving me nuts for many weeks now as I cannot get to
the
bottom of it - especially as the error message is SO unhelpful!.

NB I replaced the MS SerialPort with OpenNetCF Serial and this seems to
have
made the occurrence rarer - I thought it had gone away - but yesterday it
came back again after running perfectly for a few days :-O.

Finally - it does not appear to happen on ALL boxes - although this may
well
be a 'red herring' - ie there could be other code changes introduced
whilst
trying to instrument the problem to locate it ;-O.

I am even now getting to the stage of questioning whether CE is the right
choice here - if it can put up a show-stopper like this. My eBox has 128M
RAM
so maybe I should be thinking about Embedded XP or some other OS ?? - ie
one
which has better support for 'services'.

Thanks hopefully.

Regards

Graham




.