Hi DataMiners!
Below is an issue that is observed when trying to access Cube. Has anyone seen a similar issue?
Cube logging shows the following message:
CubeVersionNumber = 10.5.2509.3170-0e5ecfec;
----------- LogID: 109 -----------
Warning
ServerTime: 5/14/2025 1:28:01 PM
ClientTime: 5/14/2025 1:28:02 PM
Grouped 11 times in 10 seconds
Message : Exception in
Exception : System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Skyline.DataMiner.Net.Search.BucketSearchIndexEntries.RemoveGarbage()
at Skyline.DataMiner.Net.Search.SearchIndex.<>c__DisplayClass4_0.<AddEntries>b__0(ValueTuple`2 entry)
at System.Threading.Tasks.Parallel.<>c__DisplayClass31_0`2.<ForEachWorker>b__0(Int32 i)
at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Parallel.ForWorker[TLocal](Int32 fromInclusive, Int32 toExclusive, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Func`4 bodyWithLocal, Func`1 localInit, Action`1 localFinally)
at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally)
at System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, Action`1 body)
at Skyline.DataMiner.Net.Search.SearchIndex.AddEntries(MapSearchIndexEntries newEntries, TaxonomyNode nodeToClear, Boolean skipRemoveGarbage)
at Skyline.DataMiner.Client.Framework.Components.SearchManager.IndexElement(LiteElementInfoEvent eim)
at Skyline.DataMiner.Client.Framework.Components.SearchManager.HandleQueuedUpdate(Object item)
---> (Inner Exception #0) System.NullReferenceException: Object reference not set to an instance of an object.
at Skyline.DataMiner.Net.Search.BucketSearchIndexEntries.RemoveGarbage()
at Skyline.DataMiner.Net.Search.SearchIndex.<>c__DisplayClass4_0.<AddEntries>b__0(ValueTuple`2 entry)
at System.Threading.Tasks.Parallel.<>c__DisplayClass31_0`2.<ForEachWorker>b__0(Int32 i)
at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )<---


Hi Pieter – thank you for your feedback. DCP269834 was initially created to keep track of this inquiry.

ok great, we'll take it from there. thx
Hi Zain,
Whilst I have not encountered this before. The callstack does provide some useful info.
The line "Skyline.DataMiner.Client.Framework.Components.SearchManager.IndexElement(LiteElementInfoEvent eim)" tells us that when cube tries to process an elementInfoEvent for the search-bar. A null is encountered, which leads to the crash. In short this is a bug in cube we will need to investigate (If you can take dumps of the process when it crashes, that would be useful, if not not worries).
To avoid encountering this, you can disable the indexing feature (the searchbar might stop working, but at least cube will remain operational). To do this:
- Open cube
- Go to System Center->Search&Indexing
- Uncheck "Client Search"
- Click "Apply"
This will apply to all users, so you only need to do it from one client.
Alternatively you could only disable the element indexing with the following steps (although other events may trigger the same issue):
- connect to the server using client test tool.
- Click on advanced->Options->SLNet Options
- In the dropdown select SearchOptions
- On every agent add ";excludeelements"

Hi Brent,
Thank you for the feedback — the information you shared is very helpful. We'll proceed with additional testing based on this and take it from there.
One thing to highlight: for the user, the indexing feature is critical, as it’s used daily for searching elements and other key tasks. Because of that, disabling indexing may not be a viable long-term solution. Just for your reference, we also have DCP269834 open for this issue. Any new findings, I'll be sure to add it here.
Might be good to have this investigated via a support ticket, as it seems like there is some corruption in one of your elements. Disabling the indexing might allow you to proceed and login, but it's not a healthy situation. Thx