3

We have code that is producing the following unhandled exception:

Error Message: System.Reflection.TargetParameterCountException: Parameter count mismatch.

at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

at System.Delegate.DynamicInvokeImpl(Object[] args)

at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)

at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler). Stack Trace: System.Reflection.TargetParameterCountException: Parameter count mismatch.

at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

at System.Delegate.DynamicInvokeImpl(Object[] args)

at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)

at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler).

We know when this happens. We are adding an item to an ObservableCollection that is bound to by the UI. However, we're at a loss to explain WHY this happens, or HOW to fix it, given that the error only happens rarely. Since its a sporadic issue, its not likely to be some kind of typo in the Bindings or the DataTemplates, as those would be expected to go wrong 'every' time. Nowhere in our code do we use Reflection or anything that would be expected to invoke parameters at run-time; the exception must be referring to some internal classes from Microsoft. Further, the stack trace only contains Microsoft code; we've been unable to find any documentation for many of the classes in the stack trace itself (i.e., System.Windows.Threading.ExceptionWrapper). How can we debug this kind of error? Is there a way to put breakpoints of some sort inside these internal Microsoft classes so that we can see what sorts of inputs are triggering this behaviour?

Community
  • 1
  • 1
GWLlosa
  • 23,995
  • 17
  • 79
  • 116
  • One thing to check: are you making sure to only access the ObservableCollection on the UI thread? ObservableCollection notifications are not thread-safe, even if you lock access to the collection. – Dan Bryant Dec 02 '11 at 19:58
  • Wouldn't we get a rather specific illegal cross-thread exception in that case? – GWLlosa Dec 02 '11 at 20:02
  • @GWLIosa, possibly if you have that particular managed debugging assistant enabled. Even then, I'm not sure if the binding system for ObservableCollection is covered by that assistant (it was originally built for WinForms to detect Control property access from non-UI threads.) I just mentioned it as it may be easy to check and any time I encounter intermittent failures, my first suspect is a threading race condition. – Dan Bryant Dec 02 '11 at 20:07
  • Please post the code where you you suspect it is dying. And you did not answer the question from Dan Bryant. Are you updating the ObservableCollection on a thread other than the thread that owns the UI? From experience you will get intermediate errors and possibly not a meaningful error messages. It is up to a thread to ask if it owns the UI. If it does not ask and tries sometimes a background thread succsessfully updates the UI. If you are updating any UI source on a thread other than the thread that owns the UI try using a BackgroundWorker – paparazzo Dec 02 '11 at 20:45

1 Answers1

1

You may be able to determine what was going on when the app died by capturing a crash dump.

Check this question out for more info

How do I obtain a crash dump

Community
  • 1
  • 1
John Sobolewski
  • 4,512
  • 1
  • 20
  • 26
  • We have a pretty good idea of what the app was 'up to' when it died/dies; the problem is we can't figure out why that would cause it to die. We have the stack trace that from the crash (featured in the question) we just 'lose' the trace at some point, I guess. – GWLlosa Dec 02 '11 at 20:03
  • 1
    with the dump you should be able to get the state of various objects at the time of the crash which might help you figure out why it crashed – John Sobolewski Dec 02 '11 at 20:11
  • Got it; it turns out a 3rd party drawing control dies when certain things (which it shouldn't really care about) are null, which can legitimately happen from time to time ): – GWLlosa Dec 04 '11 at 17:35