Timeout issues during execution of `LaunchTcUnit.bat` on VM

[vegarosthus]

Has anyone experienced issues with the LaunchTcUnit.bat script timing out during execution? I execute the script on an Azure VM running Windows 10, through Azure Pipelines, and my console output occasionally end up looking like this.

The VM is running 4 cores with 7 GB RAM, so I don't think this is a performance related issue, allthough I feel that some actions, like closing the Remote Desktop connection to the VM, or restarting the VM, seem to mitigate the issue.

One issue that might be a symptom of some underlying issue, is that the TcXaeShell application doesn't seem to be properly shut down after the script executes (and ends abruptedly?).

I'm attaching my azure-pipelines.yml file as well, as I'm unsure what is causing this behavior. Keep in mind that this occurs only some times, so it is kind of hard to reproduce and stabilize the error.

# Demo CI workflow with TcUnit-Runner
name: TcUnit-Runner  

trigger:
- main
pr:
- main

pool: 
    name: AC4Build   
    demands:
    - agent.name -equals TcUnitTests # self-hosted agent  

steps: 

- checkout: self
  displayName: Checkout repository  

- task: CmdLine@2
  displayName: Run PLC unit-tests with TcUnit-Runner 
  condition: succeeded()
  inputs:
    failOnStderr: true
    # Start TcUnit-Runner with a timeout of 3 min
    script: '"C:\Program Files (x86)\TcUnit-Runner\LaunchTcUnit.bat" -U 3 -t PlcTask -w 3.1.4024.20'

- task: PublishTestResults@2
  displayName: Publish TcUnit results
  condition: or(succeeded(),failed())     
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/TcUnit_xUnit_results.xml'

Any help would be appreciated.

[sagatowski]

Hi @vegarosthus! Have you tried calling the TcUnit-Runner directly in your pipeline (skipping the bat-file)? Does the zombie-process exist after the time-out (code 17), or is it created after some other sequence?

[vegarosthus]

Hi @sagatowski! Thanks for the quick reply. I tried executing the application directly by changing my .yml-file to this

# Demo CI workflow with TcUnit-Runner
name: TcUnit-Runner  

trigger:
- main
pr:
- main

pool: 
    name: AC4Build   
    demands:
    - agent.name -equals TcUnitTests # self-hosted agent  

steps: 

- checkout: self
  displayName: Checkout repository  

- task: CmdLine@2
  displayName: Run PLC unit-tests with TcUnit-Runner 
  condition: succeeded()
  inputs:
    failOnStderr: true
    # Start TcUnit-Runner with a timeout of 3 min
    script: '"C:\Program Files (x86)\TcUnit-Runner\TcUnit-Runner.exe" --VisualStudioSolutionFilePath="C:\agent\_work\3\s\TcUnit-Runner Demo.sln" --Timeout="3" --TcUnitTaskName="PlcTask" --TcVersion="3.1.4024.20"'

- task: PublishTestResults@2
  displayName: Publish TcUnit results
  condition: or(succeeded(),failed())     
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/TcUnit_xUnit_results.xml'

but this results in a Access denied-error

Does the script do anything special in regards to giving the application the correct permissions?

I'm not sure what you mean by the second question, but the TcXaeShell Application process is created by the script (or technically TcUnitRunner i guess) and are not being quit if that ends abruptly. That remains the case also if TcUnitRunner is called directly by the pipeline.

[vegarosthus]

Hi @sagatowski! Thanks for the quick reply. I tried executing the application directly by changing my .yml-file to this

# Demo CI workflow with TcUnit-Runner
name: TcUnit-Runner  

trigger:
- main
pr:
- main

pool: 
    name: AC4Build   
    demands:
    - agent.name -equals TcUnitTests # self-hosted agent  

steps: 

- checkout: self
  displayName: Checkout repository  

- task: CmdLine@2
  displayName: Run PLC unit-tests with TcUnit-Runner 
  condition: succeeded()
  inputs:
    failOnStderr: true
    # Start TcUnit-Runner with a timeout of 3 min
    script: '"C:\Program Files (x86)\TcUnit-Runner\TcUnit-Runner.exe" --VisualStudioSolutionFilePath="C:\agent\_work\3\s\TcUnit-Runner Demo.sln" --Timeout="3" --TcUnitTaskName="PlcTask" --TcVersion="3.1.4024.20"'

- task: PublishTestResults@2
  displayName: Publish TcUnit results
  condition: or(succeeded(),failed())     
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/TcUnit_xUnit_results.xml'

but this results in a Access denied-error

Does the script do anything special in regards to giving the application the correct permissions?

I'm not sure what you mean by the second question, but the TcXaeShell Application process is created by the script (or technically TcUnitRunner i guess) and are not being quit if that ends abruptly. That remains the case also if TcUnitRunner is called directly by the pipeline.

As a side note, I can add that the same error occurs if I execute the application in the VM command line logged on as administrator.

[sagatowski]

Hi @vegarosthus! Sorry I don't have any experience using Azure Pipelines, but it sounds like the user that is executing the TcUnit-Runner doesn't have the right user priveleges. For Jenkins I know there are some precautions that are needed. I've described this in the user manual for TcUnit-Runner. I guess it's something similar for the agent in Azure?

[vegarosthus]

Hi @sagatowski, and thanks for your reply. I didn't have the time to investigate this further last week, and I won't this week either. But yes, it looks like it might have something to do with user privileges, allthough the kind of random nature of the symptoms doesn't fit into that. I guess I just have to trawl the web for any clues regarding the Pipelines/.yml setup. I'll take a look at it next week and I will report back here if I find a solution to the problem.

[Bulkje]

I use an Azure runner to execute TcUnit-Runner, and had permission issues in the past. I used a powershell script to check if the azure agent has administrator privileges

function Check-IsElevated
 {
    $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
    $p = New-Object System.Security.Principal.WindowsPrincipal($id)
    if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
   { Write-Output $true }      
    else
   { Write-Output $false }   
 }

I think by default the azure runner runs as Local-System, but you can make a local administrator user and set the agent to use that instead. In Services.msc there's a entry for the Azure Pipelines Agent, there you can change the account that it uses. With all that said, it could very well be that there are no licences for the VM runtime, or the VM is running with Hyper-V so TwinCAT will not run locally in the VM.

[sagatowski]

This project is archived. Replacement for it is in the works.