Like Monika says, if you stop a virtual service, you lose everything.
Regardless of what DevTest does under the hood to support performance and Think Time features, the virtual service is thread-based. When you stop a service, a close connection signal is sent to running threads. Therefore, when you stop / re-start the service, there is no prior consumer thread on which to send a response.
To go a step further....
Assume that you have two services listening on the same port but having two different base paths.
/r1/example/{custId}
/r1/example/{custId}/{personId}
Assume that a request is sent that technically satisfies both base paths.
/r1/example/12345/abcd/getSomeData
The incoming request is actually sent to both services.
The first service that processes and sends the response is the winner. The second service's response is not sent.
This is a common mistake when teams run multiple services on the same endpoint port. It becomes confusing because sometimes you might get the response you were looking for and other times not.