G
GrahamS
Hi,
More than 6 months ago I tried (unsuccessfuly) to get support for a random
problem where coredll bombed without going into my catch handler. I could not
easily demonstrate this as it seemed to be 'data dependent'. It may even have
nothing to do with the following - apart from the unprocessed exception!
I worked around this at the time by eliminating a specific piece of hardware
(usb->RS485 port), and using instead an external serial to RS485 adapter.
I now have a similar problem once again but this time I can prove it as
follows :
In a Windows CE Winform app add a button and make the button handler do the
following :
try
{
long l1 = 8169325;
MessageBox.Show(string.Format("Convert: {0}", (Single)l1));
}
catch (Exception ex)
{
MessageBox.Show("Exception: " + ex.Message);
}
}
The relevant piece of code is '(Single)l1' - as my app used this in a
different way, the dialog box is simply to demonstrate the BUG.
Running this on my CE device bombs with an Exception code 0xc0000005 in
coredll. This pops up a Quit dialog instead of calling my handler.
Now build and run the very same code under Windows and its fine.
NB I suspect that the actual number may not really matter - although it just
might.
Whilst I can work around the issue by declaring the variable as a Single in
the first place - I am still VERY worried that coredll can even throw up such
a dialog box. My application runs on an embedded box which has no user
interface - let alone a user to press the quit button. So my remote app is
effectively trashed.
Look forward to a review/comment from MS please .
NB The underlying OS is not built using the latest release, as I already
have builds out there with an nk.bin built a year ago.
Thanks
Graham
More than 6 months ago I tried (unsuccessfuly) to get support for a random
problem where coredll bombed without going into my catch handler. I could not
easily demonstrate this as it seemed to be 'data dependent'. It may even have
nothing to do with the following - apart from the unprocessed exception!
I worked around this at the time by eliminating a specific piece of hardware
(usb->RS485 port), and using instead an external serial to RS485 adapter.
I now have a similar problem once again but this time I can prove it as
follows :
In a Windows CE Winform app add a button and make the button handler do the
following :
try
{
long l1 = 8169325;
MessageBox.Show(string.Format("Convert: {0}", (Single)l1));
}
catch (Exception ex)
{
MessageBox.Show("Exception: " + ex.Message);
}
}
The relevant piece of code is '(Single)l1' - as my app used this in a
different way, the dialog box is simply to demonstrate the BUG.
Running this on my CE device bombs with an Exception code 0xc0000005 in
coredll. This pops up a Quit dialog instead of calling my handler.
Now build and run the very same code under Windows and its fine.
NB I suspect that the actual number may not really matter - although it just
might.
Whilst I can work around the issue by declaring the variable as a Single in
the first place - I am still VERY worried that coredll can even throw up such
a dialog box. My application runs on an embedded box which has no user
interface - let alone a user to press the quit button. So my remote app is
effectively trashed.
Look forward to a review/comment from MS please .
NB The underlying OS is not built using the latest release, as I already
have builds out there with an nk.bin built a year ago.
Thanks
Graham