The fact that it's so hard to reproduce and only happens on one user's machine is further evidence that this is, in fact, a threading issue. 

Threading issues are notorious difficult or impossible to reliably reproduce because they rely on arbitrary timing of the machine and the user.

The bug isn't easy to reproduce. We've just recreated the windows-profile of the user where the error occurs. We first want to ensure that this has any influence on the error. Till so far, the error remained away, but like I said, this happens +- once a week, so we may not jump to conclusions. If the error reoccurs, I will drop the filters to check this track.

Eddy De Schrijver said:

We don't apply any NotificationBadge. To be 100% sure I searched the source code for "notification" and for "badge" but no results. Do I have to search on something else?

Hm. Okay. The call stack of the exception ends with this: 

Infragistics.Win.Notifications.NotificationUIElement.AddNotificationUIElementIfPossible(UIElement parent, INotificationBadgeProvider notificationProvider)

I took a look at the code and this method gets called whether you are using NotificationBadges or not. It's the method that checks for them. The rest of the call stack shows that it's blowing up when trying to add an element into a HashSet. The hashset in this case is keeping track of all the elements that are currently being checked for NotificationBadges. It's essentially an anti-recursion flag. 

The beginning code  in this method looks like this

if (parentsInAddNotificationUIElementIfPossible.Contains(parent))
                return false;
            try
            {
                if (notificationProvider == null)
                    return false;

                parentsInAddNotificationUIElementIfPossible.Add(parent);

The first thing the code does is check to see if the element is already in the HashSet and only then does it add it to the HashSet. 

So the only way I can possibly imagine that an Exception could occur there is if there is a threading issue and this code is getting hit asynchronously from multiple threads.

The fact that it only happens on one machine is pretty typical of a threading issue. They tend to be very hard or impossible to reproduce and they rely heavily on exact timing with varies from machine to machine and user to user. 

Does removing either the draw or creation filters prevent the issue? Or does it persist without them?

Hi Mike! Sorry for the small image, I include a bigger one. It is indeed a tabcontrol with the tabs aligned to the left. 
I have implemented two filters: the draw filter (to remove the focus when selected) and the creation filter (to right align - euhm on the bottom - the last tab).
NavigationTabControl.DrawFilter = New NoFocusRectDrawFilter()
NavigationTabControl.CreationFilter = New RightTabAlignCreationFilter()

We don't apply any NotificationBadge. To be 100% sure I searched the source code for "notification" and for "badge" but no results. Do I have to search on something else?

I know that background threads can be tricky, but we only work with UI threads: we start all our application (application.run) in a different thread. There's no interaction between the threads - at least not intended. We are doing this for years without known issues. We recently migrated to 19.2 version and then the redcross error appeared. We found a workaround for the major one (the statusbar), but the one on the tabcontrol remained. At this moment the application is used by +-20 users, but before we roll out to all our customers, we want to be sure that this issue is solved. It's very strange that this occurs only by one user because the program is running on a central server (via remote desktop).