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 23 Dec 2009 14:57 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(a)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(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 > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on 23 Dec 2009 22:25 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(a)flounder.com> wrote in message news:5at4j5t8ang95os6flesoru3j5blp312hm(a)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(a)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(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 >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Anders Dalvander on 19 Jan 2010 10:54 On Dec 22 2009, 4:25 pm, "Bogdan" <bog...(a)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
From: Bogdan on 19 Jan 2010 14:07 "Anders Dalvander" <google(a)dalvander.com> wrote in message news:d8602dba-51dd-4b47-b73e-5da79b93887e(a)p8g2000yqb.googlegroups.com... On Dec 22 2009, 4:25 pm, "Bogdan" <bog...(a)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
From: Anders Dalvander on 1 Feb 2010 07:19
On Jan 19, 8:07 pm, "Bogdan" <bog...(a)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 |