I tried to reproduce the problem. After modifying the execution configuration on several VIs like TcpServerBase.runServer.vi and others, I realized this way will complex the code too much, so I need more time to debug and find a solution for this bug. I will prioritize other tickets before continuing with this ticket. I will leave some notes here for my acknowledgment only and future changes:

I had to set the TcpServerBase.runServer.vi with Shared clone reentrant execution option selected, because reentrant VIs can only have dynamic dispatch terminals if they share clones between instances. After that, the run arrow broke, and the error message recommended to me: “you must either change the terminal in the connector pane to not be dynamic or edit VI Properties to modify the reentrancy behavior.” Then, when I set the Shared clone reentrant execution option, this message appeared: "You have changed priority, execution system, or reentrancy. These changes may break other implementations of this method in the hierarchy. Would you like to make all the implementations match the priority, execution system, and reentrancy of this VI?". I clicked yes. Now the arrow is solid.

TcpServerCmd.runServer.vi and TcpServerTel.runServer.vi inherited this property, except TcpServer.runServer.vi.

With this configuration, I can run two instances of TcpServer with different ports, and I can construct two connections from two TCP clients. However, I have problems with the GenRead user event sending generic user events when the connection is closed in any TCP Client. (End of my notes)

As the discussion, the TcpServer.runServer.vi and others should not be cloned because the user will do the clone at the higher level. Therefore, there should be something else wrong.

This week I’ve been working on this bug testing different configurations in the execution properties of TcpServer LabVIEW project. I found several forums and articles talking about reentrancy in LabVIEW classes. I found this forum on the lavag.org webpage, downloaded the code Test Shared Reentrancy.zip (attached in this ticket), and modified it. I found the followings: 

• In this example (Test Shared Reentrancy.lvproj) there is a parent class with two child classes, similar to TcpServer project.
• I created a new class to emulate the TcpServer class, and named it Class C.lvclass.
• I configured the parent and child classes as non-reentrant execution.
• I configured the Class C.Count.vi with shared clone reentrant execution.
• I created the Main2.vi to call two instances of Class C.Count.vi and they work as clones using independent memory space, as expected.
• Based on this, I only should configure the TcpServer.runServer.vi on TcpServer project with the shared clone reentrant execution, but this change is not enough according to my previous tests. I need to consider this Test Shared Reentrancy.lvproj is simpler than TcpServer code, and there is no shift register or similar if we compare it with the TcpServer code.
• LabVIEW has unpredictable behavior when you use classes, reentrant VIs, and shift registers, as this article mentions. It says “Avoid combining stateful VI’s [the one that stores data within itself from one call to the next. This is done in LabVIEW using shift registers and feedback nodes] with shared clone dynamic dispatch methods. Store the data between calls using another mechanism such as the class private data itself.”
• Te-Wei is right in suspecting the shift registers are causing the bug, even though those are initialized.
• I will continue debugging the TcpServer code supporting me with Rolando's experience in LabVIEW classes and reentrancy.