$theTitle=wp_title(" - ", false); if($theTitle != "") { ?>
About Virtualization, VDI, SBC, Application Compatibility and anything else I feel like
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).
Problem summary
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.
Problem details
Google Earth uses various synchronization objects such as Events and Mutexes but registers those in the \Global namespace instead of the \Local namespace.
MSDN is quite clear on Kernel object namespaces:
“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. There is a global namespace used primarily by services in client/server applications. In addition, each client session has a separate namespace for these objects, such as in Windows Vista.”
And
“The separate client session namespaces enable multiple clients to run the same applications without interfering with each other“.
That last line is key, as that’s exactly what’s happening here!
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.
The easiest solution therefore is to modify the api call using a mechanism called Api Hooking. From an Api Hook the \Global namespace can be replaced with \Local.
The most common method for Api Hooking is Dll Injection.
Security
Although Api Hooking can be used for doing Evil (e.g. a rootkit) it’s also essential for virtualization. Application virtualization (e.g. ThinApp or App-V) relies on Api Hooking and couldn’t exist without.
There is of course a risk that an Api Hook mechanism could be abused (e.g. someone replaces the Dll that is injected and thus the payload) or that antivirus programs will prohibit the injection.
Google Earth Fix v1
In the first version of my Google Earth fix I avoided Dll Injection by using a loader program. This loader would emulate a debugger and launch Google Earth as a child process (a debuggee).
As a debugger, it is perfectly valid to do typical debugger operations such as settings breakpoints, changing memory and writing in the memory space of a process that is being debugged.
This approach worked well but was more difficult to maintain as newer OS versions such as Server 2012 and Server 2016 had subtle changes in the assembly code of Windows Api functions.
In short: my fix broke on new OS releases and had to be modified each time.
Google Earth Fix v2
For this reason, I started thinking about a smarter, easier to maintain, approach and these were the design criteria:
This has resulted in a solution based on 2 components:
The driver needs be signed with a, kernel mode, code signing certificate. This is a normal Windows security requirement since Windows Vista.
This protects against any alterations of the driver
For further security, the driver will only inject a Dll that has been signed by the same code signing certificate as the driver itsself.
This protects against any alterations or replacements of the Dll
Easy Installation
To make it eas easy as possible to use the fix I have created an MSI installer for it. The installer will install the driver and configure it to inject only into the Google Earth process.
The installation directory is C:\Program Files (x86)\Remko Weijnen\Application Compatibility\ and in this directory you will find the driver and dll.
Uninstallation is of course supported and will stop and remove the driver before removing the files.
Verify
If you want to verify the driver installation you can check if it’s running with sc query= AppCompatDriver
Using Process Explorer you can easily verify if the Dll has been injected into Google Earth. Active the Lower Pane with the View Dll’s options (Ctrl-D) and select the Google Earth process:
Supported Platforms
The fix has been tested on the following platforms:
7 Responses for "Google Earth fix for XenApp, RDSH & Horizon"
When i install this fix on the citrix image and then stream it to different servers it will not work. Only one instance of google earth can run. When i make a repair on th eclose image and does not reboot i will work….but thats no opinion…do you have an idea ?
Did you check if the driver is running after reboot? Alternatively run the install tool as a startup script. What is are you running?
This does not persist after reboot
I used this in conjunction with the Google Earth 7.3 latest version and it crashes on startup for even a single user on server 2016. When I fell back to the 7.1 version in their download history it does work however. Any ideas how to make it work with 7.3 or can you look at what tweaks need be done to make 7.3 work?
Based on previous comments I didn’t try it with the 7.3 version of Google Earth, but I can confirm this works on 7.1. Thank you so much!
Would you also provide the source code to the driver?
My experience: on Windows Server 2012 R2 and Google Earth Pro 7.13 the DLL isn’t injected (Maybe because is PRO?). With Goggle Earth 7.1 it does work but not persist after reboot (I have solve with a task schedule at startup (1 minute delayed): msiexec.exe /f {35CFF98F-3055-4C65-91BC-D4F15DE4D9C7}.
Any ideas how to make it work with 7.3?
Please….provide the source code… 🙂
Modifica
My experience: on Windows Server 2012 R2 and Google Earth Pro 7.13 the DLL isn’t injected (Maybe because is PRO?). With Goggle Earth 7.1 it does work but not persist after reboot (I have solve with a task schedule at startup (1 minute delayed): msiexec.exe /f {35CFF98F-3055-4C65-91BC-D4F15DE4D9C7}.
Any ideas how to make it work with 7.3?
Please….provide the source code… 🙂
Leave a reply