Markus
Mon May 01 09:32:58 CDT 2006
Thanks a lot for your answer. I have already lots of assertions in place.
Unfortunately the bug occurs only "on the read" it's not that easy (or
convenient) to run under the debugger (although I will do this as last
resort). As the problem seems to appear in a background thread which has
some real time requirements, I can't introduce MessageBoxes because they
would make the application unusable.
It really seems that I neet a lot of patience.
Markus
> 2) add ASSERTs to check pointers and array references
> 3) add MessageBoxes to keep track of the program so you can find where
> in your code the symptom shows
> 4) patience. lots and lots of patience
<r_z_aret@pen_fact.com> wrote in message
news:c51552h9a6r1nojlthfpk2u1qd09obrppi@4ax.com...
> Such pain is more common than any of us would like to admit. The basic
> cause is often a bad pointer or code that cleans up an array
> incorrectly. And the symptoms commonly occur far away from the actual
> bug. Some common methods:
> 1) run under a debugger and hope the debug window provides sufficient
> feedback. Adding calls to OutputDebugString will help
> 2) add ASSERTs to check pointers and array references
> 3) add MessageBoxes to keep track of the program so you can find where
> in your code the symptom shows
> 4) patience. lots and lots of patience
>
> I just used google (
http://groups.google.com/advanced_group_search) to
> look up
> debug release
> in this newsgroup and got 242 hits. I think at least a few provide
> relevant and useful info.
>
> On Fri, 28 Apr 2006 09:40:25 -0700, "Barry Bond [MS]"
> <barrybo@microsoft.com> wrote:
>
> >If the bug repros on the DeviceEmulator, then you might have some luck if
> >you configure the emulator to display its debug console window for serial
> >port 1. When the kernel detects an application exception, it logs
critical
> >data about the exception out to the device's serial port.
> >
> >Barry
> >
> >"Markus Hofer" <mh@smartsol.ch> wrote in message
> >news:u90stVsaGHA.4424@TK2MSFTNGP02.phx.gbl...
> >> I'm currently hunting a "rare" bug in a MFC PocketPC program, which
causes
> >> the program to just "disapear" from the screen. I'm using VS2005 and
the
> >> program targets PocketPC 2003 devices. The same Executable also runs on
> >> WM5
> >> PocketPCs.
> >>
> >> The bug is not reproducible and occours without user interaction (there
> >> are
> >> some background threads in the application). How can I find such a bug?
> >> I checked lots of documentation and googled on the Web, but could not
find
> >> good method:
> >>
> >> a) Postmortem debugging / Dr. Watson
> >> On WM5 it seems to be possible to write a crash dump (resp. Dr.
Wastson
> >> Log) and to do
> >> some postmortem debugging using the dump. Unfortunately all the
> >> documentation I found
> >> referenced Platform Builder but none mentioned VS2005. So I'm not
sure
> >> whether it is at all
> >> possible to do this with VS2005
> >>
> >> b) Exception Handling
> >> VS2005 supports SEH as well as C++ exception handling. SEH would
> >> probably
> >> report the crash,
> >> but does not unmangel the stack (destructors are not called) which is
a
> >> problem in multithreaded
> >> programs (locks!).
> >> C++ exceptions are not really helpful to find this bug, because it
does
> >> not give you information about
> >> the exception.
> >> In the WIN32 Api there exists the function _set_se_translator that
> >> allows
> >> you to handle a SEH exception as
> >> C++ exception. Unfortunately this function does not seem to exist for
> >> the
> >> PocketPC.
> >>
> >> So whatever I tried, it did not work as expected. All ideas, comments,
> >> recommendations and so ob are highly
> >> appreciated.
> >>
> >> Markus
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> -----------------------------------------
> To reply to me, remove the underscores (_) from my email address (and
please indicate which newsgroup and message).
>
> Robert E. Zaret, eMVP
> PenFact, Inc.
> 20 Park Plaza, Suite 478
> Boston, MA 02116
> www.penfact.com