MED-V: The Case of the Unresponsive Word Window

  • Article

I recently resolved a long standing issue that affected legacy web applications running inside a MED-V 2.0 workspace. Often web applications will trigger documents and other objects that will launch within their respective host application either through an instance of that application via COM or through a special control via ActiveX (like PDF documents.)

On more than one occasion involving one or more application the parent windowed application (usually a legacy version of Internet Explorer) will trigger an application to launch containing critical data sent to that application by way of the web application. Usually this followed a Java process that would crunch some data and then generate a document object, populate the data and then launch the form from within Microsoft Word. What was happening in every case of this issue was – the Word Window never displayed when running inside a MED-V workspace.

Make sure the problem is not resolved with the super-secret hotfix.

First of all, if you are experiencing the occasional disappearing window, there was an out of band hotfix for the Windows XP RDPShell that addressed disappearing windows. You can call up Microsoft support and request this hotfix by its name (KB2446473.) However, this only addresses a flaw in the RDPShell and did not likely apply in the cases I mentioned above because these problems were not intermittent. They were very consistent and could be reproduced consistently.

Tracking it down . . .  

Running the workspace in full screen mode never exhibited the issue. This issue only occurred when running in the seamless mode of MED-V. Launching a parallel command prompt in the workspace and running tlist.exe revealed that the WINWORD.EXE process was running so the application was not crashing. Killing the MEDVGUEST.EXE process from a command prompt prior to attempting to reproduce the problem caused the issue to go away as well. This led to me down the path of investigating what was really going on. The active Word window was being sent behind the browser window and was not being brought to the foreground for the RAIL mechanism used by MED-V to display the active window. Further debugging revealed LockSetForegroundWindow as a common denominator. Some research into the SetForegroundWindow function (https://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx)  and/or LockSetForegroundWindow function (https://msdn.microsoft.com/en-us/library/ms633532(VS.85).aspx)  yielded a way to control this.

  • HKEY_CURRENT_USER\Control Panel\Desktop 
  • Value: ForegroundLockTimeout
  • Data Type: DWORD

Reference: https://technet.microsoft.com/en-us/library/cc957208.aspx

If the time required to launch the Word application window is less than the value specified in the ForegroundLockTimeout, the application will be launched behind the Internet Explorer window.

If the time taken to load the Word window is greater than the time set in ForegroundLockTimeout registry key, the window will be launched on top of Internet Explorer. Setting this value inside the workspace to 0 resolved the issue.

While this may likely resolve all instances of this type of problem bear in mind that I also learned that if the base priority of Internet Explorer is higher than the Microsoft Word window, it will still be launched behind the Internet Explorer window to avoid active window focus change.