I upgraded to Winform 2013.2 and changed my ribbon style to 2013 .. now I am seeing a new exception.
We have also moved to running our app on 2012R2 from 2008 not sure if that is related.
2013-12-11 12:37:16 PM : V1.0.0.617: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ComponentModel.Win32Exception: Error creating window handle. at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp) at System.Windows.Forms.Control.CreateHandle() at System.Windows.Forms.Form.CreateHandle() at System.Windows.Forms.Control.RecreateHandleCore() at System.Windows.Forms.Form.RecreateHandleCore() at System.Windows.Forms.Control.RecreateHandle() --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) at Infragistics.Win.UltraWinToolbars.UltraToolbarsManager.ForceRecreateHandle(Form control) at Infragistics.Win.UltraWinToolbars.UltraToolbarsManager.OnThemeChanged(Object sender, EventArgs e) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.UnsafeInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Delegate.DynamicInvokeImpl(Object[] args) at Infragistics.Win.WeakReferenceMulticastDelegate`1.WeakReferenceProxyEventHandler.OnEventFired(Object sender, EventArgsType e, Type delegateType) at Infragistics.Win.WeakReferenceMulticastDelegate`1.Invoke(Object sender, EventArgsType e) at Infragistics.Win.XPThemes.OnThemeChangeMessage(Object sender, EventArgs e) at Infragistics.Win.XPThemes.ThemeManagerWindow.OnThemeChanged(EventArgs e) at Infragistics.Win.XPThemes.ThemeManagerWindow.ThemeManagerNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
What you are asking for is impossible.
I'll try making a dump file and puzzling it out on my own.
Hello Greg,
It's important that we know what their environment is so that you can test your application and reproduce the behavior. Ultimately we will require a sample that can reproduce the behavior on our end so we can analyze this further.
She's on a remote desktop server. I can log into the same server and get the exact same environment.
I tried doing the same things as she was and can't reproduce the error and neither can she.
If I set it up to write a dump file next time would that help you?
Greg
It would be best to find out as much information you can regarding the user's environment who is reproducing this behavior. Then try and reproduce the behavior on your end.
1. I have no idea
2. No. Out of 100 users using the application all day long on a terminal server for 3 days, one user has had the error once.
3. Runtime
4. It's a ribbon on a form with a panel. Screenshot attached. I blanked out most of the form because of NDA but it is mostly textboxes, etc.
5. I am unable to create an isolated sample because the issue is happening so rarely.