New article
Recently updated
Pentana Audit: connection fails, “A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe” is logged
This message can be logged in the following circumstance:
- The Pentana Audit application server is restarted
- While the server is restarting, the SQL Server service is also in the process of starting up
While this can occur where the application and database are on separate servers, normally this will happen where they are on a shared server:
- As the server starts, the Windows services with a Startup type of Automatic are started, so SQL Server and the Robot service start at the same time
- The Robot service connects to the Pentana Audit application service
- The application service attempts to log into the database
- However, SQL Server is not yet completely started up, and so:
- The error is logged
- The Robot quits
- Users may not be able to start their Pentana Audit application successfully
You will see the following sequence of events logged:
- In Event Viewer on the server, the System log will show Event ID 6005 as the server starts
- In the Robot service log, you may see the following errors shortly afterwards:
MessageQueueException - Message: Message Queue service is not available
Win32Exception - Message: The requested security package does not exist
ArgumentException - Message: TypeStore found no EntityType for the mid, RobotJobHistory
- In PentanaTngService.log, the following will appear shortly after that:
SqlException - Message: A connection was successfully established with the server,
but then an error occurred during the pre-login handshake.
(provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)
Solution
To clear the problem, assuming the SQL Server is back up and running successfully:
- Restart the Pentana Audit application pools
- Restart the Robot service
If the Robot service starts without error then the system has restarted successfully.
Prevention
In order to minimise risk of this happening on a shared server, change the Startup type of the Robot service to Automatic (Delayed Start). This will normally ensure that SQL Server has started up before the Robot service attempts its start.