CompleteFTP service fails to start after an upgrade: how to find the cause and fix it

You ran the installer, it finished (or it didn't), and now your file server is down. The words on the screen are almost always the same (the service failed to start), but they are produced by at least five different failures with five different fixes, and Windows shows you the same Services console for all of them. This article tells you which one you have, from evidence you already have on the machine, and then what to do about it.

Two names are used throughout, because they are different things and the error messages confuse them:

• the CompleteFTP service is the Windows service whose service name is CompleteFTP and whose display name in the Services console is Complete FTP Server. This is the file server.
• CompleteFTP Manager is the administration application. It is a client of the service, and it connects to it over the network, even on the same machine.

A separate service called CompleteAgent may also be installed. It is a client-side agent, not the file server; if only CompleteAgent is failing, your file server is fine and this article is not about your problem.

Which situation are you in?

Before anything else, do not re-run the installer and do not copy a configuration file over the top of another one yet. Both destroy the evidence that identifies your case, and the installer rotates the configuration backups you may need. Copy the whole C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Backup folder somewhere safe first.

Then answer from what you have already seen, and read only the case you land on.

The discriminator: did the diagnostics log grow?

Cases B, C and E look identical in the Services console. What separates them is the diagnostics log written by the CompleteFTP service. Open

C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Logs\Diagnostics.log

note its size and modified time, try to start the service, and look again:

• nothing was written: the service process never ran. That is Case B.
• new lines were written and they end in an error: the process ran and refused the configuration it was given. That is Case C.
• new lines were written, the file stops part-way through startup with no error of its own, and Windows reported a timeout: that is Case E.
• new lines were written, the file stops part-way through startup with no error of its own, and Windows did not report a timeout: the process was killed rather than having failed. Treat it as Case B: something outside CompleteFTP is removing or blocking the executable.

You do not need to raise the logging level to do this. The startup block is written at the Information level, which is the default.

The short version

These four steps are the same in every case. Run them before you decide anything.

1. Write down the exact wording of the message and where it appeared: installer dialog, Services console, Windows Event Viewer, or CompleteFTP Manager. The five cases above are told apart by that wording.

2. Note the state of the three server logs in C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Logs: Diagnostics.log, Errors.log and Config.log. Record their modified times before you try anything else.

3. Try the start from an elevated command prompt, so you see the failure text rather than a dialog:

   net start CompleteFTP

4. Look at Diagnostics.log again and apply the discriminator.

Then go to one section only:

• Installer stopped or was rolled back → Case A.
• Nothing written to Diagnostics.log → Case B.
• New lines, ending in an error → Case C.
• Service shows as Running but is unreachable → Case D.
• Windows reported a timeout → Case E.

Do not reinstall, and do not copy a configuration file from another machine, until you have read the section for your case. Both of those actions are the most common way an outage of one hour becomes an outage of one day.

Where everything is

Every path below is the shipped default on a current release.

"The installer" means the production installer, the one in your account on the EnterpriseDT customer site. The download on the public web site is the trial, and it will not upgrade a licensed installation. Wherever this article says to run the installer, that is the one it means.

Two notes that save time:

• If your installation is still under C:\Program Files (x86)\Complete FTP, the current installer will not install there. It installs to C:\Program Files\Complete FTP and tells you "The CompleteFTP Service executable has changed location on the disk. Please update your Windows firewall settings!". Firewall and antivirus rules that name the old path stop matching at that point.
• Errors.log records warnings as well as errors, and it rolls at a small size, so it is the quickest file to read, but it also rolls away quickly. Read it first, and keep a copy.

The configuration backups

Before it changes anything, the installer copies your existing configuration into <data directory>\Backup, named update_<version><date>.db. For example, a configuration at version 24.1.0 backed up on 3 August 2026 becomes update_2410_20260803.db. There is also a daily_… copy taken once a day when the configuration has changed, and an overwrite_… copy taken whenever a configuration is overwritten wholesale. Fifteen of each kind are kept.

This is the file you restore when you roll back, and its name tells you which release it belongs to. Copy it out of Backup before you experiment; the count is capped, and further attempts will push it out.

Case A. The installer did not finish

The installer performs four separable steps. It stops the service, replaces the program files, runs a separate configuration step that upgrades config.db to the new release, and starts the service again. Each of the four fails differently.

1. The service would not stop. The installer asks Windows to stop the service and waits 30 seconds. If the service is still running after that, the installer carries on and the file replacement fails, because the executables are locked. In install.log this looks like a run of File: error creating lines. On screen you may be told the software is still running.

Fix: stop the service yourself and confirm it has stopped before re-running the installer.

net stop CompleteFTP

If it will not stop, end the CompleteFTPService.exe process; you do not need to reboot the machine for this.

2. The configuration step failed. You get a dialog titled Configuration File Creation Error, reading An error occurred during the creation of the configuration file. When the installer then gives up, it reports An error occurred while generating the configuration file.

That dialog has a Details button, and it is worth pressing: it shows the exception and the SQL statement that failed, which names the upgrade step that could not be applied. The same information, with more context, is in Bootstrapper.log.

3. You used the trial installer on a production installation. The trial installer refuses to run against a licensed configuration, with An existing configuration containing a production license was detected. The installer then reports the generic configuration-file error above. The production installer is the one in your account on the EnterpriseDT customer site; the download on the public web site is the trial.

4. The service could not be started at the end. If the installer's own final start attempt fails you get Failed to start service: followed by the Windows error text. The installation itself is complete at that point. Treat it as Case B, C or E according to the discriminator.

If you decide to abandon the upgrade instead of finishing it, see Rolling back to the previous release.

Case B. Windows will not launch the service at all

Either nothing new appears in Diagnostics.log, because the service process never started, or it starts writing and is cut off part-way with no error of its own and no timeout from Windows, because something removed or blocked the executable while it was running. Windows reports one of The system cannot find the file specified, error 2, error 1064, or that the service must be installed first.

Check that the registered executable exists. From an elevated command prompt:

sc qc CompleteFTP

Compare BINARY_PATH_NAME with what is actually on disk. Two things go wrong here:

• The file is missing. The installer deletes the previous Server folder before it writes the new one, so an installation that was interrupted, blocked by antivirus, or unable to write to the target folder can leave the service registered and its executable absent. This is the usual explanation for CompleteFTPService.exe disappearing "by itself" after an upgrade or a reboot that followed one.
• The registered path points somewhere the files no longer are: most often an old C:\Program Files (x86)\Complete FTP\Server\ path.

The fix for both is to run the production installer again, over the top, keeping the existing configuration. It rewrites the whole Server folder and re-points the service at it. You do not need to uninstall first, and uninstalling does not delete your configuration or user data.

Do not copy CompleteFTPService.exe from another machine. It is one file out of a set that must match, and a mismatched set fails later and less legibly.

If the service is present but Windows refuses to start it because it is disabled, note that the installer only sets the startup type when it creates the service. If the service already exists, the installer updates its executable path and leaves the startup type alone, so a service someone set to Disabled stays disabled across every upgrade. Set it back to Automatic in the Services console.

Case C. The service starts and then stops

New lines appear in the server's Diagnostics.log in the data directory, and the Windows Application event log has an entry from source CompleteFTP beginning Service cannot be started. The server also writes Error while starting server to Errors.log.

The message after Service cannot be started. is the diagnosis. In practice it is one of these four.

The configuration version does not match the software version

Service cannot be started. ... ConfigException: The version of the configuration file, 25.0.4,
does not match the version of the server software, 24.1.0.

The server refuses to run a configuration that was not written for it, in either direction, and it prints both numbers immediately above the failure in Diagnostics.log:

2026-08-03 09:12:44,340 INFO Server [Server.1] Starting server Server 1 (ID=045e12e7-...)
2026-08-03 09:12:44,341 INFO Server [Server.1] Config version = 25.0.4
2026-08-03 09:12:44,341 INFO Server [Server.1] Software version = 24.1.0

Server 1 there is the name of the configured server in your configuration, not a version or a machine name. Read the two version numbers, because they tell you which half of the upgrade did not happen.

Configuration newer than the software is by far the common case. The configuration was upgraded but the program files were not, or were replaced with older ones. Causes, in order of how often they turn up in support requests:

• A configuration file was copied or restored from another machine that was on a later release (during a migration, a disaster-recovery test, or an attempt to reproduce production on a test box. The migration procedure requires you to install, copy the configuration in, and then run the installer again so the copied configuration is upgraded; skipping that second install produces exactly this.
• An upgrade was rolled back by reinstalling the old release without restoring the matching configuration backup.
• The configuration step ran but the program files did not all land (see Case A).
• In a cluster, the machines were upgraded in the wrong order or one of them was missed. Every node must end on the same release; a node left behind sees a configuration from the newer one.

Fix: make them match. Either install the release named as the configuration version, or restore the update_… backup that matches the software version. See Rolling back to the previous release.

Software newer than the configuration means the configuration step never ran. Re-run the installer over the top; if you need to do it without the installer, stop the service and run

"C:\Program Files\Complete FTP\Server\cftpconfig.exe" /v

which upgrades config.db in place and reports what it is doing. Note that every invocation of cftpconfig upgrades the configuration, whatever options you pass. It is not a read-only tool. It takes its own backup first, but take one yourself as well.

The configuration file cannot be read

Service cannot be started. ... Error while loading config from Data Source=C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\config.db;...

The text after the data source is from the database engine. A corrupt or truncated file, a column the software does not recognise, or a transaction error all land here. Restore the newest update_… backup from <data directory>\Backup that matches your installed software version. See Rolling back to the previous release.

The service account cannot reach the configuration

Installing or upgrading resets the permissions on three things: config.db, the Backup folder and the Logs folder. Inheritance is switched off and the access list is replaced with Full Control for the account that ran the installer, NT AUTHORITY\SYSTEM, NT AUTHORITY\SERVICE and the local Administrators group. Any access those three had through inherited permissions is gone.

By default the service runs as the local SYSTEM account and is unaffected. If you changed it to a named or domain account, re-check that account's access to those three paths after every upgrade. Diagnostics.log records the identity actually in use during startup on a line beginning Running as.

The .NET Framework is older than the software requires

The current release needs .NET Framework 4.7.2 or later. That is .NET Framework, not .NET Core or .NET 5+. When it is present but too old, startup fails part-way with a framework or security-protocol error rather than a configuration error. Diagnostics.log prints what is actually in use, on lines beginning .NET CLR version = and .NET version =. When it is missing altogether the process does not start at all, which presents as Case B.

Case D. The service is running but nothing can reach it

Windows shows Complete FTP Server as Running, and CompleteFTP Manager disagrees. What it says depends on where you are running it from.

Running CompleteFTP Manager on the server machine itself, connecting to localhost:

The CompleteFTP service is not currently running on this machine. Would you like to start it?

and if you answer Yes, CompleteFTP Manager failed to start CompleteFTP service.

Both of those messages are guesses, and here they are wrong. CompleteFTP Manager reaches that dialog whenever its connection to the administration port fails for any reason other than a rejected login. Answering Yes runs net start CompleteFTP, which fails because the service is already running, and that failure is reported as "failed to start the service". So the message tells you the connection failed, not that the service is stopped. Believe the Services console, not the dialog.

Running CompleteFTP Manager from your own workstation, connecting to the server by name or address, you get no such offer, only Could not connect to '<address>'. Try again?. It is the same failure; CompleteFTP Manager simply will not offer to start a service on a machine it is not on. Everything below applies either way, but steps 1 and 2 have to be run on the server machine.

The underlying connection error appears in CompleteFTP Manager's own log, under the Windows profile of whoever ran CompleteFTP Manager, on the machine they ran it on, at %LOCALAPPDATA%\EnterpriseDT\CompleteFTP\Logs\Diagnostics.log, which is a different file from the server's Diagnostics.log:

Failed to connect to 127.0.0.1:14983 within timeout 120000 ms

Work through these, in this order:

1. Is the administration listener actually up? In the server's Diagnostics.log, look for the administration port being bound. If another process has it you will see a line containing is already using port and the process name and id; if no interface could be bound at all you will see No interfaces bound. Port. Confirm with:

   netstat -anb | findstr LISTENING

2. Is it listening only on one address? If the administration site has specific interfaces configured, it will not answer on localhost. netstat will show the port bound to a single address rather than the all-interfaces wildcard. Point CompleteFTP Manager at that address instead of localhost. That gets you back in, and you can then correct the interface setting.

3. Do CompleteFTP Manager and the server match? This one connects and then refuses, so it looks different from the rest of Case D. An upgrade replaces both on the server machine, but a copy of CompleteFTP Manager installed on an administrator's own workstation is not upgraded with it. That produces a dialog titled Version Mismatch:

   The versions of the client (24.1.0) and the server (25.0.4) do not match.

   Install the matching version of CompleteFTP Manager on that workstation.

4. Is a firewall rule pointing at the old executable path? See the note under Where everything is.

5. Is the server admin-only? If your licence is for Free, Standard or Professional but the configuration has acquired Enterprise MFT features, the server starts, accepts administrative connections, and refuses everything else, logging:

   The server was not started because the installed license is for a lower edition.  Enterprise features have been enabled, but the installed license is only for the Professional edition.

   Note the trap: that line is written at ERROR level and says the server "was not started", but the service does start and stays up. It is Case D, not Case C. The giveaway is that the log carries on past it instead of ending there.

   The usual route into this is a trial installation somewhere in the machine's history, since the trial enables Enterprise MFT. The remedy is to activate the licence that matches, or to remove the features that require Enterprise MFT.

Case E. Windows timed the start out

The Complete FTP Server service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Windows error 1053, usually with a 30000-millisecond timeout, and usually on a reboot rather than a manual start. Diagnostics.log shows the startup sequence beginning and stopping part-way, with no error of its own.

This is the Windows Service Control Manager giving up, not CompleteFTP failing. Its default patience is 30 seconds from the moment the service is asked to start, and a machine that is booting (starting antivirus, mounting network storage, waiting on a domain controller) routinely takes longer than that to get one service through startup.

Two things to do:

• Raise the Service Control Manager's timeout. Create or set the DWORD value ServicesPipeTimeout under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control to the number of milliseconds to allow, then reboot. 180000 (three minutes) is a reasonable starting point. This is a Windows-wide setting and affects every service on the machine.
• Check what startup is waiting for. Look at the last line written to Diagnostics.log before the timeout. Mapped network folders, an unreachable domain controller and an unreachable SMTP server for notifications are the usual culprits, and all three are worth fixing regardless.

You do not need to configure Windows recovery actions. The installer already sets them when it creates the service: restart after 60 seconds, for each of the first three failures. That is also why a failing service can appear to start and stop repeatedly for a few minutes after an upgrade.

Rolling back to the previous release

Referenced from Cases A and C. The configuration and the program files must be rolled back together. Rolling back only one of them produces the version mismatch described in Case C.

1. Stop the CompleteFTP service.
2. In <data directory>\Backup, find the newest update_… file whose version matches the release you are rolling back to. Copy it out to a working folder and rename the copy config.db.
3. Move the current <data directory>\config.db aside. Do not delete it.
4. Put the renamed backup in its place.
5. Run the production installer for the release you are rolling back to, and leave Keep existing configuration selected.

If there is no backup with the right version in Backup, do not improvise with a configuration from another machine. Finish the upgrade forwards instead: install the release that matches the configuration you have.

When it doesn't work

Ordered by how often each turns up in support requests. Each is tagged with the cases it applies to.

A configuration file was moved between machines on different releases. [C] This is the single most common cause of the version-mismatch error, and it is not always deliberate. Restoring a whole ProgramData folder from backup does it too. The configuration file and the installed software must be the same release. If they are not, change one of them; there is no setting that relaxes the check.

The service did not stop, so the upgrade only half happened. [A, B, C] The installer waits 30 seconds. Stop the service yourself first, and confirm it has stopped, particularly on a busy server or one with a large configuration. install.log will show file-creation errors if this happened.

CompleteFTPService.exe is gone. [B] Re-run the production installer. Copying the executable from another machine does not work, and produces a fresh set of errors that look unrelated.

The trial installer was used to upgrade a production installation. [A, D] The trial installer refuses a licensed configuration outright; a trial installation that did succeed at some earlier point leaves the configuration marked for Enterprise MFT, which later shows up as an edition-related refusal to serve users. Always upgrade with the production installer from your account.

CompleteFTP Manager says the service failed to start, and it is running. [D] The message is produced by a failed connection, not by a failed start. Check the Services console before you act on it.

The service is set to Disabled and stays that way across upgrades. [B] The installer sets the startup type only when it creates the service, so a disabled service is never re-enabled by an upgrade.

Permissions on config.db, Backup and Logs were reset by the upgrade. [C] Only relevant if you run the service under a named account rather than the local SYSTEM account, but if you do, this recurs at every upgrade until you make the grants explicit rather than inherited.

The administration port is bound to one address, so localhost does not answer. [D] Connect CompleteFTP Manager to that address instead, then fix the interface setting.

A remote copy of CompleteFTP Manager was not upgraded. [D] Upgrading the server machine does not reach administrators' workstations.

.NET Framework is older than the software requires. [B, C] The current release requires .NET Framework 4.7.2 or later. That is .NET Framework, not .NET Core or .NET 5+. Present but too old shows up as Case C; missing altogether shows up as Case B. Diagnostics.log in the data directory prints what is in use at startup, on lines beginning .NET CLR version = and .NET version =.

Firewall or antivirus rules still name the old program path. [B, D] The installer warns when the executable location changes, and it is easy to click past. Antivirus quarantine of a newly written executable also presents as Case B.

A cluster was upgraded in the wrong order, or a node was missed. [C] Secondaries are upgraded first, with the primary stopped, and the primary last; every node must end on the same release. A node left behind hits the version mismatch in Case C. The full procedure is in the product guide, linked below.

Reading the output

The startup block in Diagnostics.log in the data directory is the fastest way to establish what is actually installed and running. It is written at the default logging level and looks like this:

2026-08-03 09:12:44,102 INFO Service [Service.1] Starting CompleteFTP service...
2026-08-03 09:12:44,105 INFO Service [Service.1] BaseDirectory = C:\ProgramData\Enterprise Distributed Technologies\Complete FTP
2026-08-03 09:12:44,106 INFO Service [Service.1] ExecutablePath = C:\Program Files\Complete FTP\Server\CompleteFTPService.exe
2026-08-03 09:12:44,340 INFO Server [Server.1] Starting server Server 1 (ID=045e12e7-...)
2026-08-03 09:12:44,341 INFO Server [Server.1] Config version = 25.0.4
2026-08-03 09:12:44,341 INFO Server [Server.1] Software version = 25.0.4
2026-08-03 09:12:44,342 INFO Server [Server.1] .NET CLR version = 4.0.30319.42000
2026-08-03 09:12:44,342 INFO Server [Server.1] .NET version = 4.8
2026-08-03 09:12:44,343 INFO Server [Server.1] Operating System = Windows

What to take from it:

• ExecutablePath is the executable Windows actually launched. If it is not the one you just installed, you have two installations, and the wrong one is registered as the service.
• Config version and Software version must be identical. They are printed before the check that compares them, so they are present even in a failing start.
• If the file stops part-way through this block with nothing further and no error of its own, the process was stopped rather than having failed. If Windows reported a timeout, that is Case E; if it did not, the process was killed from outside, which is Case B.
• An ERROR line naming Error while starting server is the last thing written before the service gives up; the exception text follows it.

If you are sending logs to support, send Diagnostics.log and Errors.log from the data directory, plus install.log and Bootstrapper.log from the program directory. Together those four cover all five cases, whichever machine of a cluster you are on. Move the existing log files aside first and reproduce, so that what you send is only the failing attempt.

If you are on an older release

• The requested security protocol is not supported at startup. Affected 23.0.0–23.0.1, fixed in 23.0.2. Upgrading .NET Framework to 4.8 also avoids it.
• Installer failure when e-mail notifications were saved by an older release. Affected releases up to 23.1.x, fixed in 24.0.0.
• Installer error while copying e-mail notifications and process triggers. Fixed in 22.2.1.
• Installer failure on non-canonical access-control lists. Fixed in 12.1.4.

In every case the remedy is to upgrade to the current release. If you are jumping several releases, test the upgrade on a copy first.

Related

• Product guide: How to upgrade, Requirements, Migrating to another machine, Upgrading a cluster, cftpconfig, Logging.
• KB: Turning on debug logging in CompleteFTP, for raising the logging level once the service runs again.
• Background: Migrating an SFTP server and Setting up an SFTP server on Windows.

Other technical articles

• CompleteFTP: System.OutOfMemoryException during SFTP, or a service that stops responding
• Does edtFTPnet/PRO support .NET 8? Which assembly to reference for .NET Framework, .NET Core and .NET 5+
• How to disable weak ciphers and encryption algorithms in CompleteFTP
• How to enable Debug logging in CompleteFTP for troubleshooting
• How to export and import CompleteFTP configuration between servers and versions
• IP filtering and whitelisting in CompleteFTP: what it supports and how to configure it
• Passive FTP and FTPS data connection failures in CompleteFTP: login works, the directory listing times out
• SFTP login fails with "No supported authentication methods available (server sent: publickey)" or "Permission denied (publickey)"
• Using Active Directory, Entra ID (Azure AD), SAML and LDAP groups to control who can log in to CompleteFTP
• Why SFTP transfers fail with "ConsumeWindowSpace timed out", and how to fix it
• Why an SSL certificate won't import into CompleteFTP, and how to fix it

Download Free Trial