ThinApp Scripts and Killing Lingering Processes


ThinApps occasionally require some special manipulations to get working correctly.  One of the most common issues that I’ve seen with otherwise working ThinApp packages is a failure to close correctly.  Sometimes, even after a ThinApp is closed, a process will be left running that might keep the sandbox undesirably locked or cause issues with re-execution.  An easy way to resolve that issue is with a ThinApp Script.

These scripts can be used to solve all sorts of issues.  A ThinApp Script is just a VBS script that runs at one of four specified points in a ThinApp’s execution.  The vbs script can be named anything, but should be placed as a sibling with the package.ini file (you only get one vbs file though a script can call another script ad infinitum), in the root of the package.  The vbs script will be automatically baked into the package, and each of 4 optional functions will be executed at the appropriate time.  Those functions are as follows:

The OnFirstSandboxOwner function is executed whenever the Sandbox for the ThinApp is opened.  That means that it runs when an entry point to the ThinApp is run, but only when the first entry point is run.  For example, if you look at a typical MS Office ThinApp, this function would run when an Office Application (say Word) is executed.  If Word is left open and Excel is started, this function would not execute again.  After both programs are closed, if Excel (or any other Office Application, for that matter) is run again, this function will run as well.  It only runs when the Sandbox is opened, not every time an entry point is executed.

The OnFirstParentStart function runs whenever an entry point is executed, prior to the actual execution of the ThinApp.  This happens for each entry point, so can happen multiple times per sandbox.  To use the above example, this function would execute when Word is opened and then again when Excel is opened, regardless of the running state of Word.

The OnFirstParentExit function is the converse of the prior function; it runs whenever an entry point is closed.  This function will run every time an entry point is closed, even if that Entry Point has spawned child processes that are still running.  In our example, it would run when both Word and Excel are closed.  This is the function that I’ve used to kill my errant Child Processes.

The final function is to OnFirstSandboxOwner as OnFirstParentExit is to OnFirstParentStart.  The OnLastProcessExit function executes after the final process (be it an entry point or a child) closes and the Sandbox is thus closed as well.  In our example, this function would execute only after both Word and Excel had been closed (as well as after any spawned Child Processes had closed).

So, how do we use one of these scripts to kill an errant process?  The first thing that we must do is determine the name of our target process.  To discover the name of the process, simply add the following line to the [BuildOptions] section of your Package.ini file:


ProcessExternalNameBehaviour=Original


Once you rebuild your package, that will expose the actual process names, rather than just getting the name of the entry point.  Start your ThinApp, then close it and open up Task Manager to look for the process that’s left lingering.

Since we’re planning on killing a process by its name, we want to ensure that we have the correct name.  With your process name identified, you can use the following vbs script to take care of the issue.  Just define “strProcessKill” with whatever your process is named and you’re good to go.  This code snippet is from the VMware ThinApp blog at http://blogs.vmware.com/thinapp/2008/10/using-ie-7-on-v.html.  As you can see, I used this to kill a lingering process from Adobe Creative Suite 5.5.

Beware of unintended Line Breaks due to the width of this blog... if something doesn't look like it should be on a separate line, it probably shouldn't be.



Function OnFirstParentExit



    Dim objWMIService, objProcess, colProcess
    Dim strComputer, strProcessKill
    strComputer = "."
    strProcessKill = "'cs5.5servicemanager.exe'"

    Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
    Set colProcess = objWMIService.ExecQuery ("Select * from Win32_Process Where Name = " & strProcessKill )

    For Each objProcess in colProcess
        objProcess.Terminate()
    Next

End Function

Comments

  1. Tried the above, with no luck.
    vbs script:

    Function OnFirstParentExit


    Dim objWMIService, objProcess, colProcess


    Dim strComputer, strProcessKill


    strComputer = "."


    strProcessKill = "’splwow64.exe’"


    Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")


    Set colProcess = objWMIService.ExecQuery ("Select * from Win32_Process Where Name = " & strProcessKill )


    For Each objProcess in colProcess


    objProcess.Terminate()


    Next


    End Function


    I get this error:

    Source: (null)
    Description: (null)
    File: (null)
    Line 21, Character 4
    At:

    Any idea what is causing this?

    Packaged App: MS Office Enterprise 2007-x86.
    Capture taken: Win XP SP3-x86.
    Problem description: Running any entry point of the above app causes the sandbox folder to lock for at least 4 min, before it can be removed. On Win XP x86, the sandbox folder can be deleted immediately after the last entry point is shut down.

    Offending exe on the host machine (Win 7 x64) named 'splwow64.exe'. Manually ending this process will unlock the sandbox folder immediately.

    ReplyDelete
    Replies
    1. It's been a while since I've done any real work with ThinApp. I'm not sure if a system process (the print spooler) can be killed by a ThinApp package, especially in Windows 7 where UAC might be a factor. Try executing your package with elevated credentials and see if the script works correctly (just to take UAC out of the picture). Sorry that I don't have better advice for you...

      Delete
    2. One more idea - when you clean up your ThinApp package, is there anything in the print spooler folder besides the ThinApp config files? Maybe there's some junk in there that needs to be processed. Alternately, I believe that that folder should not be sandboxed, so check to make sure that it's configured that way... maybe there's some lingering print spool files hanging out in the sandbox.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. "When you clean up your ThinApp package, is there anything in the print spooler folder besides the ThinApp config files?"

    OK, fist FYI, I'm using the latest ver. of ThinApp 5.0.1 to capture changes after the software is installed including ALL MS Office updates.
    In the main captured project folder there are subfolders which I clean before packing and some others I delete completely.

    %AppData% and %Local AppData% are the first ones I clean. I leave inside of them only ##Attributes.ini file.
    I search and clean other subfolders as well for junk files especially in %SystemRoot% folder.
    However, the only folder named "spool" I have found only inside %SystemSystem% and %SystemSystem64% folders.(By the way, I could not locate the printing files/folders in any other place inside the project folder, besides the aforementioned ones. If you know it may exist elsewhere please let me know. I’ll try to remove/modify them and test again.)
    They contain only the ##Attributes.ini file, with the code:

    "[Isolation]
    DirectoryIsolationMode=Merged"

    I have tried to pack the soft with both options when the above spool folders are cleaned/removed from packing and when they are present (by default).
    The behavior is the same. In win 7 x64 the 'splwow64.exe' locks the sandbox folder for about 4 min, before it can be removed. Word and PowerPoint are the only entry points to
    to trigger the execution of splwow64 in the host. Is this related with the fact that I have launched these two on the guest machine before "postscan"?

    Also help file is not functioning correctly.

    when I click the question-mark icon inside the program I receive this warning:

    Microsoft Office Help Viewer, warning
    "There are no help topic available that match your request".
    Again, this problem is visible only when I deploy the virtual package in Win 7 x64 and Win 7 x86. In win XP Pro SP3 this feature is functioning as it should...

    ReplyDelete
    Replies
    1. I'm suspecting some registry keys inside the thinapp project folder are triggering the launch of slpwow64.exe in the host. Which one? I'm not sure...Maybe some registry activity viewer or some tool of that type will show what is causing this.

      Delete
    2. You could try using Process Monitor, but it generates ghastly amounts of data...
      http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

      Alternately, you could try checking the registry files in your sandbox (comparing the sandboxes from when the issue is happening vs. when it's not). I wrote up some notes about that process here:
      http://virtuallyjason.blogspot.com/2012/04/messing-with-thinapps-registry-for-fun.html

      Delete
  4. Jason, thank you for your quick reply...

    I'll look up your article a little later, and see if it's helpfull for my specific situation.However, I managed to solve the sandbox lockup issue by simply putting the "splwow64.exe" file from the 64-bit host OS into the %SystemRoot% folder.
    I built the project with the default settings with the "splwow64.exe" in it
    and the sandbox doesn't lock up anymore on exit. This may be a "quick and dirty" fix, can't be so sure since I'm not a programmer.
    A more ellegant and perhaps "technically correct" way of doing it is to go through thinapp registry modifications...???!!!
    Nontheless, it's working for now and I'll explore better ways of fixing this type of issue as I keep working with this, since I have to fix the
    help option that is not working, still ATM. If you have any suggestion on that please let me know...

    ReplyDelete
  5. Q. If I capture the same app from two different OS versions with ThinApp, is there a way to "merge" the two captures into one project folder?

    Combining files and registry keys from both platforms may solve some glitches or incompatibilities when deploying the virt. package across platforms. I'll have to try this approach if doable.

    Sorry, if the question sounds a little off topic but I wasn't able to find useful info on this topic, on the net as of yet. I hope someone who has done this before can drop me a hint...

    ReplyDelete
    Replies
    1. That's a very interesting question - I've never heard of any way to automatically merge two different captures. In theory, you could do it by hand (perform the two separate captures and then copy files and desirable registry entries from one to the other), but that sounds like a very arduous and error prone process.

      Why not just maintain 2 separate ThinApp packages (one for each OS)? I don't know how you're registering your ThinApps, but it shouldn't be too difficult to modify a login script to check OS and then register the correct version. If you're using Workspace, you may even be able to build that logic into the presentation directly (I know that it can differentiate between Android vs. Windows vs. iOS, but I don't know if it can differentiate between Win XP and Win 7).

      Delete

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Copying VM Folders and Permissions from One vCenter to Another