mfc vc++ dialog app stops updating screen.

Simple Dialog Application, Screen updates stop and or don't display correctly.
Multi-threaded to communicate via connected sockets, serial ports,  pipes, events, user created messages.
Writes to a text log file (this keeps happening when the screen updates stop).
Works just great for 55 minutes, then the screen updates stop.
A list control in the dialog seems to keep updating as required, but
a multi-line edit control (write only, duplicate of the text log) stops, as well as
a number of static text controls, (one is a digital clock) both text and background color updates.
A child dialog can be brought up but doesn't display correctly.
No memory leaks are reported when the app is halted in the debugger (VS 2005 standard).
I must have something really foobar`ed.
Any thoughts as to how to find out what?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

If you can launch the app under VS and reproduce the problem there, press Break in the Debug menu and you will see all threads and where they are.
Probably, there is a problem with a critical section a mutex. Check all places where you enter to a critical section or lock the mutex.  
AndyAinscowFreelance programmer / ConsultantCommented:
Sounds like it could be a resource leak.
You don't get warnings about these from the IDE when your app finishes :-(

Basically windows uses handles to identify things.  There is a fixed maximum number of handles available to the operating system - when you use one then don't give it back, then another.... until the op system freezes typically with display problems first.
dia_richAuthor Commented:
I believe that your suggestion is the most likely cause of my issue.
How does one programmatically ensure that used handles are released?
CompTIA Security+

Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.

It is beginning of typical elimination process that I can only describe in abstract since I have no idea of what application does or what the circumstances are.

Option 1, if you have any goof performance monitor application, use that on the app

Option 2: To rapidly locate the problem, I'd replace the client of application by a stub code (dummy) and then introduce resources back into the pool one by one until app breaks again.

Also, there are tricks such as artificially reducing available memory so that error would crop up sooner These utilities typically ship with Studio doubt you as a person have patience to wait 55 minutes. OR
you can write your own memory gobbler.
AndyAinscowFreelance programmer / ConsultantCommented:
Releasing handles - no easy method that I know of.  
For example when a Font is selected into a windows element at some point it should be de-selected to release it.  (same for pens, brushes....)
dia_richAuthor Commented:
If handles were being consumed wouldn't that be shown in the task manager (I should have mentioned that this is on a XP box.)?  Because they aren't.
Updates that stop in a multithreaded application are frequently caused by cross-thread manipulation of a window.
For example, if you use SetWindowText() on the edit control, but call it from a worker thread, then that would be a cross-thread manipulation of a window, and should be avoided.  Basically, a rule of thumb is that you should not manipulate a window directly from any thread other than the thread that created the window.
Indirect manipulations are fine.  For example, one common resolution of the above is for the worker thread to PostMessage a user-defined message to the window's thread, wherein the the user-defined message contains enough information to locate the text that should be displayed.  Then, in the handler for the user-defined message, which will be executed in the thread context of the window, the text is located and SetWindwoText() is called from there.
dia_richAuthor Commented:
The worker threads put data into pipes and then set Messages which get processed.
I have a timer message processor which sets some the static text based on global variables and
the OnCtlColor to set background color for the text.  
Could the Message Pump be stalling?
AndyAinscowFreelance programmer / ConsultantCommented:
Resource handles.
When your app starts having problems do other apps also start having display problems, especially ones you then start.
Run your app until the display problems start.  Now without closing this app open winword, browser...  Do they work properly?  If yes then it probably is not related to resource handles.  However if they also behave oddly in display then it could be due to your consuming handles and not releasing them.
dia_richAuthor Commented:
Other apps seem to function & display properly.
dia_richAuthor Commented:
Running out of GIDs because I wasn't releasing objects created by CreateSolidBrush.
That is what I get for being a UNIX guy. . . .

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AndyAinscowFreelance programmer / ConsultantCommented:
Hmmm - it was not releasing resource handles then.
dia_richAuthor Commented:
I would have thought the same thing except when I watched the "handles" with task manager nothing
much was changing.
I had to use processes tab and then the view menu and then  select handles and GIDs
which added that column to the task manager. "handles" were constant.
GIDS (or rather GD GIDs) were counting up and up. . .  
GIDs are special case of "handles". Had to look in obscure places to track down what to look for and
then guess as to what object was being left on the heap. . .
Nothing I remember reading about for mfc objects warned about these special handles.
AndyAinscowFreelance programmer / ConsultantCommented:
I just know them as handles - in the early nineties I tracked a problem down which involved a third party app chewing up (resource) handles (on 16 bit windows where there were many less available) which caused the system to freeze after 30-40 minutes, first with things not drawing correctly then gradually grinding to a halt.

Maybe some terminology has changed.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.