Re: WM_TIMER crash (maybe)?

Tech-Archive recommends: Fix windows errors by optimizing your registry

running in debug / release?
Stops with either release or debug mode (built & tested both).

>What debug error?
In a previous thread I described the situation as "program gone" in that it
never displays any error message. A reply explained that if the dialog
describing the fault is followed by a 2nd, the program is closed. DrWatson
stack trace seems to indicate that this is happening, so one of my basic
difficulties is in not having any info on the error.

I've created a capability to insert a function with a text argument that
sends the text to another task which maintains a forever circular queue of
the text. Should the main program "be gone" I can examine the text log from
what I call the TRACE task. I log every socket create, connect, send,
receive, and close. I also log OnTimer entrance, exit, OnReceive entrance,
exit, etc., along with about a thousand other points. What I always see as
the last operations started with an OnReceive of a reply, processing, script
execution (the program is programmable) leading up through sending of the
next poll, and concludes with what looks to be a completely normal exit.
Whatever the fault is it doesn't appear to be within the time-span of my
program operation. I increased the frequency of WM_TIMER events (shortened
the settimer) so I typically see one or more OnTimer executions after
sending a message before the next OnReceive event. Since the log never ends
on an OnTimer, I can only infer that the initiation of a next WM_TIMER event
faults before my program reaches the first text TRACE from the OnTimer
routine (practically the first thing my routine does).

>What do you do on OnTimer overrides?
The main function is to test if it's been too long since the last message
was sent without having received an OnReceive event. Typically OnReceive
events receive responses and initiate resuming the polling script. When
OnTimer determines that a timeout has occurred, OnTimer initiates resuming
the polling script. The polling script is operated in a separate thread.
The TRACE log has always indicates correct response from the previous sent
poll initiating the events resulting in the send event which ends the TRACE.

>Ensure you are not creating tens of thousands of new sockets and not
closing and deleting them after.
The polling script is single threaded. It only uses a single socket.

"Mark Randall" <markyr@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:eNko9UZcFHA.3464@xxxxxxxxxxxxxxxxxxxxxxx
What debug error? Are they all running in debug / release? In release things
like buffer overflows go unnoticed etc. Ensure you are not creating tens of
thousands of new sockets and not closing and deleting them after.

WM itself can't crash, its simply pushed through a handler array which if it
works once, should work forever. What do you do on OnTimer overrides?

--
- Mark Randall
http://zetech.swehli.com

"x" <x@xxxxx> wrote in message news:5p-dnS7YCuKPXzLfRVn-jA@xxxxxxxxxxxxxx
> 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
>
>



.

Relevant Pages

  • Re: WM_TIMER crash (maybe)?
    ... As a result, if a wrong handler is supplied, the message ... > Stops with either release or debug mode. ... > describing the fault is followed by a 2nd, ... I also log OnTimer entrance, exit, OnReceive ...
    (microsoft.public.vc.mfc)
  • Re: WM_TIMER crash (maybe)?
    ... Are they all running in debug / release? ... What do you do on OnTimer overrides? ... If I install VC on a machine where I ... > the fault, I don't see the fault ever occur again (so much for using a ...
    (microsoft.public.vc.mfc)
  • Re: windows error
    ... > for teh alst few days whenever I open either control panel I get an error ... > microsoft Visual C++ Debug library ... > I have turned off the script debugger in internet options for both internet ...
    (microsoft.public.windowsxp.help_and_support)
  • _CrtIsValidHeapPointer() debug error
    ... In my debug build executable, i get the following an assertion fault with _CrtIsValidHeapPointerwhen i exit. ... the same fault does not happen when i exit the debug build on my development comp. ...
    (microsoft.public.vc.debugger)
  • WM_TIMER crash (maybe)?
    ... socket events, and keep WM_TIMER running to monitor when to give up for ... the software Int that closest the program (trying to re-open debug dialog ... 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 ...
    (microsoft.public.vc.mfc)