You find that the sp_ctrl is hung in Windows environment though the replication is working fine as evident from the messages moving from source to target.
The corrupt services file is responsible at times for this behavior
The issue has been known to be resolved at times by stopping the sp_cop services for that port (since sp_ctrl is no longer functional) and then renaming the services file prior to relaunching the sp_cop and sp_ctrl.
The services file keeps a record of the state of a Shareplex child process (if other than the default) so that when the Shareplex is shutdown and then subsequently restarted, the process remains in that state. For example, if a process is shutdown or errors out, then after Shareplex is shutdown and then restarted, the process will be in the state of "stopped" or "stopped due to error" depending on its state prior to the last shutdown. When renaming the services file, this can result in the loss of that information and consequently when Shareplex is brought up, all the processes will start. Sometimes that may be undesired as you may want to keep certain process in a stopped state but this is a small price to pay for getting the replication back to normal.
