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

  • Follow


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


0
Reply Bogdan 12/22/2009 3:25:04 PM

>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
0
Reply David 12/22/2009 3:42:27 PM

"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.

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


0
Reply Bogdan 12/22/2009 6:11:03 PM

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" <bogdan@nocompany.com> wrote in message 
news:OSvxmrxgKHA.2160@TK2MSFTNGP02.phx.gbl...
> 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
>
> 
0
Reply Tom 12/22/2009 11:23:06 PM

>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
0
Reply David 12/22/2009 11:57:59 PM

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
0
Reply Joseph 12/23/2009 3:30:49 AM

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" <newcomer@flounder.com> wrote in message 
news:9c33j55sba8s2t7ikse2po3i6eg4g7qqeq@4ax.com...
> 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 


0
Reply Bogdan 12/23/2009 2:32:09 PM

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" <tom@camaswood.com> wrote in message 
news:edue521gKHA.1824@TK2MSFTNGP04.phx.gbl...
> 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" <bogdan@nocompany.com> wrote in message 
> news:OSvxmrxgKHA.2160@TK2MSFTNGP02.phx.gbl...
>> 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
>>
>> 


0
Reply Bogdan 12/23/2009 2:47:31 PM

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" <DavidL@example.invalid> wrote in message 
news:m5n2j5lcsnb3sksl41a32pos535ov1rhpp@4ax.com...
> >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 


0
Reply Bogdan 12/23/2009 2:54:30 PM

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" <bogdan@nocompany.com> wrote in message 
news:O8f5S79gKHA.3888@TK2MSFTNGP02.phx.gbl...
> 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" <tom@camaswood.com> wrote in message 
> news:edue521gKHA.1824@TK2MSFTNGP04.phx.gbl...
>> 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" <bogdan@nocompany.com> wrote in message 
>> news:OSvxmrxgKHA.2160@TK2MSFTNGP02.phx.gbl...
>>> 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
>>>
>>>
>
> 
0
Reply Tom 12/23/2009 6:39:17 PM

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

On Wed, 23 Dec 2009 09:32:09 -0500, "Bogdan" <bogdan@nocompany.com> wrote:

>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" <newcomer@flounder.com> wrote in message 
>news:9c33j55sba8s2t7ikse2po3i6eg4g7qqeq@4ax.com...
>> 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 
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
Reply Joseph 12/23/2009 7:57:32 PM

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" <newcomer@flounder.com> wrote in message 
news:5at4j5t8ang95os6flesoru3j5blp312hm@4ax.com...
> 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
>
> On Wed, 23 Dec 2009 09:32:09 -0500, "Bogdan" <bogdan@nocompany.com> wrote:
>
>>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" <newcomer@flounder.com> wrote in message
>>news:9c33j55sba8s2t7ikse2po3i6eg4g7qqeq@4ax.com...
>>> 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
>>
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm 

0
Reply Tom 12/24/2009 3:25:05 AM

On Dec 22 2009, 4:25=A0pm, "Bogdan" <bog...@nocompany.com> wrote:
> Could anyone please give some ideas/pointers about how to troubleshoot th=
is
> 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
0
Reply Anders 1/19/2010 3:54:29 PM

"Anders Dalvander" <google@dalvander.com> wrote in message 
news:d8602dba-51dd-4b47-b73e-5da79b93887e@p8g2000yqb.googlegroups.com...
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

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


0
Reply Bogdan 1/19/2010 7:07:00 PM

On Jan 19, 8:07=A0pm, "Bogdan" <bog...@nocompany.com> wrote:
> I have not been able to find a working solution. =A0I did however make so=
me
> progress by disabling on-board nvidia and putting in pcie ATI 44* Radeon.=
 =A0I
> no longer experience any drawing related issues. =A0But I'm not completel=
y out
> of the woods. =A0The app now leaks about 30 MB of memory per hour! =A0The=
 same
> app runs at ~75 =A0MB of memory for weeks on XP and W2K. =A0I think that =
Win7 is
> not quite ready yet (hardware, drivers, decoders, etc.) to run 24x7. =A0I=
 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
Reply Anders 2/1/2010 12:19:04 PM

14 Replies
709 Views

(page loaded in 0.358 seconds)


Reply: