

In the first version of my Google Earth fix I avoided Dll Injection by using a loader program. someone replaces the Dll that is injected and thus the payload) or that antivirus programs will prohibit the injection. There is of course a risk that an Api Hook mechanism could be abused (e.g. ThinApp or App-V) relies on Api Hooking and couldn’t exist without. a rootkit) it’s also essential for virtualization. The most common method for Api Hooking is Dll Injection.Īlthough Api Hooking can be used for doing Evil (e.g. From an Api Hook the \Global namespace can be replaced with \Local. The easiest solution therefore is to modify the api call using a mechanism called Api Hooking. The Application Compatibility Toolkit has a shim to redirect Global to Local objects, called the LocalMappedObject but it is only applied for file mapping objects so this will not help us here.

That last line is key, as that’s exactly what’s happening here! “ The separate client session namespaces enable multiple clients to run the same applications without interfering with each other“. In addition, each client session has a separate namespace for these objects, such as in Windows Vista.” There is a global namespace used primarily by services in client/server applications. “ A Remote Desktop Services server has multiple namespaces for the following named kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects.

MSDN is quite clear on Kernel object namespaces: Google Earth uses various synchronization objects such as Events and Mutexes but registers those in the \Global namespace instead of the \Local namespace.

So let’s look at the actual issue: the first user on a server is able to launch Google Earth but for any subsequent users on the same server Google Earth fails silently. Both Google Earth and Google Earth Enterprise do not work correctly for multiple users on shared Hosted Shared Desktops (I still prefer to call it Server Based Computing but that’s likely because I’m an oldtimer).
