Adobe recently released a secured version of Reader which includes a new security feature called sandboxing. A sandbox restricts the privileges of the PDF viewer built into Adobe Reader to access computer resources, which in turn helps to reduce the impact of as-yet undiscovered security flaws in the PDF viewer, because when these security flaws get exploited, the exploit is much less able to attack the system it is running on. This is a fantastic effort by Adobe and in theory at least makes reading PDFs in Adobe Reader much safer.

Adobe have written a couple of technical blogs about the Reader sandbox design at and More information is also available at

Unfortunately, the release of Adobe Reader X exposed a bug in Keyman Desktop when interacting with sandboxed processes. Interestingly, Chrome and Office 2010 include similar sandboxes but they did not trigger the flaw in Keyman Desktop. In December 2010, we started receiving reports of a crash that initially did not make any sense to us at all: Keyman would crash when shutting down, with an error that it could not “unregister a controller window”. We could not see how the existing release suddenly started failing, given it had been in use for some time without problems. It wasn’t until we received a report from a user of Keyman Desktop that it wasn’t working with Adobe Reader X that we were alerted to the issue ourselves: when I started testing this problem, as well as replicating the inability to type into Adobe Reader X, I suddenly started experiencing the crash that had been reported by other users.

Some debugging and research uncovered the problem that caused the crash – basically, the Keyman Engine keyman32.dll which was attached to the sandboxed Adobe Reader process was unable to communicate with the main Keyman Engine window and left the Keyman Engine in an unstable state. This error state was exposed when Keyman Desktop was shutting itself down and cleaning up.

I have written a fix for the beta of Keyman Desktop 8.0 to resolve the crash and will release an updated beta shortly. However, we have not yet completed development to enable Keyman input into Adobe Reader X while protected mode is switched on, because the way that the process is sandboxed restricts the ability of Keyman Desktop to communicate with the application, and this will take more effort to resolve.

The workaround that both avoids the crash and enables input into Adobe Reader X is to turn off protected mode. While I acknowledge that this is not a wonderful solution, it at least enables you to do your work, and at the very least you are no worse off than when running previous releases of Adobe Reader.

Tavultesoft Knowledge Base Article 69 provides a step-by-step workaround and will be updated when we complete resolution of this problem.

1 thought on “Adobe Reader X’s Sandbox and Keyman Desktop”

Marc Durdin (Tavultesoft) · February 18, 2011 at 3:42 pm

Keyman Desktop is now available which resolves this crash. You can download this from

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts


Mitigation for Keyman, Windows 10 1803, and Amharic, Tigrinya and Sinhala issue

Background It recently came to our attention that under Windows 10 1803 and Windows 10 1809, Keyman keyboards simply do not work when associated with Amharic or Sinhala languages, and sometimes do not work with Read more…

Developing Keyman

The Keyman keyboard input pipeline

This highly technical blog post explains the design rationale for the Keyman Engine keystroke input pipeline on Windows. The intended audience is software developers working on Keyman Engine, and other interested onlookers. In the beginning, Read more…

Developing Keyman

How to send feedback to Microsoft for issues that impact Keyman

We report all issues in Windows that impact Keyman to Microsoft. If a particular issue impacts you, it is very helpful to “upvote” the issue or add further comments about the issue in the Feedback Read more…