If VPOP3 is not starting properly, then the first thing to check is whether the database server is starting. In VPOP3 v3 and later, VPOP3 uses a PostgreSQL Database server for data storage, so if the database server is not running, VPOP3 will not be able to start properly. In this case, the VPOP3.EXE process may appear in Task Manager, but it won't respond to anything, or it may appear in Task Manager and then stop after a short period.
If this is happening, then first of all, check that the VPOP3DB (or PostgreSQL-VPOP3 in VPOP3 v3 and v4) service is running in Windows. If this is not running, then start it.
If the database service does not exist, see the VPOP3DB service doesn't exist article.
If the database service doesn't start, or starts and stops immediately, see the VPOP3DB service not starting article.
If the database service is started, but VPOP3 won't start, then there are a few possibilities below. Also, check the Windows Application Event log for errors from VPOP3, and check the 'EXCEPTIONS.LOG' file in the VPOP3 directory. These may indicate what the problem is.
This will usually not be a problem, but if you have been moving VPOP3 or have manually installed PostgreSQL, then it is a possibility that is worth checking.
Open a command prompt and go to the PostgreSQL installation directory (usually C:\VPOP3\PGSQL) and then the bin subdirectory.
In the command prompt, type in 'psql -U postgres -p 5433' (omit the '-p 5433' in VPOP3 v3 or v4), then at the password prompt type in 'pgsqlpass'
Type in \l. This will give a list of defined databases. Check that there is a database listed called vpop3 with an owner of vpop3. If not, then the database has not been created.
To create the database/user manually type in
CREATE USER vpop3 LOGIN PASSWORD 'vpop3pass'; CREATE DATABASE vpop3 OWNER vpop3 ENCODING 'SQL_ASCII' TEMPLATE template0;
then \q to exit the PostgresSQL system
Only one instance of VPOP3 can run on a PC at once, so if VPOP3.EXE is already running, any attempt to start a second instance will just lead to the second instance stopping immediately. Use the Process or Details tab in Windows Task Manager to check whether VPOP3.EXE is already running (ensure that you are viewing processes for all users)
If VPOP3 takes an excessive amount of time to start, the VPOP3 service may stay in the 'Starting' state for a long time, end without starting, or start but not respond (depending on which version of VPOP3 you have).
In this case, ending VPOP3.EXE from TaskManager, and starting VPOP3 as an application (by running VPOP3.EXE from the VPOP3 installation directory) may give more information as VPOP3 will usually display a 'splash screen' which displays progress information when started this way.
If VPOP3 appears to hang at the Check OutQueue DB step, then the probable reason is that the VPOP3 OutQueue contains an excessive number of messages, so it is taking a while to validate them. See the delete Outqueue messages directly from the database article for some things to do next.
If a database backup (eg using
pg_dump.exe) is currently running, then VPOP3 will not be able to complete its startup database checks until the backup is complete (due to database locks). You can tell if this is the case by looking for pg_dump.exe in the Windows Task Manager Processes list. If it is, then stopping and restart the VPOP3DB service should cancel the current backup.
If database files are corrupted or missing, then sometimes the database service will start OK, but then when VPOP3 tries to access its data, it will receive unrecoverable errors. These will usually be logged in the EXCEPTIONS.LOG file in the VPOP3 installation directory. If this is the case, you may need to restore from a database backup.
One user had problems with PostgreSQL (and thus VPOP3) not starting when the PC rebooted. He found that unchecking the Enable LMHOSTS lookup setting in Windows → LAN settings → TCP/IP → WINS for his network cards fixed the problem. We are not sure why this is, but it seems to have worked for him, so it's worth trying if all else fails. LMHOSTS lookup is generally not needed any more, since modern Windows networks use DNS, not WINS, so unchecking this option should have no bad effects.
Some users have problems with VPOP3 not automatically starting for various reasons, when starting it manually later will work. This can be solved by using the alternative method of automatically starting VPOP3.
The spam filter's Bayesian statistical database is stored outside the main database for performance reasons. This database lets the spam filter analyse message content based on how previous messages were categorised. Occasionally this database may get corrupted (eg after a power failure or disk failure), which can cause VPOP3 to crash on startup. This database is stored in the VPOP3\_database\bayes.ldb directory on the disk. If you suspect this is the problem, you can delete/move/rename this directory and see if this makes any difference. VPOP3 periodically backs this database up, so it will automatically recover from a previous backup if you do this.