This cmdlet keeps my ps1 to exe stay running in task manager

[castillocaleb]

I have made a GUI that lets users login with sql creds. It has 2 textboxes for email and pw and uses Connect-DbaInstance from dbatools.io to test connection.

I have gone through each step on making my GUI... adding logic... building an EXE... and this is the only part where it keeps the EXE alive after closing it.

the Connect-DbaInstance cmdlet can be found on the dbatools.io website but I cannot share external links on this post since I need a minimum of 5 posts.

My code:

Code: Select all

$buttonLogin_Click = {
	if ($maskedtextboxUserName.Text -ne "" -or $maskedtextboxPassword.Text -ne "")
	{
		Login-Account -Username $maskedtextboxUserName.Text -Password $maskedtextboxPassword.Text
		$checkLogin = Connect-DbaInstance -SqlInstance $sqlInstance -SqlCredential $creds
		
		if ($checkLogin -ne $null)
		{
			$dataIntakeForm.Visible = $false
			Show-Intake_psf
		}
		else
		{
			$labelStatus.Text = "Connection unsuccessful"
		}
	}
	else
	{
		$labelStatus.Text = "Please make sure all textboxes are populated"
	}
}

function Login-Account
{
	param (
		[string]$Username,
		[string]$Password
	)
	# Store login info into global creds variable
	$securePw = $Password | ConvertTo-SecureString -AsPlainText -Force
	$Global:creds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $Username, $securePw
}

[jvierra]

If you set the main form's visible to false the form will close and the script will exit. You cannot hide the main form in PowerShell.

[castillocaleb]

hmmm I just changed my code to

Code: Select all

$buttonLogin_Click = {
	if ($maskedtextboxUserName.Text -ne "" -or $maskedtextboxPassword.Text -ne "")
	{
		Login-Account -Username $maskedtextboxUserName.Text -Password $maskedtextboxPassword.Text
		$checkLogin = Connect-DbaInstance -SqlInstance $sqlInstance -SqlCredential $creds
		
		if ($checkLogin -ne $null)
		{
                         $labelStatus.Text = "Connection successful"
		}
		else
		{
			$labelStatus.Text = "Connection unsuccessful"
		}
	}
	else
	{
		$labelStatus.Text = "Please make sure all textboxes are populated"
	}
}

function Login-Account
{
	param (
		[string]$Username,
		[string]$Password
	)
	# Store login info into global creds variable
	$securePw = $Password | ConvertTo-SecureString -AsPlainText -Force
	$Global:creds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $Username, $securePw
}

and I closed the EXE after login was successful and it still is alive in Task Manager.

[jvierra]

You have some piece of code that keeps it alive. WIth the provided information there is no way to determine why this is happening.

You cannot hide a form that is a dialog. Making a dialog not visible will close the dialog. Once all dialogs are closed then any code running outside of the dialogs will control what happens.

[castillocaleb]

I've segregated that just the login and its in fact the Connect-DbaInstance cmdlet. I have the entire code here.
Github -> /senorezi/DbaTools_GuiHang

Connect-DbaInstance by dbatools.io can be found in dbatools.io - i cant post links yet...

I think it's keep the SMO SQL connection object is staying even though I am closing the connection using
ConnectionContext.SqlConnectionObject.Close()

[Alexander Riedel]

Try
[System.Diagnostics.Process]::GetCurrentProcess().Kill()

[jvierra]

I think it's keep the SMO SQL connection object is staying even though I am closing the connection using
ConnectionContext.SqlConnectionObject.Close()

A SQL connection cannot block a process exit. Connections are globally cached to the process and get called to close and destroy when a process is exiting. More likely the connection attempt is hanging due to network issues so the process is blocking and the close events do not get executed.

[Alexander Riedel]

You should also wait. Some .NET processes take quite a some time to close. If you have a network timeout it can take 20- 30 seconds

[jvierra]

SQLServer connection failures can take 2 minutes to timeout. Other network connection operations can take as much time. In rare instances a connection attempt can hang indefinitely which indicates a configuration error or a failure of some kind. In my experience these are hard to troubleshoot without advanced methods. The first step is to isolate the issue by using a loop in a simple script to try to force this. Often this fails. Network sniffers can trap the history of connections and produce detailed tracing that can help. These issues are almost never related to any application. They are network and server relative.