Failed to create Release artifact directory (Access to the path 'C:\agent\_work\r1\a\NUL' is denied.)

Question

Lately we face an annoying problem with our build agents (2 seperately installed machines running Windows 2016) with the VSTS build agent installed. When we run del "\\?\%CD%\nul" (see Super User) it works for a couple of builds and then appears again.

How and why is this file created and how can we make sure the build agent doesn't break?

Stacktrace below:

Failed to create Release artifact directory C:\agent\_work\r1\a with an exception
Microsoft.VisualStudio.Services.Agent.Worker.Release.Artifacts.ArtifactDirectoryCreationFailedException: Failed to create Release artifact directory 'C:\agent\_work\r1\a'. ---> System.UnauthorizedAccessException: Access to the path 'C:\agent\_work\r1\a\NUL' is denied.
   at System.IO.Win32FileSystem.DeleteFile(String fullPath)
   at System.IO.FileInfo.Delete()
   at Microsoft.VisualStudio.Services.Agent.Util.IOUtil.c__DisplayClass26_1.b__0(FileSystemInfo item)
   at System.Linq.Parallel.ForAllOperator`1.ForAllEnumerator`1.MoveNext(TInput& currentElement, Int32& currentKey)
   at System.Linq.Parallel.ForAllSpoolingTask`2.SpoolingWork()
   at System.Linq.Parallel.SpoolingTaskBase.Work()
   at System.Linq.Parallel.QueryTask.BaseWork(Object unused)
   at System.Linq.Parallel.QueryTask.RunTaskSynchronously(Object o)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   --- End of inner exception stack trace ---
   at Microsoft.VisualStudio.Services.Agent.Worker.Release.ReleaseFileSystemManager.EnsureEmptyDirectory(String directoryPath, CancellationToken cancellationToken)
   at Microsoft.VisualStudio.Services.Agent.Worker.Release.RetryExecutor.Execute(Action action). Retrying the creation of Release artifact directory.

Answer 1

The cause of this problem in our case was not related to the build agent. It was a sub-module of a test-runner we use (testcafe) that creates the file. The wrapper that calls this module passes NUL as the name of the log file... and this is not handled correctly further down the line.