Application xxx has encountered a serious error and must shut down
GrahamS
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
Rob
If you can debug your image, it should not be so hard to find where the
dialog comes from. Messageboxes are very rare in kernel/driver parts of the
system.
A simple search trough the CE sourcecode-tree might already identify it.
(assuming it comes from the OS)
Don't know how this applies to the sourcecode of the C# libraries...
Kind regards,
Rob
www.robtso.nl
GrahamS
Thanks for the feedback.
I am building my own NK.BIN file - although I wish I was not having to do
that :-O - its yet another layer of complexity I could do without ;-)) - but
I guess that it does give me greater control over the final product....
I am running a search right now - although I 'suspect' that it might be in
the CF code. I just saw my Com1 port - I had left it connected, and it shows
a lot of entries like :
Exception 'Access Violation' (14): Thread-Id=05170002(pth=87270854),
Proc-Id=051
60002(pprc=87270564) 'EmsAppCE.exe', VM-active=05160002(pprc=87270564)
'EmsAppCE
.exe'
PC=40bf7e9c(mscoree3_5.dll+0x00047e9c)
RA=40bf8256(mscoree3_5.dll+0x00048256) SP
=0004ee68, BVA=555555a8
Exception 'Raised Exception' (-1): Thread-Id=05170002(pth=87270854),
Proc-Id=004
00002(pprc=812a7800) 'NK.EXE', VM-active=05160002(pprc=87270564)
'EmsAppCE.exe'
PC=c00338b1(k.coredll.dll+0x000138b1) RA=c0033901(k.coredll.dll+0x00013901)
SP=d
1ecefc8, BVA=ffffffff
EmsAppCE.exe is my managed code app - but these exceptions are down in
mscoree and k.coredll :-O. Without runtime access to a debugger, I don't know
how to find where this is in my code ;-O.
This has made me start to look even harder at my code though - especially my
use of Queue<string> across multiple threads - and even my exception logging
mechanism - may need to beef up the thread-safe functionality here a little
as well ;-).
I am also adding an application-level 'UnhandledException' handler - as I
originally thought that just a try-catch around the Form.Run would have done
that - but I guess not - if the exception is from another managed thread
etc....
Its strange because I originally saw this type of failure back in January
but it seemed to be coming from my Socket Layer code :-O. Recently its
stopped my Serial port thread - last time it stopped the whole app :-O.
Thanks for the feedback though - helps keep me on the right track (and sane
I hope!) ;-).
Trouble is that I hate 'guesswork' (like try this and see if it fixes it) -
I'd much rather be able to understand exactly what is going wrong - then fix
it. Gives far more long-term confidence in my code :-O.
Regards
Graham
Rob
If you cannot debug the part (OS/C# ?) where it actually occurs, you are
left with trying to avoid the situation in which it occurs. This can easily
be caused by your app beeing not thread-safe, or some other misuse of an API.
In that case you should be able to find and fix it.
If it's a bug in some driver, CE , or C# LIB, you will be in trouble if you
can't debug those parts. IMHO This is the price you sometimes pay for the
choice of a high-level language.
Kind regards,
Rob.
www.robtso.nl
Chris Tacke, eMVP
caused by someone accessing memory they don't have ownership of, and in
managed code that's really hard to do. Are you using unsafe code anywhere?
P/Invokes using handles (IntPtr, int, uint, GCHandle or otherwise)?
I'm betting this is not a thread issue, but a compaction issue. You've got
some buffer that was passed to native code, then that buffer gets moved by
the GC and the native code tries to use the old buffer address.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"GrahamS" <Gra...@discussions.microsoft.com> wrote in message
news:F23FBD0A-E81B-44B6...@microsoft.com...
Rob
But I guess this is no so much a problem in C#.
Kind regards,
Rob
www.robtso.nl
Chris Tacke, eMVP
that case.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"Rob" <__rob_AT_robtso_DOT_nl__> wrote in message
news:2892B770-E4DE-4816...@microsoft.com...
GrahamS
This has generated some feedback here - sorry I was away doing something
else - having made some tweaks and letting it run.
To answer a few of the points.
Unmanaged code - the only stuff I am aware of is in the OpenNetCf_Serial
stuff - and I added that AFTER I started having these issues.
Thread communications are all (bar 1 which I will come to) done using simple
typed string queues. All declared as public static (as I read somewhere that
these were thread-safe in CF).
public static Queue<string> command = new Queue<string>();
There is (or was) one probably issue I found in my code. I have a static
Audit task, which can write to a disk file, and actually does quite often.
This was actually doing the writing directly from the calls - ie in each
thread!!. It just uses a System.IO stream. SO - I have now decoupled this by
just adding the text to be written into yet another static Queue - then I
have one task (in my main UI timer event) which actually does the writing. My
'guess' is that threads 'could' have been competing for the log file -
especially as it gets larger (its a new file every day) and I just append the
next log entry to it - BUT the latest crash was early on Sunday AM - at 01:54
- when the file would have been quite small anyway.
So - its running with this change made now....so we'll see how that goes I
guess.
I never found any reference anywhere under WINCE600 of 'must shut down'
which is the tail of the error message.
Wait a mo... just had a further thought - if I were to create a string in
one thread, then Enqueue that to 2 queues - does it get queued by reference
or value ??, it couldn't then be being deleted by one thread whilst still in
the second queue could it ?? - I would hope not, but could code around that
just in case I guess.
Thanks guys for your ongoing help with this one....
Graham
Dean Ramsier
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" <Gra...@discussions.microsoft.com> wrote in message
news:3ACD8546-4A75-4713...@microsoft.com...
GrahamS
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
Wil
(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
Michel Verhagen [eMVP]
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
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]
already use up your 2 free support calls with Platform Builder? Or you
don't have Platform Builder?
Wil
3rd party (in fact, purchasing it this way is enforced via company policy),
and when you call MS, they say - "oh, that SKU is a support-less SKU", please
get out your credit card. So we're getting a "deal" of some sort, I
suppose. Long answer to a simple question...
Michel Verhagen [eMVP]
idea on how to deal with CE support questions and they don't know about
the 2 free support calls you get with PB. As long as you bought a legal
Platform Builder you get the 2 free support calls, at least as far as I
know. Just don't take no for an answer and don't pay when you don't have
to. I've just been through another 2 hour session opening a support call
and they told me several times I just had to pay. In the end I didn't,
but only because I was very persistent and have called them many times
before (so I know the procedure, just have to convince them...). This
issue with CE support is being escalated at Microsoft as we speak, so
hopefully the next time you call with a CE specific problem the support
people will actually know what to do.
Bruce Eitman [eMVP]
it from a third party. So your company didn't do anything unusual.
--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman
EuroTech Inc.
www.EuroTech.com
"Wil" <W...@discussions.microsoft.com> wrote in message
news:A5E71651-7E53-4911...@microsoft.com...
GrahamS
Just got a notification that this topic had come back to life and thought I
should add my two -penn'th.
The issue arises on my code in 'some' systems but not others, and my view is
that it is not a PB or DevStudio problem :-O. Mine arises on 'release build'
code running completely stand-alone. I 'suspect' its somewhere in mscoree or
below that the error is occurring.
I have 'gone quiet' on this topic purely because I am in the process of
completely re-architecting my (managed) application and its not yet got to
the CE stage yet ;-).
Hope this helps....
Regards
Graham
Wil
site where a particular function (call it f()), is about to be called for the
first time. Then trying to step into (F11) the function causes the error. I
can verify that the passed parameters all look good before attempting to
step in. There are 12 passed parameters.
I suspect that this must be a problem with the JIT compiler or .NET support
code in some way, since this would be the first execution of f(), and it is
getting JITted. I suspect that my environment is such that there is
additional memory load, etc., in the failure case that is somehow aggravating
the JIT compiler.
Does this sound like a JITter issue?
- Wil
Wil
JITter issue that they have fixed but not yet released. Look for a QFE
coming your way some time in the future!
- Wil
Paul G. Tobey [eMVP]
Paul T.
"Wil" <W...@discussions.microsoft.com> wrote in message
news:0DF44CB5-F14A-4128...@microsoft.com...
kummool
"Wil" <W...@discussions.microsoft.com> wrote in message
news:0DF44CB5-F14A-4128...@microsoft.com...
Wil
build of .NETCF 3.5 we received from MS (9085) addressed the issue, which as
a JITter bug which wrongly used a relative jump instruction which couldn't
jump more than 32MB. Since CE6 removes the 32MB VM space limitation of CE5,
it was now susceptible to this bug.
Now I've opened another case with MS as we're seeing the "serious error"
dialog outside the managed debugger situation...
Igor Golikov
We experience the same problem using CE 6 (both R2 and R3) and CF 3.5.
This error message occurs when , for example, i close our main form.
For this case I have a memopry dump output (from Dr.Watson):
STACK_TEXT:
0007fad0 40d67068 : 40d88bdc 076d0002 00000000 00000002 : netcfagl3_5!
GUI_Init+0x10b50
0007fadc 40d0cb7c : 40d88bdc 076d0002 00000000 00000002 : netcfagl3_5!
GUI_Init+0x12938
0007fae8 40d5d930 : 40d88bdc 076d0002 00000000 00000002 : mscoree3_5!
NSLHandle_Release+0x3c
0007faf4 40d54228 : 40d88bdc 076d0002 00000000 00000002 : netcfagl3_5!
GUI_Init+0x9200
0007fb18 40c94a84 : 40d88bdc 076d0002 00000000 00000002 : netcfagl3_5!
DllMain+0xac
0007fb1c 40c9e034 : 40d88bdc 076d0002 00000000 00000002 : mscoree3_5!
EE_SetTerminateProc+0x34
0007fb20 40c9495c : 40d88bdc 076d0002 00000000 00000002 : mscoree3_5!
EE_GetCurrentAppDomainCompatVersion+0xbd4
0007fb30 40d2d59c : 40d88bdc 076d0002 00000000 00000002 : mscoree3_5!
PALProcess_CurrentTerminate+0x1a14
0007fb3c 40d2c594 : 40d88bdc 076d0002 00000000 00000002 : mscoree3_5!
DllGetClassObjectInternal+0x3e4
0007fb4c 40c498d4 : 40d88bdc 076d0002 00000000 00000002 : mscoree3_5!
PALHost_LaunchApp+0x214
0007fda0 40c49a80 : 40d88bdc 076d0002 00000000 00000002 : mscoree!
PALHost_LaunchApp+0x64
0007fdb8 4003c124 : 40d88bdc 076d0002 00000000 00000002 : mscoree!
CorExeMain+0x174
0007fdf0 00000000 : 40d88bdc 076d0002 00000000 00000002 : coredll!
_InternalCxxFrameHandler+0x388
It seems that there is a problem in CF 3.5. I am working on catching
this message during the application lifecycle. IF memory dump will be
available I think it will be clear what is the issue.
The second issue I noticed is that sometimes remote process viwer just
stops working. It connects to the device buyt shows only one record
with adress 0000000 - looks like something VERY buggy.
The most is that when I replace the tolhelp.api DLL from the release
directory - it works back!
But the files are different in size... something very very strange.
Besides, I n oticed that using toolhelp.dll (for toolhelp API) can
cause some very weird things. For example,
Igor Golikov
One more failure:
On debug output i have:
Exception 'Data Abort' (4): Thread-Id=06bd0052(pth=84270d4c), Proc-
Id=06bc004e(pprc=83d2b780) 'GUI.exe', VM-active=06bc004e
(pprc=83d2b780) 'GUI.exe'
PC=4002c384(coredll.dll+0x0001c384) RA=40d11660(mscoree3_5.dll
+0x000b1660) SP=0007fad0, BVA=00000064
GUI.exe is our managed application.
From the Dr.Watson dump I have:
STACK_TEXT:
0007fad0 40d1165c : 00000060 06bd0052 0000001c ffffc808 : coredll!
LineTo+0x40 [d:\yamafp-1\private\winceos\coreos\core\thunks
\twingdi.cpp @ 958]
0007fad8 40d82324 : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
PALCriticalSection_Enter+0x4
0007fadc 40d0cb7c : 00000060 06bd0052 0000001c ffffc808 : netcfagl3_5!
GUI_Init+0x2dbf4
0007fae8 40d5d930 : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
NSLHandle_Release+0x3c
0007faf4 40d54228 : 00000060 06bd0052 0000001c ffffc808 : netcfagl3_5!
GUI_Init+0x9200
0007fb18 40c94a84 : 00000060 06bd0052 0000001c ffffc808 : netcfagl3_5!
DllMain+0xac
0007fb1c 40c9e034 : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
EE_SetTerminateProc+0x34
0007fb20 40c9495c : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
EE_GetCurrentAppDomainCompatVersion+0xbd4
0007fb30 40d2d59c : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
PALProcess_CurrentTerminate+0x1a14
0007fb3c 40d2c594 : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
DllGetClassObjectInternal+0x3e4
0007fb4c 40c498d4 : 00000060 06bd0052 0000001c ffffc808 : mscoree3_5!
PALHost_LaunchApp+0x214
0007fda0 40c49a80 : 00000060 06bd0052 0000001c ffffc808 : mscoree!
PALHost_LaunchApp+0x64
0007fdb8 4003c124 : 00000060 06bd0052 0000001c ffffc808 : mscoree!
CorExeMain+0x174
0007fdf0 00000000 : 00000060 06bd0052 0000001c ffffc808 : coredll!
_InternalCxxFrameHandler+0x388
It seems that our app caused this error in MS dll. The problem is how
to know the managed stack that caused the crash:(
Any ideas?
Thanks
Igor Golikov
Any news????????
Ulrich Eckhardt
> HELLOOOO
> Any news????????
Igor, I'm not sure what you are replying or referring to, but considering
the title of your posting you may be wondering where that message box comes
from. The answer is simple, it is generated by a built-in check that tries
to detect overflows of arrays on the stack.
I recently had the same and it turned out that sometimes two threads were
accessing the same piece of data concurrently.
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Igor Golikov
Hi
Great to have an answer;;;
But maybe there is a way to know where did it come from? In a large
app its almost impossible to find it by trying to look over the
code... Especially when I cannot reproduce this message.
Thanks anyway:)
Igor
Ulrich Eckhardt
> But maybe there is a way to know where did it come from? In a large
> app its almost impossible to find it by trying to look over the
> code... Especially when I cannot reproduce this message.
The thread linked below is what I found and what helped me most. The problem
is that it even is hard to produce the error even when using the example
the compiler docs give.
Anyway, what I did was to for another thread that watches all others. If one
thread runs into this error, it will be stopped, which can be detected
because all others are still running. This is a bit different from e.g.
a "normal" access violation, where the OS terminates the application. Here,
the check is built into the application which otherwise keeps on running.
Once I had an idea where the crash happened, I also saw patterns that
triggered it and eventually could resolve it. There was some guessing
involved though.
Good luck!
Uli
Igor Golikov
> Igor Golikov wrote:
> > But maybe there is a way to know where did it come from? In a large
> > app its almost impossible to find it by trying to look over the
> > code... Especially when I cannot reproduce this message.
>
> The thread linked below is what I found and what helped me most. The problem
> is that it even is hard to produce the error even when using the example
> the compiler docs give.
>
> Anyway, what I did was to for another thread that watches all others. If one
> thread runs into this error, it will be stopped, which can be detected
> because all others are still running. This is a bit different from e.g.
> a "normal" access violation, where the OS terminates the application. Here,
> the check is built into the application which otherwise keeps on running.
>
> Once I had an idea where the crash happened, I also saw patterns that
> triggered it and eventually could resolve it. There was some guessing
> involved though.
>
> Good luck!
>
> Uli
>
>
> --
> Sator Laser GmbH
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Hi Ulrich
I didnt understand what you mean by "watcvhing another threads".
How does it happen? Can you give me a simple example here?
Thanks
Ulrich Eckhardt
> I didnt understand what you mean by "watcvhing another threads".
> How does it happen? Can you give me a simple example here?
I just updated the current file and line in a global variable and checked
that variable regularly in a different thread. If it doesn't change for
some time, I can assume the thread is blocked at that position.
Uli
Igor Golikov
OK thanks:)