Generic GDI error

When using Terminal Services, SandRibbon often throws a GDI error:

System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+.
at System.Drawing.Graphics.Clear(Color color)
at Divelements.SandRibbon.RibbonForm.OnPaintBackground(PaintEventArgs e)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at Divelements.SandRibbon.RibbonForm.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I can't consistantly reproduce it, but your best bet is to try running a SandRibbon application under Remote Desktop. Then, minimize and maximize the RDP window. This seems to be at least partly connected to a framework bug (see bug #96873 in the .NET Feedback center on Connect), but the net result is that SandRibbon is essentially useless under Terminal Services.

Hardware and software platforms are mixed, although the latest version of SandGrid and the framework are installed everywhere.

The error also occurs when you have the SandRibbon designer open in VS.

That is interesting. I am not aware of any circumstances under which Graphics.Clear can fail. Obviously, nearly every control calls Graphics.Clear at the beginning of its paint cycle.

I do not wish to start wrapping every call to that method in a try block, so will await word from Microsoft on that bug and potential workarounds.

I'm surprised I haven't heard way more people complaining about this yet.

Any chance you could reconsider your decision? Microsoft has declared that although this is a bug in GDI+ (see http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=96873), they will not fix it. This means that, in my experience, any application that uses a RibbonForm cannot be used over Remote Desktop (even if the exception is handled, the form is not drawn properly until the application restarts).

It seems to be the Graphics.Clear call in RibbonForm.OnPaintBackground that causes the exception (although I don't know if this would be the only cause).

Out of curiosity, can you reproduce this? Has anyone else seen the same problem? Workarounds? Any way to 'reset' the form rendering?

No, I've never personally seen this and I use SandRibbon through remote desktop a fair bit.

Out of interest, what exactly would you suggest that we do? It doesn't get any more basic than calling Graphics.Clear at the beginning of your paint cycle. It has only one parameter, a color, and it's impossible to have an invalid color.

We haven't heard of anyone else experiencing the issue, either, which does suggest it depends on a certain machine configuration.

Are you running an ATI Rage (XL) graphics chip on your server (i.e. the box you're connecting to)? I've had issues with that chipset before throwing strange graphics bugs when using MS's driver for it and then different bugs when using ATI's driver for it.

Well, I'm surprised. I can reproduce this pretty consistantly on all configurations I've tried. I haven't tried on Rage hardware, but I have on Radeon.

The only thing I can think of to fix this would be to wrap each Paint event's code in a Try block, and when this particular exception is thrown, ignore it. This might make sense either way, since any unhandled exception that occurs in a Paint event is a particuarly bad thing. I could be wrong here, but there's not really much of a performance hit from using a Try block unless an exception is actually thrown, right?

That said, I fully understand if this isn't doable; I don't expect you to make such a change based on one bug report you can't reproduce.

The weird thing is that Microsoft is entirely aware of the problem, knows it is impacting customers, and refuses to fix it. I don't mean they can't get a fix for this particular bug in to the next release, I mean the entire team responsible for GDI+ is not taking any more bugfixes whatsoever.

Which sucks.

The feedback on MS's site will show that there are thousands of GDI+ bugs where they throw strange exceptions in unexceptional cases. The thing is: they are fixed. You just have to use .NET 3.0 (WPF) to get the fixes. That is why they refuse to fix any .NET 2.0 GDI+ issues -- they want GDI+ to just go away. The sooner we can get WPF controls from Divelements, the better.

WPF controls are being worked on.

In the meantime, it is correct to say that any error in GDI+ has virtually zero chance of being fixed. The GDI+ team were disbanded many years ago.

I am also getting this error in my application and it does seem to happen when I use Remote Desktop to check on my running application. (Yes, I'm lazy and do not want to walk down to the basement where my "big" computer is running.)

I have attached a screenshot of the error.
I am running a debug version of my application because I am still working out the bugs. The application basically runs all day collecting stock market data and will eventually trade stocks without my assistance while at work. Hence Debug mode so that I can check for crashes and blowups while I was away.

Hi,

We are getting the same error, it appears to happen after a long period of the SandRibbon showing (the machine was not accessed via Terminal Services).

Any clues?

thanks

dan

Hi,
I get the sam error.
After testing my app over remote desktop connection I get this error from Clear method.

I am bumping this thread to point it is very important issue. Could you just try to add try/catch blok on this and maybe all will be fine?

Wrapping all code within a paint operation in a try/catch is a pretty bad idea. I don't want to do this in the product. Remember, you could always do this yourself. All you need to do is override OnPaint and call the base method inside a try/catch block.

Generic GDI+ error is caused by GDI+ engine when drawing on disconnected secured canvas (like in case with TerminalServices & RemoteDesktop).

It's easy to reproduce, you just need to keep RemoteDesktop window minimized for 15 minutes...

Microsoft said that it's by design and they will not fix it in GDI+. So the only possible solution if wrap a paint operation in try/catch block.

 

 

(to update this very old thread that has been resurrected)

Microsoft have indeed confirmed this will never be fixed, and we have code in all our products to catch and silently swallow the exception.

I have version 1.6.1.1.  I am experiencing this issue, with Terminal services (Remote Desktop).  May I get a fix without having to buy an upgrade?