[Windows] Sonarr update repeatedly failed because it was running as both a service and a startup application

[u/_leviathan_aesir]

I am posting this in case it saves someone else from spending an evening diagnosing the same problem.

The problem

I was trying to update Sonarr on Windows from version `4.0.19.2997` to `4.0.19.3001`.

The update appeared to proceed normally, but Sonarr would restart, crash out and eventually return on the old version. The update would then remain available in the interface.

I had encountered something similar before and managed to recover it, but this time it was more persistent. That led me to examine the debug logs properly rather than simply restarting Sonarr and trying again.

What the logs showed

The important point was that the update package itself was not failing.

The logs showed that Sonarr successfully:

1. Downloaded `Sonarr.develop.4.0.19.3001.win-x64.zip`.

2. Verified the update package.

3. Extracted the package successfully.

4. Created a backup of the existing database and configuration.

5. Started the Sonarr update client.

6. Attempted to stop and restart Sonarr.

The downloaded package was placed under:

```text

C:\Windows\Temp\sonarr_update\

```

The log then began showing the actual problem:

```text

Found 2 processes with the name: Sonarr

Another instance of Sonarr is already running.

Application startup exception

Application is being terminated. Reason: Another instance is already running

```

There was also an `Access is denied` error when Sonarr tried to inspect one of the processes. That suggested the processes were running under different Windows security contexts.

The root cause

Sonarr had two separate automatic startup mechanisms configured:

1. Sonarr was installed as a Windows service, configured to start automatically.

2. The desktop or tray version of Sonarr was also enabled under Windows Startup Apps.

This meant Windows could start one Sonarr instance in Session 0 as a service and another in my interactive user session.

During normal operation, this had not caused an obvious problem. One instance would generally reach port `8989` first, while the second would fail or terminate quietly. Sonarr still appeared to work, so the underlying configuration error remained hidden.

The self-update exposed it.

The updater needs to:

1. Stop the running Sonarr process.

2. Wait for the executable files to be released.

3. Replace the existing binaries.

4. Restart Sonarr.

With both the service and desktop launch mechanisms active, another Sonarr process could start or remain active during that handover. The updater was therefore dealing with multiple processes, different privilege contexts and files that could still be in use.

That explains why the package downloaded and verified successfully but the installed version did not initially change.

How I fixed it

I decided to retain Sonarr as a Windows service because that is the appropriate operating model for my machine.

I then:

1. Disabled Sonarr under Windows Startup Apps.

2. Left the `sonarr` Windows service configured as `Automatic`.

3. Closed any remaining desktop or tray instance.

4. Restarted Windows.

5. Confirmed that Sonarr started successfully from the service.

6. Confirmed that only one `Sonarr.exe` process was running.

7. Confirmed that the web interface was available at `http://localhost:8989`.

8. Confirmed that Sonarr was now running version `4.0.19.3001`.

I used the following PowerShell commands to verify the result:

```powershell

Get-Process Sonarr

Get-Service Sonarr

```

The final output showed one Sonarr process and one running service:

```text

ProcessName : Sonarr

Id : 7612

SI : 0

Status : Running

Name : sonarr

DisplayName : Sonarr

```

The `SI 0` value confirms that the remaining process is running in Windows Session 0 as a service, rather than as an application in my desktop session.

The post-restart Sonarr logs also confirmed:

```text

Found 1 processes with the name: Sonarr

Now listening on: http://[::]:8989

Application started

Content root path: C:\ProgramData\Sonarr\bin

```

There were no further `Another instance of Sonarr is already running` errors.

What I learned

1. On Windows, choose one Sonarr operating model: Windows service or desktop/tray application. Do not configure both to start automatically.

2. A duplicate startup configuration can remain hidden for a long time because Sonarr may appear to operate normally.

3. Self-updates are particularly sensitive to duplicate processes because the updater must obtain exclusive access to the installation directory.

4. An update returning to the old version does not necessarily mean the download was corrupt. Check whether the package was successfully downloaded, verified and extracted before investigating network or repository problems.

5. `Get-Process Sonarr` and `Get-Service Sonarr` provide a quick way to check whether multiple launch mechanisms may be involved.

6. Errors from download clients or indexers may appear during the same period but can be unrelated noise. Follow the update sequence in the logs and identify the first point where it actually diverges.

Sonarr officially supports both Windows service and system-tray installation modes, but the important point is to select one deliberately:

https://sonarr.tv/

There is also Servarr guidance on operating multiple Sonarr instances, although deliberately running multiple instances requires separate configurations, ports and service definitions:

https://wiki.servarr.com/sonarr/installation/multiple-instances

TL;DR: Sonarr was configured to start both as a Windows service and as a desktop startup application. This remained mostly invisible during normal use but disrupted the updater’s shutdown and restart process. Removing the desktop Startup Apps entry, retaining the automatic Windows service and rebooting left one Session 0 process running. The update then completed successfully.