title: "The operation completed successfully" exception
body: <p>I have a custom method that finds the largest size to use for a given string and font to fill a given box without cutting off the text.  To test it, I created a service that cycles through a few different strings and a few different fonts and does batches of them in a Parallel.For loop.  When this service is running, all the CPU cores on a system are at %90-%100.  After running for 8 or 9 hours, it will start throwing exceptions.  It will still work most of the time, but there will be the occasional exception or burst of exceptions.</p>
  
  <p>The innermost exception has the message "The operation completed successfully" and is originating from the WidthIncludingTrailingWhitespace accessor on a FormattedText object.  The call stack looks like this:</p>
  
  <pre><code>   at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
     at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
     at System.Windows.Threading.Dispatcher..ctor()
     at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
     at System.Windows.Media.TextFormatting.TextFormatter.FromCurrentDispatcher(TextFormattingMode textFormattingMode)
     at System.Windows.Media.FormattedText.LineEnumerator..ctor(FormattedText text)
     at System.Windows.Media.FormattedText.DrawAndCalculateMetrics(DrawingContext dc, Point drawingOffset, Boolean getBlackBoxMetrics)
     at System.Windows.Media.FormattedText.get_Metrics()
     at System.Windows.Media.FormattedText.get_WidthIncludingTrailingWhitespace()
     ...My Library Here...
  </code></pre>
  
  <p>In researching this, I found that undisposed drawing objects (Graphics, Icons, etc) are a common cause for this, but I could not find any Disposable objects in use.  The text sizing code uses WPF classes (FontFamily, FormattedText, and Typeface) and none of them implement IDisposable.</p>
  
  <p>I have perfmon monitoring the process and while memory use, handle count, and thread count do vary quite a bit, they never skyrocket out of control.  This tells me it probably isn't a handle leak.  What else could it be?</p>
  
  <p>UPDATE: I have been running the test for a few days now with one significant change: it is doing a regular for instead of a parallel for.  It hasn't crashed yet and perfmon shows horizontal lines with very little variance.  Perhaps this is an issue with parallelization and not WPF text rendering?</p>