Dual Dialogs when Defer & CloseApps are Specified & a Process is Running

The Toolkit General Discussion
1

I’ve noticed that when when the following options are specified

  • CloseApps option is specified, populated with 1 or more processes and one of those processes is running
  • AllowDefer and -DeferTimes are specified

For example:

Show-InstallationWelcome -CloseApps 'notepad' -AllowDefer -DeferTimes 3 -CheckDiskSpace -PersistPrompt -BlockExecution -CloseAppsCountdown 3000

I receive two dialogs with defer & continue options.

The first dialog looks like this:
PSADT_1

The second dialog looks like this:
PSADT_2

I’m perfectly happy & comfortable to go diving into the code, but before I go down that route, I wanted to seek an understanding:
Is this normal & expected behavior?
If yes, would you help me to understand why that is? My brain is struggling to wrap around what I’m seeing:

  • If I click ‘Close Process’ on the first dialog, I don’t get the second.
    Why don’t I receive the second dialog?
    Why is this path different?

  • If I click ‘Continue’ with the process still open, the dialog reappears.
    This is normal & expected behavior.
    But if I close the process & ‘Continue’ on the dialog, I still get the second.
    I already said ‘Continue’ so why does it ask again?

Steps to Reproduce:

  1. Use stock 3.8.2 toolkit
  2. Modify first Show-InstallationWelcome dialog to close one process (e.g.: iexplore; notepad etc.) and allow deferrals.
  3. Launch the process you specified in the close apps in the script & leave it running
  4. Run Deploy-Application.exe
  5. Receive first dialog shown above
  6. Manually close the process
  7. One of two things happens:
    (a) More often than not the first dialog disappears automatically which is great I think :slight_smile: or
    (b) The dialog stays open log enough for one to click ‘Continue’ to allow the installation the proceed - which is what I want to have happen.
  8. Second dialog appears

The PSADT logs look like this

PSADT_3
PSADT_31503×347 36.6 KB

Text version of the PSADT log follows

|[Pre-Installation] :: Get deferral history...|Get-DeferHistory|10/5/2020 1:47:38 PM|22788 (0x5904)|
|---|---|---|---|
|[Pre-Installation] :: Return fully qualified registry key path [Registry::HKEY_LOCAL_MACHINE\SOFTWARE\PSAppDeployToolkit\DeferHistory\PS_AppDeployToolkitMain_3.8.2_EN_01].|Convert-RegistryPath|10/5/2020 1:47:38 PM|22788 (0x5904)|
|[Pre-Installation] :: Registry key [Registry::HKEY_LOCAL_MACHINE\SOFTWARE\PSAppDeployToolkit\DeferHistory\PS_AppDeployToolkitMain_3.8.2_EN_01] does not exist. Return $null.|Get-RegistryKey|10/5/2020 1:47:38 PM|22788 (0x5904)|
|[Pre-Installation] :: User has [2] deferrals remaining.|Show-InstallationWelcome|10/5/2020 1:47:38 PM|22788 (0x5904)|
|[Pre-Installation] :: Check for running application(s) [notepad]...|Get-RunningProcesses|10/5/2020 1:47:38 PM|22788 (0x5904) <- PSADT checks to see if one of the specified processes is running|
|[Pre-Installation] :: The following processes are running: [notepad].|Get-RunningProcesses|10/5/2020 1:47:39 PM|22788 (0x5904) <- PSADT sees that one of the specified processes is running|
|[Pre-Installation] :: Resolve process descriptions...|Get-RunningProcesses|10/5/2020 1:47:39 PM|22788 (0x5904)|
|[Pre-Installation] :: Prompt user to close application(s) [Notepad]...|Show-WelcomePrompt|10/5/2020 1:47:39 PM|22788 (0x5904) |
|[Pre-Installation] :: User has the option to defer.|Show-WelcomePrompt|10/5/2020 1:47:39 PM|22788 (0x5904) <- PSADT displays the first dialog giving me the option to close the processes, defer or continue|
|[Pre-Installation] :: The running processes have changed. Updating the apps to close: [Notepad]...|Show-WelcomePrompt|10/5/2020 1:47:41 PM|22788 (0x5904) <- I quickly closed the application/process and …|
|[Pre-Installation] :: User selected to continue...|Show-InstallationWelcome|10/5/2020 1:47:46 PM|22788 (0x5904) <- I quickly clicked continue in the first PSADT dialog|
|[Pre-Installation] :: Check for running application(s) [notepad]...|Get-RunningProcesses|10/5/2020 1:47:48 PM|22788 (0x5904) <- PSADT checks to see if one of the specified processes is running|
|[Pre-Installation] :: Application(s) are not running.|Get-RunningProcesses|10/5/2020 1:47:48 PM|22788 (0x5904) <- PSADT correctly confirms the processes are not running! Although, I’m not sure it’s necessary but I am ok with it.|
|[Pre-Installation] :: User has the option to defer.|Show-WelcomePrompt|10/5/2020 1:47:48 PM|22788 (0x5904) <- PSADT displays the second dialog giving me the option to defer or continue.  But why?  I already clicked continue above. |
|[Pre-Installation] :: User selected to continue...|Show-InstallationWelcome|10/5/2020 1:48:12 PM|22788 (0x5904) <- I click continue again and it actually executes.|
|[Pre-Installation] :: [-BlockExecution] parameter specified.|Show-InstallationWelcome|10/5/2020 1:48:14 PM|22788 (0x5904)|
|[Pre-Installation] :: Create scheduled task to cleanup blocked applications in case installation is interrupted.|Block-AppExecution|10/5/2020 1:48:17 PM|22788 (0x5904)|
|[Pre-Installation] :: Retrieve Scheduled Tasks...|Get-ScheduledTask|10/5/2020 1:48:17 PM|22788 (0x5904)|
2

If the specified processes are running then the toolkit lists them but it keeps checking them in the background every couple of seconds. Once they get terminated, it changes the window to not confuse the user that the processes are still running. If you were to start the again, the window would show it again. This is normal. Also, use the latest version - 3.8.3.

3

Thanks for taking the time to reply, I really do appreciate it.

I hear you. The scenario you describe is valid & makes perfect sense:

  1. If a key process is running, PSADT displays a prompt asking the user to make a decision.
  2. While the prompt is up, PSADT will keep checking in the background to see if the process is now gone.
  3. If the process is no longer running, the dialog is adjusted to show only the relevant options.
    Again, that is a realistic scenario that’s completely valid & in fact works great! We love it!

However, I’m referring to a different scenario. As they say ‘the devil is in the details’ which are conveniently in the logs themselves. I tried to highlight that in the original post but in short:

  1. A key process is running before the PSADT installer is launched
  2. The PSADT installer executed
  3. PSADT displays the first prompt informing me that a key process is running and it asks me what to do - EXPECED
  4. The process is closed outside of PSADT (i.e.: I closed it manually) - POSSIBLE VALID SCENARIO
  5. The first prompt is still present so I click ‘continue’ on the first prompt because I’m ready for PSADT to proceed with the installation now that the process is closed - POSSIBLE VALID SCENARIO
  6. The first PSADT prompt disappears - EXPECTED
  7. In the PSADT logs it confirms ‘user selected to continue’ - EXPECTED
  8. In the PSADT logs it confirms a key process isn’t running - EXPECTED - At this point the installation should ‘continue’ because (a) I clicked continue on the first prompt & (b) no key processes are running
  9. PSAD displays a second prompt asking me if I want to perform the installation - UNEXPECTED

In this second scenario should a user be expected to click ‘Continue’ twice when no key processes are running at the time the user clicked ‘continue’? If yes, this is expected, what’s the reasoning behind that? Again, I’m just here to seek an understanding for a behavior we can reproduce at will across a few versions of PSADT.

4

No there shouldn’t be two windows. Once you click continue/close processes, it should not be opened again. However there is a bug there currently with the logic that closes the processes. Sometimes they dont get closed after clicking the button and so the window reappears since it didnt close them. Not sure if this is related to your issue though. Internet Explorer is a typical process that fails to be closed sometimes. We will rewrite the logic when we replace the UI with a more modern one in the v4.

5

Good Morning & Happy Friday to you.
Thank you for taking the time to reply. My sincere apologies for not replying sooner.

Don’t spend a lot of time on this - it’s not critical :slight_smile: And having really thought about this for a while now, I’m thinking that our users are likely to just click ‘close’ which doesn’t manifest in this behavior.
Being quite comfortable in PowerShell, I’ll take a look in my spare time to see if I can offer a potential snippet of code that can be easily slipped in.

Thanks again. Take care, be safe & have a great weekend

6

I think the fix will be just to close the processes by name not by ID. I am already working on a patch that will implement that. Thanks for the info though.

1 Like
7

If it was still detecting the process, then it would be listing that process that needs to still be killed like the first pop-up. If I don’t close the app and click “continue” it will re-pop up with the process(es) still open.

This looks like it’s handling the -defer flag twice, once for the close apps and once like it was standalone.

8

It checks processes by name but then uses cached instances of those processes to close them by ID.

This PR will change that: https://github.com/PSAppDeployToolkit/PSAppDeployToolkit/pull/577