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

OK. Do you think this is a Platform Builder support issue or a DevStudio
support issue? I have lots of MSDN support issues, but no PB support issues
available... I suppose I'll just call and find out...

- Wil S

"Michel Verhagen [eMVP]" wrote:

Your only real way forward is opening a support incident with Microsoft
and driving for a QFE. If you have Platform Builder you may get away
with using one of your 2 free support incidents. If this is really a bug
in MS code or an MS component you will still have 2 free support
incidents (as a MS bug does not count towards your free support incidents).

Make sure you get a QFE, so everybody reaps the benefits.

Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.

Wil wrote:
I'd like to chime in on this. We're seeing a similar issue with our managed
(C#, .NET CF 3.5, ARMV4I CPU) app on WinCE6.0. We see the same dialog box
pop up (where xxx is our application name). Our application has both managed
and unmanaged components. We've determined the following through trial and
error:
1) Our application works fine in WinCE5.0. We've been shipping it for about
9 months now. The failure only occurs when running CE6.0.
2) The failure seems only to occur when running under the managed debugger.
We can launch under the unmanaged debugger (useless for debugging managed
code, which is 95% of our app), and it works fine - no error even under
conditions in which is would "always" fail under mananged debugging).
3) The failure is not 100% predictable. In different conditions, it seems
to "always" occur, and in others it sometimes occurs.
4) If we reduce the complexity of the application (by snipping out some
plugin functionality that would otherwise be loaded), the failure happens
less often or "never".
5) Our particular failure, if it shows up, shows up within a minute or so of
starting, typically just before or just after the main Form is displayed.
6) Like GrahamS, we use sockets and serial.

Our assesment so far is that this is a problem with managed debugging and/or
conmanclient2, or possibly the LAN related code (driver?). Given that LAN
works fine (we've done extensive testing) in other situations, I think the
issue must be with conmanclient2 or .NET 3.5 runtime running on WinCE6.0.

GrahamS is right in that there is little or no information given in this
message. It is not a managed issue, else as Chris points out we would get a
managed exception. There's something going on in conmanclient2 or perhaps
mscoree that is operating outside of managed code.

I'd love to hear if anyone has any hints about how to proceed.

Thanks,
Wil S

"GrahamS" wrote:

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




.