0

We have a WPF application using Prism 6.0 which have different screens that show collections. Many of these views are loaded in the startup and shown as necessary.

Sporadically, we are getting an exception in the startup. The exception call-stack does not give any useful information (except that it is a cross thread collection access issue) and we are finding it difficult to find the root cause. The exception is as below

at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at System.Collections.Generic.List`1.get_Item(Int32 index)
at System.Collections.ObjectModel.Collection`1.get_Item(Int32 index)
at System.Collections.ObjectModel.ReadOnlyCollection`1.System.Collections.ICollection.CopyTo(Array array, Int32 index)
at System.Collections.ArrayList.InsertRange(Int32 index, ICollection c)
at System.Collections.ArrayList.AddRange(ICollection c)
at System.Collections.ArrayList..ctor(ICollection c)
at System.Windows.Data.ListCollectionView.<RefreshOverride>b__1_0()
at MS.Internal.Data.SynchronizationInfo.AccessCollection(IEnumerable collection, Action accessMethod, Boolean writeAccess)
at System.Windows.Data.BindingOperations.AccessCollection(IEnumerable collection, Action accessMethod, Boolean writeAccess)
at System.Windows.Data.ListCollectionView.RefreshOverride()
at System.Windows.Data.CollectionView.RefreshInternal()
at System.Windows.Data.CollectionView.RefreshOrDefer()
at System.Windows.Data.ListCollectionView.ProcessCollectionChanged(NotifyCollectionChangedEventArgs args)
at System.Windows.Data.CollectionView.ProcessChangeLog(ArrayList changeLog, Boolean processAll)
at System.Windows.Data.CollectionView.ProcessInvoke(Object arg)
at MS.Internal.Data.DataBindOperation.Invoke()
at MS.Internal.Data.DataBindEngine.ProcessCrossThreadRequests()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Is there any way to which collection (at least the type of collection elements) is causing this issue or any way to find the root cause?

Any ideas are welcome!

thank you

Pramod B R
  • 612
  • 6
  • 7

1 Answers1

-2

This exception is usually thrown when the index used to access the collection is less than zero or equal to or greater than the collection's Count.

A cross-thread exception would usually be of type NotSupportedException.

You must ensure that the index is within the range.

To find the exact location you must go to the Debug menu and enable the debugger to break on all exceptions and then run you application in debug mode:

  1. Press Ctrl+Alt+E and tick the "Common Language Runtime Exceptions" check box
  2. Run in debug mode to make the program halt at the line of origin (in case of proper exception handling)

From your exception message it looks like the stack trace is generated from a release build.
In this case make sure you publish the PDB files too (debug symbols). This will allow the exception stack trace to include line numbers.

Another option is to review all your index based collection access (read) and guard against an index out of range (it should be standard in production code). You could use the occasion to do this for index based write access too. You can use the search tool to locate indexers in your solution.

Even if you include PDB files or use the debug mode to identify the line of origin, you should consider to review your code base for other brittle index based collection access with the help of the search tool. And maybe add a rule to your coding guide to force developers to check the collection bounds before accessing it by index.

BionicCode
  • 1
  • 4
  • 28
  • 44
  • This issue is not reproducible when running the IDE. And it is not possible to do a remote debug either. What I am looking for is a way to get information from a deployed application . I have already put all checks where any collection is accessed by index. This issue seems to happen from the framework/WPF code. – Pramod B R Jul 06 '22 at 07:37
  • Yes it's likely framework code indicated by the ThrowHelper, unless you use this helper too. But it's related to collection access which is triggered by using its API. The collection doesn't throw on its own. It's either indexed based read access or initialization e.g., by passing a collection to the collection's constructor (which for example could be NULL, which would cause a similar exception). It's difficult to identify the issue if you don't have any logs that show the current state of the application or an instruction trace the moment it crashes. – BionicCode Jul 06 '22 at 08:57
  • You can ask the consumer to reproduce the error and then ask him to describe *exactly* what he has done. Maybe ask him to record his GUI interaction using a screen capture tool. This will allow you to identify the component and maybe even the exact operations involved. Otherwise you have no chance except for reviewing your code and trying hard to reproduce the issue. You can also blindly refactor the related component hoping to eliminate the error source this way. – BionicCode Jul 06 '22 at 08:57
  • Or deploy a new version that includes PDB files and additional logging and ship it to the customer that has reported the issues. Then next time you will get the exact line of origin from the stack trace. – BionicCode Jul 06 '22 at 08:59