"Status 3006 is typically a secondary error, caused after a network failure drops the connection. This is common if the PC is not being used for a long time, goes to sleep (or puts the NIC to sleep), and when it wakes up, the server thinks the client is long gone. Sometimes this can be addressed by enabling Auto-Reconnect on the Server and PSQL Client, but not always. You may have to disable power management on the PC (or set to high performance) instead.

Another possible issue is with some PC's (especially from Dell) and RealTek network cards. Microsoft released a faulty driver for various versions of Windows for the RealTek NICs, and I have seen these cards cause endless problems with exactly the symptoms you mention. Swap out the NIC or upgrade the driver to one from RealTek's web site, and this problem goes away.

It might be helpful to confirm the exact exception, too. Check the Windows Event log and post the complete message you see from the software exception. The exception type, module, and location may be beneficial in determining what is going on.

If all else fails, monitoring a PC's connection with Wireshark can yield information about what is truely happening under the covers…."

"We have enabled Auto Reconnect option both on the server and client side.

The exact exception that we get is "External exception C0000006". In the Pervasive database server log "C:\ProgramData\Actian\PSQL\logs\pvsw.log" we see the following session timeout errors which are repeating for each client PC …"

Ahh – the dreadded "In-Page I/O Error"! This error appears when an application EXE file or DLL is loaded across a network connection, but the network connection is lost (or disconnected) and cannot be re-established when the application attempts to read more data from the EXE/DLL file.

I am afraid to tell you that this is a common Windows issue, usually caused by network outages. Your search through the Windows Event Logs must have missed it – every InPage I/O Error is logged by the OS there! Were you looking on the workstations or on the server?

I have seen a few possible causes of this type of outage:

1) Power Saving Mode kicking in on the client or server, limiting network traffic. This is indicated if the problems happen after a computer is idle for a time period.

2) Extremely busy network traffic on a LAN segment, preventing communications for a long period of time. (With PARC disabled, 10-15 seconds is enough – with PARC enabled, though it should take 3 minutes.) This can happen at any time, but especially while backups are running.

3) Suspension of a virtual machine, due to either backup via an external tool (e.g. Veeam) or vMotion (which can also cause a LAN overload). This can also happen any time, especially on VM environments.

4) Failing DHCP renewals. This can happen with a short DHCP lease and a renewal process that is not working. The Windows Event Logs should ALSO indicate that the IP address has been released, and if it takes more than 10 seconds to renew, all hel1 breaks loose. This can easily be seen if you monitor a problem workstation via a network analyzer – you can actually see the DHCP renewals returning NAK and the IP address getting freed up, killing EVERY TCP connection, including both the database AND the windows sessions.

5) Windows Sessions getting disconnected. You can disable the Windows SMB disconnect via registry settings (search the web for "0xC0000006" and you'll get solutions there. Clearly the sessions are getting disconnected.

While you can eliminate the InPage I/O Error by moving the application locally, the loss of the TCP connection for the database cannot be fixed. I would start by capturing a network trace (with Wireshark) on a workstation experiencing the problem, and you should see EXACTLY what is happening when the failure appears.