Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GDI/GDI+ stop drawing after a while on Windows 7

68 views
Skip to first unread message

Bogdan

unread,
Dec 22, 2009, 10:25:04 AM12/22/09
to
I have an app that I developed some time ago for W2K. The app draws text
and graphics onto a CView derived window using GDI+. It also hosts
shockwave flash player that occasionally plays a clip in the same window.
The app could work 24x7 on W2K and XP.

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.

Quitting the app and restarting it fixes the problem (i.e. for another
couple of hours/days). So it is not a system wide failure.

I'm monitoring the most important resources (e.g. memory, handles, etc.) and
did not see any leaks. The app is not hung either. The app's timers and
worker threads are running when the app runs into the problem. I could also
bring up a dialog box belonging to the app and move it around without any
problems.

I realise that Windows 7 with its Direct3D Aero/WDM has to 'emulate' GDIs
but I'd rather expect some performance issues and not a complete and
undetectable failure like this.

Could anyone please give some ideas/pointers about how to troubleshoot this
one?

Thanks,
Bogdan


David Lowndes

unread,
Dec 22, 2009, 10:42:27 AM12/22/09
to
>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

Bogdan

unread,
Dec 22, 2009, 1:11:03 PM12/22/09
to

"David Lowndes" <Dav...@example.invalid> wrote in message
news:l2q1j5p315omuhsqn...@4ax.com...

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.

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


Tom Serface

unread,
Dec 22, 2009, 6:23:06 PM12/22/09
to
Hi Bogdan,

Did you try setting up the column for GDI resources in the Task Manager to
see if maybe something is leaking somewhere? You can set it up in the
options.

Tom

"Bogdan" <bog...@nocompany.com> wrote in message
news:OSvxmrxg...@TK2MSFTNGP02.phx.gbl...

David Lowndes

unread,
Dec 22, 2009, 6:57:59 PM12/22/09
to
>I tested the app with Basic and, as far as I remember, the performance was
>not acceptable. Does that make sense?

Ignoring any performance issues, does it fail in that mode?

Dave

Joseph M. Newcomer

unread,
Dec 22, 2009, 10:30:49 PM12/22/09
to
See below...

****
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: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Bogdan

unread,
Dec 23, 2009, 9:32:09 AM12/23/09
to
Joseph,

Thanks for the reply.

My application keeps track of resources (including GDI handles) and reports
them to a server via HTTP at a predefined frequency (currently set for 10
minutes). So, at any time I could get a snapshot of resource usage with the
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.
BTW, the app calls GetGuiResources() to get its usage of GDI handles.

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 a
corresponding error message is logged into a file. No errors are logged
when the app gets into trouble.

Thanks again,
Bogdan


"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:9c33j55sba8s2t7ik...@4ax.com...

Bogdan

unread,
Dec 23, 2009, 9:47:31 AM12/23/09
to
Tom,

Yes. I always have the 'extra' columns enabled - including handles,
threads, user objects, and gdi objects.

The app keeps track of GDI objects usage on its own by calling
GetGuiResources(). The count returned by the API agrees with what I see in
the Task Manager. Could not see any leaks - the count stays at 114.

And the fact that the app sometimes fails just after 2-3 hours and another
times after 3 or more days would suggest that this not a resource issues.

What is really frustrating in this case is that I have no way of detecting
it. I know that GDI+ calls are taking place (I have different levels of
logging in the app, including diagnostics, so I'm certain of it) and those
calls do not return any errors.

Also, the flash object that my app uses from time to time, does not report
any errors either. The area of the screen that the object is supposed to
update though, does not get updated.

Bogdan


"Tom Serface" <t...@camaswood.com> wrote in message
news:edue521g...@TK2MSFTNGP04.phx.gbl...

Bogdan

unread,
Dec 23, 2009, 9:54:30 AM12/23/09
to
I haven't tried it yet. I did not think it was worth trying because of the
performance.
I'll give it a try once the currently running test is finished.

Bogdan

"David Lowndes" <Dav...@example.invalid> wrote in message

news:m5n2j5lcsnb3sksl4...@4ax.com...

Tom Serface

unread,
Dec 23, 2009, 1:39:17 PM12/23/09
to
OK, it was worth mentioning, but sounds like you have that covered. I
wonder if you have any filters registered that could be the culprit. Are
you doing anything with DirectX/DirectShow?

If so maybe using a tool like:
http://msdn.microsoft.com/en-us/library/dd390950(VS.85).aspx on the content
would give you and idea of what is being called and you could try
unregistering some of them to see if that makes a difference. I know I'm
clutching for straws, but ...

Tom


"Bogdan" <bog...@nocompany.com> wrote in message

news:O8f5S79g...@TK2MSFTNGP02.phx.gbl...

Joseph M. Newcomer

unread,
Dec 23, 2009, 2:57:32 PM12/23/09
to
Sigh. Sounds like some problems with GDI+, or possibly that Flash control. Maybe you
could create a trivial little app that ran a Flash animation endlessly, and see if it
failed all on its own. That's the next thing I'd try if I were trying to figure this out.
Then I'd try the app but condition out the Flash animation and see if it failed.

It doesn't help that Microsoft treats professional systems like Win16 boxes and puts silly
limits on GDI resources (which are allocated globally, not per-process, so if I have 50
processes running, I run out of GDI resources, on a $%&! 4GB 2.8GHz quad processor! Give
me a break, people, this is a professional world with professional users with professional
demands for resources! It would not at all surprise me if they haven't fixed this
stupidity in Win7, or maybe even made it worse)
joe

Tom Serface

unread,
Dec 23, 2009, 10:25:05 PM12/23/09
to
I don't know about this particular issue, but I've found Windows 7 has fixed
a lot of issues I had with Vista. I'm happily updating my systems one by
one.

Tom

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message

news:5at4j5t8ang95os6f...@4ax.com...

Anders Dalvander

unread,
Jan 19, 2010, 10:54:29 AM1/19/10
to
On Dec 22 2009, 4:25 pm, "Bogdan" <bog...@nocompany.com> wrote:
> Could anyone please give some ideas/pointers about how to troubleshoot this
> one?
>
> Thanks,
> Bogdan

Hi Bogdan,

It has been some time since you last posted in this thread, but I hope
you or someone else stops by anyway.

I have similar problems as you, I have a working application which
works fine on Windows XP and Windows Vista, but when running it on
Windows 7 I get GDI leaks.

Did you find a solution to your problem?

Regards,
Anders Dalvander

Bogdan

unread,
Jan 19, 2010, 2:07:00 PM1/19/10
to

"Anders Dalvander" <goo...@dalvander.com> wrote in message
news:d8602dba-51dd-4b47...@p8g2000yqb.googlegroups.com...

I have not been able to find a working solution. I did however make some
progress by disabling on-board nvidia and putting in pcie ATI 44* Radeon. I
no longer experience any drawing related issues. But I'm not completely out
of the woods. The app now leaks about 30 MB of memory per hour! The same
app runs at ~75 MB of memory for weeks on XP and W2K. I think that Win7 is
not quite ready yet (hardware, drivers, decoders, etc.) to run 24x7. I hope
that hardware/drivers will mature soon on Win7 so we can retire XP.

Bogdan


Anders Dalvander

unread,
Feb 1, 2010, 7:19:04 AM2/1/10
to
On Jan 19, 8:07 pm, "Bogdan" <bog...@nocompany.com> wrote:
> I have not been able to find a working solution.  I did however make some
> progress by disabling on-board nvidia and putting in pcie ATI 44* Radeon.  I
> no longer experience any drawing related issues.  But I'm not completely out
> of the woods.  The app now leaks about 30 MB of memory per hour!  The same
> app runs at ~75  MB of memory for weeks on XP and W2K.  I think that Win7 is
> not quite ready yet (hardware, drivers, decoders, etc.) to run 24x7.  I hope
> that hardware/drivers will mature soon on Win7 so we can retire XP.
>
> Bogdan

I was successful in resolving my issue, it was due to a programming
error on my part. It appears that Windows 7 is stricter regarding
cleanup order than previous Windows versions, and we were releasing a
DC that had a GDI object selected. Tested a lot of GDI object counting
tools, and all of them reported different numbers, which is a bit
strange.

Regards,
Anders

0 new messages