I can no longer deploy my website due to this error. For the last few months, I would simply restart the server and the step would succeed, but no longer. Here is the error message:
System.IO.IOException: (32) The process cannot access the file because it is being used by another process: [\?\D:\xxxxxx\Antlr3.Runtime.dll]
at Alphaleonis.Win32.NativeError.ThrowException(UInt32 errorCode, String readPath, String writePath)
at Alphaleonis.Win32.Filesystem.File.CopyMoveCore(Boolean isFolder, KernelTransaction transaction, String sourceFileName, String destinationFileName, Boolean preserveDates, Nullable1 copyOptions, Nullable1 moveOptions, CopyMoveProgressRoutine progressHandler, Object userProgressData, CopyMoveResult copyMoveResult, PathFormat pathFormat)
at Alphaleonis.Win32.Filesystem.File.Copy(String sourceFileName, String destinationFileName, Boolean overwrite)
at Calamari.Integration.FileSystem.CalamariPhysicalFileSystem.RetryTrackerFileAction(Action fileAction, String target, String action)
at Calamari.Integration.FileSystem.CalamariPhysicalFileSystem.CopyDirectory(String sourceDirectory, String targetDirectory, CancellationToken cancel)
at Calamari.Integration.FileSystem.CalamariPhysicalFileSystem.CopyDirectory(String sourceDirectory, String targetDirectory)
at Calamari.Deployment.Conventions.CopyPackageToCustomInstallationDirectoryConvention.Install(RunningDeployment deployment)
at Calamari.Deployment.ConventionProcessor.RunInstallConventions()
at Calamari.Deployment.ConventionProcessor.RunConventions()
Greetings! Are you deploying to a Custom Installation Directory? If so, are you stopping the App Pool prior to deploying? Is your anti-virus software configured to scan the folder being deployed to?
I am stopping IIS altogether and I have excluded the deploy-to folder path from virus scan software.
Iâve seen cases where even when the app pools are stopped, they continue to execute until theyâre done with whatever request they were handling at the time. Are you using the Custom Installation Directory feature?
Yes. I am using the custom installation directory feature
Thank you for confirming 
For your application, is using that feature something that is required? The Deploy to IIS step will create a new folder and switch where IIS is pointing when the deployment is complete which may solve your issue. If not, we can eliminate the w3wp processes as an issue by placing a Run a Script step in between the stopping of IIS and the deployment of new code using something like
$appPools = Get-Process | Where-Object {$_.ProcessName -eq âw3wpâ}
while ($null -ne $appPools)
{
Write-Output âWaiting for app pools to stopâŚâ
Start-Sleep -Seconds 3
$appPools = Get-Process | Where-Object {$_.ProcessName -eq âw3wpâ}
}
I will try that script. Thanks!
Cool! Please let me know if that doesnât solve your issue
Even though I ran a script to stop the iis in step 1, when the script to kill the w3wp process kicked off in step 4 it got stuck for 2 days and continually wrote âWaiting for app poolâ. This is discouraging.
Hey there Suzanne, sorry to hear you are still having difficulties 
Iâm wondering if we can confirm that step 1 is working correctly. Do you have access to the IIS server itself? Can you test the process by executing only step 1 and log on to the server to see if the site(s) are in a stopped state?
Hi Shawn - I have full access to that server and can confirm the site does stop. I actually stop the IIS.
Hi Suzanne, thanks for getting back to me Perhaps my script isnât working the way I thought it was, when I tested it locally it stopped printing the Waiting once the last of the w3wp processes stopped. Since you have full access to the server, perhaps we can do some more troubleshooting. After you stop the site, take a run Task Manager and see if all w3wp.exe are gone from the Details tab.
I see this in the event log:
Id=1000
Application Error
Faulting application
name: w3wp.exe, version: 10.0.14393.0, time stamp: 0x57899b8a
Faulting module
name: ucrtbase.dll, version: 10.0.14393.2999, time stamp: 0x5ce36be6
Exception code:
0xc0000409
Fault offset:
0x000000000006cba8
Faulting process id:
0xbb0
Faulting application
start time: 0x01d55dd4660fc8df
Faulting application
path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module
path: C:\Windows\System32\ucrtbase.dll
Report Id:
7bfec7ef-14cd-4ad2-a899-1992d1ac0823
Faulting package
full name:
Faulting
package-relative application ID:
Hmm, that seems like the w3wp.exe is suffering from a hard crash, but that should result in it being in a stopped state. Were you able to verify that when you stop IIS, all the w3wp.exe process stop as well?
I am not seeing the w3wp.exe process in the details tab of task manager at all - neither stopped nor running. So, then I browsed to the web site and looked in details again. There it is, but it disappeared the minute I stopped the site.
That confirms that the w3wp.exe processes arenât hanging, thanks for checking into that Strange that my script continued to run, should have stopped when the w3wp.exe processes stopped.
If I may ask a question, is it necessary to use the custom installation directory? Or are you open to trying the automatically generated folder location and letting the Step Template perform the switch for you in IIS?
I am open to anything at this point. How would I go about that?
Within the Deploy to IIS Step template, disable the feature of Custom Installation Directory. This will allow Octopus to create a versioned directory on the web server for each deployment. When a new deployment occurs, the code will be placed in a new folder and Octopus will point IIS to the new folder so there is minimal downtime. This also makes it easy to switch back should something go wrong (depending on your retention policies, of course). This should alleviate the issue of deleting or overwriting any files that may still be in use.
I have rewritten the process to use that template. Initial deploy worked without hiccup. I will continue to monitor and let you know. Thank you very much for your support.
Glad to hear that itâs working for you You are most welcome, please donât hesitate to contact us if you need anything else
Regards,
Shawn