We are still facing the "Parameter is not valid." from time-to-time

… at System.Drawing.Graphics.GetHdc()

Just as I described above.  The real annoyance is that if you google this error outside the context of Infragistics, there are often some "legitimate" reasons for the error.  It can happen, for example, if you run out of GDI objects in certain extreme situations.

… but in the context of the Infragistics winforms code, the meaning of the error becomes a lot less certain.  It has nothing to do with GDI resources, nor does it have a legitimate root cause.  It seems to be an Infragistics logic bug rather than a GDI bug.  for example here is a callstack:

Stack trace:    at System.Drawing.Graphics.GetHdc()
   at Infragistics.Win.FormattedLinkLabel.PositionElementsCache.MeasureTextGDIOrThemed(String text, Font font, TextFormatFlags textFormatFlags)
   at Infragistics.Win.FormattedLinkLabel.PositionElementsCache.MeasureCharacterRangesGDI(String text, Font font, TextFormatFlags textFormatFlags, CharacterRange[] ranges)
   at Infragistics.Win.FormattedLinkLabel.PositionElementsCache.ReMeasureParts(String text, Int32[] parts, Single[] widths, Int32 partStartIndex, Int32 partEndIndex, Font font, Single& lineHeight)
   at Infragistics.Win.FormattedLinkLabel.PositionElementsCache.MeasureParts(String text, Int32[] parts, Font font, Single& lineHeight)
   at Infragistics.Win.FormattedLinkLabel.NodeText.TextLayoutInfo.Measure(PositionElementsInfo& info)
   at Infragistics.Win.FormattedLinkLabel.NodeText.PositionSelf(PositionElementsInfo& info)
   at Infragistics.Win.FormattedLinkLabel.NodeBase.PositionHelper(PositionElementsInfo& info)
   at Infragistics.Win.FormattedLinkLabel.NodeBase.PositionChildNodes(PositionElementsInfo& info)
   at Infragistics.Win.FormattedLinkLabel.NodeBlock.PositionChildNodes(PositionElementsInfo& info)
   at Infragistics.Win.FormattedLinkLabel.NodeBase.CalcSize(IFormattedLinkLabelOwner owner, Graphics graphics, Int32 maxWidth)
   at Infragistics.Win.UltraWinToolbars.Ribbon.RibbonMetrics.CalculateCaptionAreaHeight()

That stack is telling me that the bug is relate to the ribbon, on a UltraWinToolbar, and that the ribbon cannot calculate it's area.

While calculating the area, it is trying to measure the size of a "FormattedLinkLabel", and that is making use of a "PositionElementsCache".  I suspect failures are a result of a poor caching strategy within the Infragistics winforms controls.

Another thing that makes the bug frustrating is that it isn't consistent.  I can have twenty users who never see it, and one who gets it all the time.  Even though they are doing the exact same things.

I did some research and found a couple other anecdotes about people having the same problem:

• https://www.infragistics.com/community/forums/f/ultimate-ui-for-windows-forms/41053/random-crashes-in-ultrawintoolbars-system-argumentexception-parameter-is-not-valid/

After much teeth-gnashing I found somewhere (can't remember where) that setting the IsGlassSupported property on the UltraToolbarsManager to False solved the problem. It certainly worked for me.

• https://www.infragistics.com/community/forums/f/ultimate-ui-for-windows-forms/90657/parameter-is-not-valid

We put the change to remove the IsGlassSupported for the ribbon and have no reported crashes in over a week of customer use.

So to make a long story short, it seems that the problem is not unique to me, and others have struggled as well.  The workaround is extremely obscure (IsGlassSupported to false) and I don't understand why Infragistics doesn't improve this situation in one of their winforms releases.  It would take far less time to do something on your end than to leave customers to fend for themselves and try discovering the workaround.  Here are my suggestions:

• Fix the bug (in the "glass" feature or whatever)
• Catch the exception ("Parameter is not valid." ) and own-up to it, and then re-throw it.  Change it from a system-generated argument-exception to a PositionElementsCacheChokedException so it is clear that the problem is with IG, and not with the win32 GDI resources.  The failure is not in the underlying GDI system but in the custom logic of the Infragistics components.
• Suggest a fix in the exception error message.  If the problem is not going to be fixed and customers will be encountering it forever, and you can detect the conditions of the problem (GlassSupport) then the message should help lead the developer to the workaround ie.  "Cache failure.  Have you tried disabling Glass Support?"

Hope one of these things sounds reasonable.

We use 16.1.20161.2141 (for both winforms and wpf).

It appears that there may be a history behind this error and it was "fixed" in a service release several years ago.  Are there any outstanding/known issues that would produce the same exception?