GDI/GDI+ stop drawing after a while on Windows 7
in [MFC]
|
Prev: More Printing questions..... Merry Christmas
Next: Owner draw main windows, will left some drawing on the background of the window, I want the reason and how to prevent this happen?
From: Joseph M. Newcomer on 22 Dec 2009 22:30 See below... On Tue, 22 Dec 2009 13:11:03 -0500, "Bogdan" <bogdan(a)nocompany.com> wrote: > >"David Lowndes" <DavidL(a)example.invalid> wrote in message >news:l2q1j5p315omuhsqnhfrs8hfhnmphmpfd7(a)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(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Bogdan on 23 Dec 2009 09:32 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(a)flounder.com> wrote in message news:9c33j55sba8s2t7ikse2po3i6eg4g7qqeq(a)4ax.com... > See below... > On Tue, 22 Dec 2009 13:11:03 -0500, "Bogdan" <bogdan(a)nocompany.com> wrote: > >> >>"David Lowndes" <DavidL(a)example.invalid> wrote in message >>news:l2q1j5p315omuhsqnhfrs8hfhnmphmpfd7(a)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(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Bogdan on 23 Dec 2009 09:47 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(a)camaswood.com> wrote in message news:edue521gKHA.1824(a)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(a)nocompany.com> wrote in message > news:OSvxmrxgKHA.2160(a)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 >> >>
From: Bogdan on 23 Dec 2009 09:54 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(a)example.invalid> wrote in message news:m5n2j5lcsnb3sksl41a32pos535ov1rhpp(a)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
From: Tom Serface on 23 Dec 2009 13:39
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(a)nocompany.com> wrote in message news:O8f5S79gKHA.3888(a)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(a)camaswood.com> wrote in message > news:edue521gKHA.1824(a)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(a)nocompany.com> wrote in message >> news:OSvxmrxgKHA.2160(a)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 >>> >>> > > |