Release file locks

[JuniorJr]

Hi,

When I try to do some testing where I have to rebuild packages, and/or remove sandboxes... I always get the "Cannot delete... File is in use".

I close the ThinApps that I have open, I've even waited a day just to see if that would release the locks, but it doesn't.  So, each time I have to remove a sandbox, or update a build, I have to log off my test machine. That releases it.  Is there an easier way?  maybe terminate specific processes?

Thanks in advance

[doofkopf]

Hello,

you have to look after you Programm Process in the Taks Manager, in many cases the Program you Virtualize do not close korrekt.

You can write a Script to close the Prozess.

[JuniorJr]

Thanks

I do see the apps close - for example, when I open Outlook 2010, I do see the Outlook.exe process close when I close the app.  There must be other processes that must be closed I assume.  I do see other VMware processes, but I think they are related to VMTools, and VMware workstation processes.  Are there any others related to ThinApp that I need to check for?

.

[doofkopf]

No nothing from VMWare that must be a Office ore Related Prozess

[Phil_Helmling]

Are you using VMware workstation shared folders to host the packages? If so, thats the problem. I shutdown my VM after the capture/test and it releases the file locks.

Painful, but still quicker than packaging on a physical box.

Phil

[JuniorJr]

Hi.

Actually, for my testing, no shared folders and everything is local to the VM.  Even the sandbox.  I start simple then "complex it up".

Thanks for the response.

[Phil_Helmling · Accepted solution]

does this blog entry help?

http://blogs.vmware.com/thinapp/2011/04/whats-keeping-my-sandbox-locked.html

[Theike]

There are several ways to prevent apps from 'locking' your system.

Several processes are well known in this issue, like ctfmon.exe or mdm.exe. As these are not essential to the virtualised application these can be easilly 'deactivated' by adding them to the process exclusion list, so they are always run natively.

Additionally there might be less obvious ones, like MS Word. Initially you open a document from your virtualised application (so the native installed word runs within your virtualisation context). Next while that document is open you open a new/existing one natively (you double-click on a document from the explorer). You would expect this document is opened in a native version, but Word tries to save resources and extends the running instance to also edit the new document, so it also runs virtualised. When you close the app and the document (the initial one), your sandbox is still locked by the latest document...

The later issues can be solved by adding word to the exclusion list as well, but if plugins have to be loaded which are only available within the virtualisation context, you will have an issue...

Kind regards, Michael Baars

Comprehensive ICT Solutions (Weert, NL)

Please remember to mark a question anserwed if so and reward points to those who helped you...

[JuniorJr]

Thanks everyone... process explorer helped. Let's me see (and kill) what is truely holding on to those files/folders.

[shrivastavaa]

Just one suggestion, in case you really want to know who is holding up locks on sandbox,  launching log monitor will help in determining that. It will give you list of all process named/ID which are run virtualized and most probably be holding the lock. Few process which we generally ignore but they do lock it are svchost.exe, taskhost.exe etc.

If your VM OS is windows 7, it actually prompts you and tell you who is blocking the file.

So for testing one application, you may launch it with log monitor once, notice what all process are executed, write a script to close them. and start testing them usual (with out logmonitor ), from next instance.