I see the same issue, you're not alone. This is on a new ThinApp 5 package of Microsoft Access 2003.
Removing a USB key leaves the drive letter as a ghost, which is of course "unavailable" if you try access it.
On a Windows 7 host you can see the ghost drive letters in Windows Explorer. On a Windows XP host you cannot see the ghost drive letters in Windows Explorer, but they exist because the drive letters in question are no longer available to assign to new volumes.
Closing down all V5 thinapped applications is the only way to release the drive letters.
In Windows 7 Resource Monitor you can view Associated Handles for a running process. Looking at the thinapped executable process, I see a whole bunch of SymbolicLink handles like \GLOBAL??\X: (where X is a drive letter). When I remove a USB key the relevant symbolic link handles remain. This might be a good clue for the ThinApp devs ;-)
I have never seen ThinApp 4 packages do this, so I believe it's a new bug in V5.
This bug is a fairly big one because it's very easy to run out of drive letters if you swap out USB keys like I do. Then there's the fact that your drive letters change all the time (recent documents lists don't like that!)
Same behavior in windows 8.x also.
And if the removable drive is ejected before quitting the thinapp V5 application, you may need reclaim the drive letter manually by erasing the registry at :
where x is the ghost drive letter.
By the way, mapped network drive are also affected and cannot be ejected and remain "unavailable" as long as a thinapp V5 application is running.
Same here when testing ThinApp packed software. Can't believe it's still not fixed... Only workaround is to close the handle manually in Process Explorer.
Apparently Thinapp 5.0.1 has the same problem.
I guess that a lot of Thinapp 5.x users are struggling with their removable disks, not knowing it is thinapp 5.x that's messing.
I wonder how come VMware is still not aware of the problem?
Same Problem here. I already migrated many ThinAppss v4 to v5.
Is there a fix or workaround for the Problem?
Same problem in Version 5.1. Seems the developers are not aware of the problem.
I've now made the engineers aware of this issue.. But please, why did you not file a support ticket? Filing a support ticket is the only guaranteed way to make VMware aware of potential issues.. This community is not the official support offered by VMware.
It looks that the latest thinapp release 5.1.1 still mess with the removable drives letter. No fix yet!
Still unfixed in 5.2. Exactly two years since the first post in this thread. More than one year since the engineers were made aware of the issue. No good conclusion can be drawn about the future of this product, specially when this is such a deal-breaker bug.
Same problem here. But a little bit more a problem.
We use ThinApp in a complex network. We have a lot of drives mapped.
But when i have a thinapped application open, with no connection to say U: is still cannot reconnect to another U: while the thinapedp application is open.
We need it, because we have different programs using the same letter to another share (not at the same time)
Please let me now how to fix it.
Same problem with the last version 5.2.2-4828553 and Windows 8.1.
Very annoying !
ThinApp that solve this problem exist in VMware internal. Please contact the official support and request fixed ThinApp.