Reputation: 563
I am new to MFC & I am maintaining a MFC Application, Which has a CView Window GUI for displaying and manipulating values of a Tree using CTreeCtrl. All my functionality are working fine but sometimes I am getting a crash. But still I can not identify any pattern for reason of the crash.
Sometimes after some common action like changing values (which I have already performed like 100 times & just worked fine) ,the application hangs or crashes; sometimes for maximizing after 10-15 minutes is causing this .Sometimes the tree text are getting weirdly bold in size and then hangs/crashes. Checking Call stack is of no use till now as it always points to DbgCRT
or some internal MFC source files. It is an MDI application and I have noticed the crash happens when number of files are more or Current file has a large nested tree.
The main problem is I can not reproduce this bug at will. What I do is doing various actions with the tree like adding new nested branches, changing values & After 20-30 min of this crash may happen. Anyone please suggest any possible way of solution of this random occurring bug.
sample gui: http://postimg.org/image/6ed619voh/ "sample"
ADDITION: a snap after it was hanged : http://s7.postimg.org/dn216ufzf/crashtime_snap.png
Upvotes: 0
Views: 1628
Reputation: 6039
It sounds like you are leaking some kind of resource, most likely GDI handles. These can be hard to find - you have to check each use of controls (like the CTreeCtrl
, bitmaps, handles, etc.) to make sure you are properly releasing them at the proper time (MSFT docs are indispensable here).
One thing that can help is bringing up TaskManager in Windows and looking at the GDI objects column while you are interacting with your app. If the handle count just keeps climbing and your app logic says it shouldn't be, it gives you a place to start looking for problems.
The Visual Studio debugger will also give you clues to memory leaks. When shutting down your app (debug build), look in the output window. If you are leaking, the output window will have output that indicates a memory leak (something like: Detected memory leaks
followed by addresses and memory dump).
Also, run your build in the Visual Studio debugger (debug build). Sometimes there will be clues in the Output window at run-time as to leaks, memory overwrites, etc. PAY ATTENTION TO THESE. They offer valuable info. A clean program run will have no warnings, ASSERTIONS, leaks, etc. in the Output window.
If you have a place to upload your project (& not too huge), I will take a look at it for you.
Diligence and attention to detail is everything, here.
Hang in there!
Upvotes: 1