Re: WM_TIMER crash (maybe)?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 15 Jun 2005 10:52:18 -0400
My first inclination would be to check for resource leaks. It sounds very much like
something is running out. A 'new' failed. An operation requiring a handle didn't find a
handle. Something like that.
Are you multithreaded? Note that the normal debug dialog opens up in some thread; if
another thread is still running, it could be generating requests asynchronously. In
addition, I suspect that, given the debug dialog IS, in fact, a dialog, and therefore it
has a message pump, so there is a good chance that WSAAsyncSelect is allowing new messages
to be sent for network events, in which case the situation which caused the first fault
will cause the second fault.
Now this leads to other issues. For example, if you install VC, it typically installs the
latest runtimes and other libraries (not all of which could be statically linked, so
static linking is a red herring, and probably unrelated to the problem), the point being
that you could be replacing older DLLs with the latest redistributable DLLs. Next, when
you say you are using the debugger, are you compiling the program in debug mode, instead
of release mode? In that case, you are debugging a DIFFERENT program, not the one that is
failing. The heap usage in a debug heap can be quite different from the heap usage of the
same code running in release mode. If you need to debug a release version, you need to
create debug symbols for the release version as well.
The phenomenon where using a debugger produces a different result than not using it is
well-understood. There's even a name for the types of bugs that only appear when the
debugger is absent: "Heisenbugs".
I would suggest that if you see the bug on a machine, you first run Depends, and carefully
record every DLL that it shows, including the version numbers. Then compare this list to a
machine on which you have already installed VC. If you see any differences, it suggests
that perhaps some existing library has been properly updated with a corrected version.
The static linking solution attempt is based on the erroneous premise that the only
library used as a DLL is the standard MFC library. In one simple MFC library, I had 26
DLLs. ONE of them was MFC42.dll; the rest were system DLLs, including OLE/COM libraries
and many others. Some of these are part of the "standard redistributable libraries" you
should be including in your install (or are you still subscribing to the myth that copy ==
install? This hasn't been true in at least 15 years, but some people pretend that they are
the same. They are most certainly NOT the same). If your program is not being installed by
a professional install program, you are at risk for having one or more DLLs inconsistent.
If installing VC on the machine makes the problem go away, this is almost certainly an
indicator that the statically-linked MFC library is still depending, for its correctness,
on other libraries whose behavior is expected to be consistent with that MFC library.
One solution you might try is to intercept the exception yourself. See Doug Harrison's
article on how to intercept exceptions in C++, http://members.cox.net/doug_web/eh.htm,
Not saying this is going to be easy, but it could handle the double-fault problem a little
better by allowing you to record something about the failure before any dialog box pops
up, thus perturbing the environment by creating a secondary message pump.
joe
On Wed, 15 Jun 2005 00:56:12 -0500, "x" <x@xxxxx> wrote:
>I've got a network polling program. Interrogates different devices
>continuously using CAsyncSockets. Use callbacks (OnReceive & OnConnect) for
>socket events, and keep WM_TIMER running to monitor when to give up for
>response after send. After perhaps 100,000 transactions over anywhere from
>8 to 24hrs the next OnTimer doesn't happen. An exception occurs when I
>anticipate the next WM_TIMER should fire, the debug dialog opens, then
>another exception occurs, and the program is closed. DrWatson only records
>the software Int that closest the program (trying to re-open debug dialog
>when debug dialog is already opened).
>
>The program runs FOREVER without ever halting on any machine with VC
>installed (can run weeks on end). If I install VC on a machine where I see
>the fault, I don't see the fault ever occur again (so much for using a
>debugger). Depends shows all files present. I've taken to building with
>release build with static libraries to minimize the requirements for any
>external mfc dlls, but that doesn't have impact (a previous suggestion from
>this newsgroup was to check that all required dlls were current on a machine
>without VC installed).
>
>Since I'm unable to ever see the fault occur running under VC debugger, I
>send diagnostics to another task so I can examine what was happening up to
>the fault. I see a socket created, connected, send, and return ... to await
>reply. There's no indication of another WM_TIMER event (OnTimer calls are
>set to reoccur repeatedly). Every fault seems to show a successful exit of
>all events through the last message sent, so I'm wondering if WM_TIMER is
>crashing.
>
>Any ideas?
>
>Rich
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- WM_TIMER crash (maybe)?
- From: x
- WM_TIMER crash (maybe)?
- Prev by Date: Re: how to make a stealth application
- Next by Date: Re: spawning process
- Previous by thread: Re: WM_TIMER crash (maybe)?
- Next by thread: Re: WM_TIMER crash (maybe)?
- Index(es):
Relevant Pages
|
