I am running UI-Automation Test with Appium WinAppDriver using a .bat
file. When I run the .bat
file manually on the agent everything goes as expected but it produces
System.ComponentModel.Win32Exception (5): Access is denied exception when running through Azure Release.
Tried:
BuildUser
is the account having admin privileges on my agent machine DOTNET4
.
I have tried running the release pipeline using both BuildUser
account and also my local account.
Tried different ways to run the .bat
file as admin too.
I provided Full Control of folder in which I have WinAppDriver.exe
, AzureAgent.exe
, & Folder having AUT.
Azure Agent Service in running using the BuildUser
account in Windows Services. I have this .exe
running using Run as Administrator
.
Contents of .bat file is attached:
@echo off
set TESTDIR=%~1
set LaunchedFromWinAppDriver=True
set ApplicationExe=C:\Git\filePathToExe\application.exe
C:\Git\filePathToExe\AppExeCommandLineRunner.exe -X "%ApplicationExe%"::"%TESTDIR%"
Code Snippet that is causing Exception:
public static void KillApplication()
{
try
{
string windowHandle = WindowDriver.CurrentWindowHandle;
Log.Debug("CurrentWindowHandl:"+windowHandle);
[DllImport("user32.dll")]
static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint processId);
IntPtr windowHandlePtr = new IntPtr(Convert.ToInt64(windowHandle, 16));
Log.Debug("WindowHandlePtr:" +windowHandlePtr.ToString());
uint processId;
GetWindowThreadProcessId(windowHandlePtr, out processId);
Log.Debug("Process Id for killing is: " + (int)processId);
Process process = Process.GetProcessById((int)processId);
process.Kill();
}
catch(Exception ex)
{
Log.Error("FailedToKill:", ex);
throw;
}
}
Function GetWindowThreadProcessId
returns 0 when run using Azure Release pipeline and then process.Kill generates the exception.process. Additionally if I give a valid Process id using some other logic it fails to Kill that as well giving same access id denied.
GetWindowThreadProcessId
returns a valid process id on which AUT is attached when the .bat
file is run manually on the agent.
I believe this issue is due to a permission issue.
The above issue was happening because the Azure Agent Listener was running as a service
. It solved when I run the Agent.Listener.exe
manually on the system in a interactive desktop session.
Path to Listener.exe: "C:\agent\bin\Agent.Listener.exe"