1

I am quite puzzled how this is actually possible.

In my application (.NET framework 4.0) I have a "paste button". On application startup or when the focused object changes, I check the data in the clipboard to set the enabled state of that button.

Now it happend several times (on one machine) that this function seems to deadlock. Take a look at that stacktrace:

 at System.StubHelpers.InterfaceMarshaler.ConvertToManaged(IntPtr pUnk, IntPtr itfMT, IntPtr classMT, Int32 flags)
 at System.Windows.Forms.UnsafeNativeMethods.OleGetClipboard(IDataObject& data)
 at System.Windows.Forms.Clipboard.GetDataObject(Int32 retryTimes, Int32 retryDelay)
 at System.Windows.Forms.Clipboard.GetDataObject()
 at XXX.Forms.ClipboardHelper.<GetClipboardType>b__5()
 at XXX.DataProvider.Executor.Execute[TResult](Logger logger, LogLevel level, Func`1 action, Boolean throwUp, TResult defaultValue, String format, Object[] arguments)
 at XXX.DataProvider.Executor.Catch[TResult](Logger logger, LogLevel level, Func`1 action, TResult defaultValue, String format, Object[] arguments)
 at XXX.DataProvider.Executor.Catch[TResult](Logger logger, Func`1 action, TResult defaultValue, String format, Object[] arguments)
 at XXX.Forms.Ribbon.RibbonFormHelper.IsPasteButtonEnabled()
 at XXX.Forms.StartForm.XXX.Forms.IClipboardViewer.EnablePasteButton()
 at XXX.Forms.Ribbon.RibbonFormHelper.OrderOverview_FocusChangedEvent(Object sender, EventArgs e)
 at DevExpress.XtraVerticalGrid.VGridControlBase.ActivateEditor(RowValueInfo cell)
 at DevExpress.XtraVerticalGrid.NormalState.MouseDown(MouseEventArgs e)
 at DevExpress.XtraVerticalGrid.BaseHandler.MouseDown(MouseEventArgs e)
 at DevExpress.XtraVerticalGrid.VGridControlBase.OnMouseDown(MouseEventArgs e)
 at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
 at System.Windows.Forms.Control.WndProc(Message& m)
 at DevExpress.XtraEditors.Container.EditorContainer.WndProc(Message& m)
 at DevExpress.XtraVerticalGrid.VGridControlBase.WndProc(Message& m)
 at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
 at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
 at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
 at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
 at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
 at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
 at XXX.Program.Main(String[] args)

So even if I have a large amount of data in the clipboard it should finish eventually. I waited several minutes...

Now it works again but I'd still like to know what was going on!

toATwork
  • 1,335
  • 16
  • 34
  • *"when the focused object changes"* - you could use [clipboard event](http://stackoverflow.com/q/621577/1997232) instead. Before blaming clipboard, can you create and show us [mcve](https://stackoverflow.com/help/mcve)? Preferably without using DevExpress (see [this](https://www.devexpress.com/Support/Center/Question/Details/T447517)). – Sinatr May 12 '17 at 13:29
  • @Sinatr I cannot reproduce it myself anymore. I was lucky to get that call stack (serveral times, sometimes it occurs in the backgroundworker_completed, sometimes it occurs later on) – toATwork May 12 '17 at 13:41

1 Answers1

1

There is a bug in the WinForms version of the Clipboard class that I've seen cause this. In my case, using the WPF version of the Clipboard class (which has the same API) resolved the issue.

https://msdn.microsoft.com/en-us/library/system.windows.clipboard(v=vs.110).aspx

Jeff
  • 35,755
  • 15
  • 108
  • 220
  • both call the "OleGetClipBoard" on the "ole32.dll" but the System.Windows version has additional Attributes "SecurityCritical, SuppressUnmanagedCodeSecurity". I will check what those Attributes mean. – toATwork May 12 '17 at 15:32