minutes). So, at any time I could get a snapshot of resource usage with
max delay of 10 minutes.
I have not seen any leaks. For example handle count stays around 800, GDI
objects: 114, and user objects: 76.
Most of the drawing is done in GDI+. GDI+ API return codes (e.g. Ok means
success). The app checks the return codes and if Ok is not returned then
corresponding error message is logged into a file. No errors are logged
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Tue, 22 Dec 2009 13:11:03 -0500, "Bogdan" <bogdan@nocompany.com>
wrote:
"David Lowndes" <DavidL@example.invalid> wrote in message
news:l2q1j5p315omuhsqnhfrs8hfhnmphmpfd7@4ax.com...
I'm now testing the app on Windows 7 Home Premium. I'm running into
a
strange problem. After running it for a while - sometimes it could be
a
couple of hours, another times a couple of days - the app simply stops
drawing to the screen. That is, the app still calls the necessary
APIs
but
nothing happens on the screen.
I'm logging the most important calls to a file with their return codes
and
there are no errors reported whatsoever. In addition, the shockwave
object
is not displaying anything either and does not report any errors.
Bogdan,
Have you tried it on a couple of different W7 machine - i.e. one with
Nvidia and one ATI graphics? Have you tried it with Aero and with
Basic?
Your symptoms do sound similar to running out of resources, but as you
say you can't see any obvious leaks, then a graphics driver quirk may
be the issue!
Dave
Dave,
Thanks for the reply. I currently have only 2 Windows 7 machines
available
for testing and [unfortunately] they are identical. I'm running a
different
test on the second one. I'm going to set it up for the problematic test
this afternoon and see if it behaves differently.
And, as you suggested, I'll try a different graphics card. Both of the
Windows 7 machines use an on-board Nvidia.
This is a nasty problem for apps that need to run 24x7. There seem to
be
no
way to detect the failure.
****
First, you need to look at all those graphics calls that do drawing. If
you are losing
information, you can either do something like
VERIFY(dc.LineTo(...));
VERIFY(dc.TextOut(...));
or
if(!dc.LineTo(...))
LogFailure(_T("LineTo"), _T(__FILE__), __LINE__);
if(!dc.TextOut(...))
LogFailure(_T("TextOut"), _T(__FILE__), __LINE__);
or do something like
#define logLineTo(L, T, R, B) if(!dc.Lineto(L, T, R, B))
LogFailure(...etc...)
but you have not told us what you are examining or logging, so we have
no
way to tell.
Use the sysinternals (www.sysinternals.com) Process Explorer to see what
your GDI handle
usage is. Have it monitor the app and watch if it grows. Use the
Application Verifier to
see if you have a handle leak, and where.
These are the first things I would try.
joe
****
You say you log return code values, but in the absence of any details of
WHAT return codes
you save there is no way to tell what you are doing.
One additional piece of info that I did not mention in my initial
post...
The app also plays mpeg, mp4, or wmv clips in a window using DirectShow.
The playback of these files never fails. The app works fine with VMR7
(DirectDraw), VMR9 (Direct3D), and EVR renderers.
For example, if GDIs fail the DirectShow keeps rendering fine for
another
day or longer.
And as I mentioned, I keep track of threads, user objects, GDI objects,
handles, memory, etc. No obvious leaks there.
I tested the app with Basic and, as far as I remember, the performance
was
not acceptable. Does that make sense?
I'll go through the testing and post the results here.
In the meantime, if you or anyone else has an idea what else I can do
I'd
greatly appreciate it.
Thanks,
Bogdan
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm