StackOverflowException when deploying package

I cannot deploy any release from my project due to StackOverflowException. Here is task log message:

== Failed: Step 2: Deploy Web Site ==
12:32:52   Fatal    |     The step failed: One or more child activities failed.
12:32:52   Verbose  |     Deploy Web Site completed
                    |     Running: dev-01
12:32:47   Verbose  |       Octopus Server version: 3.2.3+Branch.master.Sha.[sha]
12:32:47   Info     |       Deploying package 'D:\Octopus\Files\[package-name].nupkg-[guid]' to machine '[machine-name]'
12:32:48   Verbose  |       Octopus Deploy: Calamari version 3.1.8+Branch.master.Sha.[sha]
12:32:48   Info     |       Deploying package:    D:\Octopus\Files\[package-name].nupkg-[guid]
12:32:48   Verbose  |       Extracting package to: D:\Octopus\Applications\[extraction-folder]
12:32:49   Verbose  |       Extracted 136 files
12:32:49   Error    |       Process is terminated due to StackOverflowException.
12:32:52   Error    |       The remote script failed with exit code -1073741571
  • I removed all powershell scripts from my step template but still getting this error.
  • This step works for other projects.
  • Cloning project do not help


Thanks for letting us know. It would be great if we could somehow isolate this into something that causes it to happen repeatably. Does it only happen with this particular NuGet package?

Paul Stovell

Hi Paul.
Thanks for your attention. I figure out what is the source of exception.

In my “Deploy Web Site” step (from “Deploy a NuGet package” template) “Additional transforms” parameter is set to #{config.transform}

In project I have 2 variables with the name “config.transform” and both have empty scope:

Name: config.transform
Value: Web.Test.config => Web.config
Scope: <empty>
Name: config.transform
Value: Web.Production.config => Web.config
Scope: <empty>

When I set correct scope (depending on channel), StackOverflowException dissapears.

I don’t know why Octopus launched project with incorrect configuration and I am afraid to ask how exactly it tried to launch it:). At least nothing was removed from file system.
I hope this bug will be fixed soon:).

Hi Sergey,

Thanks for the follow up, that’s pretty concerning if that is what triggered the StackOverflowException. We’ll try to reproduce this on Monday and will let you know how we go.


Hi Sergey,

I am taking this ticket over from Paul. I’ve just spent a good hour trying to replicate this and it isn’t happening for me at all.
I will run it past someone else in the team who has hit this area recently.
It might help us if we could replicate this repeatedly and as you can, your package or config files might help us here. Is that something we could get a copy of?
If yes I can give you a secure place to upload the files.



i upgraded to 3.4 and using the new Tenants feature.
Getting the error:
'The remote script failed with exit code -1073741571’
with: Process is terminated due to StackOverflowException.

This happens whenever i try to deploy a Windows Service step
or a DB.Up database upgrade console application step.
Deploying Web app packages works fine.


Hi Bojan,

Could you please provide the full deployment logs
If you would prefer they were private you will need to create a new thread or email them to us at support at octopus dot com.


So the scenario in which I have this happen to be triggered is via custom powershell code to create an IIS site (because of special settings on App Pool, I can’t just go with out of the box stuff).

I normally have variables for portNumber and SSLFlags. Because of refactoring, NEITHER of these existed at all ( I mean there wasn’t a variable for them in the variable or variable sets, not just not scoped) as I flat out missed them.

Here’s the relevant part of the custom code. I think this may be a variation (although same error) from what was mentioned above so unless you really want the logs, I’m not going to bother. Also a good reason to start playing more with F#.

 switch ($sslFlags)
                    New-Item $IISPath -bindings @{protocol="https";bindingInformation="`:$portNumber`:$hostheader"} -physicalPath "$physicalPath"                
                    Set-ItemProperty $IISPath -Name applicationPool -Value $AppPoolName
                    setSSlBindings -portNumber $portNumber -FriendlyName $Binding
                    New-Website -Name $siteName -HostHeader $hostHeader -PhysicalPath $physicalPath -ApplicationPool $AppPoolName -Ssl -port $PortNumber -SslFlags $sslFlags -force                
                    New-Website -Name $siteName -HostHeader $hostHeader -PhysicalPath $physicalPath -ApplicationPool $AppPoolName -Ssl -port $PortNumber -SslFlags $sslFlags -force

Hi @Mpeterson,

The major cause of the StackOverflowException error is when a variable is recursively defined with a secondary variable. We added a catch that will at least error now when this occurs.
You are welcome to send through logs with variables turned on and we should be able to help you find the offending variables if you are unable to.


I have been able to find the variable(s), but what you describe wasn’t the case here.
I’ve been trying to find the happy mix of when to use variable sets, when to use project variables, and now here shortly when to use tenanted variables. After having to copy a project for reasons, I’m going through the project figuring out what I need to do to reconfigure and I end up with a printout 25 pages long with multiple duplicates of the same variables, so I started moving some/most of those to variable sets.

I had about 15 different projects that when I had them using project variables, I used “#{serviceName}” to set up the project variable. When I switched to variable sets I switched the naming to include the service name so I didn’t accidentally inherit from a different variable set. So if my Service was called “MikeService”, the variable became “mikeServiceName”. Or it should have. Except I missed some as I was flipping through all of the projects and all of the steps. So where I got that error is where I previously had a local variable “serviceName” that I had then blown away and added as a different name in a variable set (this variable never existed in a variable set), but then missed updating in a step of the project process.

ServiceName is just an example. I had the same thing with username/password and a few others. It was a good opportunity to standardize some of the stuff I should have been doing all along.


Hi Mike,

Could you provide a deployment log with our special variables turned on when this exception occurs. Here is the documentation about the variables if you don’t have it handy:



Sorry, I should have captured them at the time, but it has been a little while now and I haven’t hit it since.
If I run into it again I will do so.