LiveCycle ES2: XMLForm.exe terminated abnormally with error code {3}


If you are using LiveCycle to process PDF documents you may encounter problems displaying/converting forms or PDF documents, accompanied by exceptions similar to the following in the server log:

ProcessResour W com.adobe.service.ProcessResource doProcessExitCleanup BMC024: Service XMLFormService: Process ProcessResource@f1f45(name=XMLForm.exe,pid=0) terminated abnormally with error code {3}

XMLFormAgentW E com.adobe.livecycle.formsservice.logging.FormsLogger logMessage ALC-OUT-002-004: Unable to find service: XMLFormService, error: Connection to failed service.


The error message “XMLForm terminated abnormally with error code {3}” can occur in various situations, and the relevant solutions are described below.

1. The LiveCycle font directory is not valid

In this situation you should see a warning or error in the server log during startup similar to the following:

FontManager   E com.adobe.fontmanager.FontManager loadFromFontDirectories ALC-FMR-001-009:FontManager: Null/Non-existent font directory : /opt/server   /resources/fonts

When configuring LiveCycle you can enter a directory where fonts are stored and can be used by LiveCycle.  If this directory is not valid when calling XMLForm it can result in the error code {3}.

You can modify the location of the font directories in the administration console under Settings > Core System Settings > Configurations.  You will need to restart the application server after modifying these settings.

Further details here:

2. The LiveCycle root directory contains “null” in the path

This can occur particularly on Weblogic installations.  You should explicitly set the path using -Dadobeidp.RootDirectory=<path> in the server startup script.

Further details available here:

3. Solaris 10 Update 10 has been applied

If you have recently applied Solaris 10 Update 10 XMLForm may start failing with error code {3}.  There is a compatibility issue between the compiler settings that Adobe uses to compile the XMLFormService and some additions that Oracle have made to Solaris to support GNU extensions to their ELF symbol versioning.  What this means is that Solaris no longer recognizes XMLFormService as a valid executable and will not run it.

The best solution here is to update Solaris to a more recent version that contains the fix.  Details on exact versions can be attained from Oracle.

A workaround is to disable the run-time linker check by removing the DT_VERSYM entry from the objects dynamic section in

To apply the workaround you should run the following command on the file found in ServicesNatives2/lib directory:

% elfedit -e 'dyn:delete versym'

The workaround should only be applied by a sysadmin in critical situations, as it is a system change that may cause other side-effects.  You should make a backup of the original file before making that change.  Further details here:

You can find further details here:

4. WebSphere global security is turned on

In this situation you will most likely see the following exception also in the server log:

CSIServerRIBa W   JSAS0638E: [] Client authentication required at the server but no principal information is present in the <server>:<port> method request from client {2}.

We have seen this issue occur when strict global security was turned on in WebSphere and the clientcertificateauthentication for the csiv2inbound property in the WebSphere configuration was set to “Required” instead of “Supported”, and when the transport was set to “SSLRequired” instead of “SSLSupported”.  Change these to “Supported”, as shown below, to resolve this issue.

<csiv2inbound basicauthentication=”Supported” clientcertificateauthentication=”Supported” identityassertion=”false” stateful=”true” transport=”SSLSupported” sslconfigalias=””/>

<csiv2outbound basicauthentication=”Supported” clientcertificateauthentication=”Supported” identityassertion=”false” stateful=”true” sessiongcinterval=”300000″ sessiongcidletime=”900000″ transport=”SSLSupported” sslconfigalias=””/>

Further details here:

5. SELinux security is in “enforcing” mode

If LiveCycle is running on a server where NSA Security Enhanced Linux (SELinux) is in enforcing mode, XMLForm will terminate with error code {3}.

To correct this problem, change SELinux security to permissive mode.

6. Other native library problems

To investigate native library problems you should enable debugging on the XMLForm process as follows:

  • On Unix/Linux deployments locate <XMLFormService/bin>/XMLForm.exe shell script and edit using a text editor.
  • Navigate to end of the file and you should see an “exec” line.
  • Modify “exec” line to include Corba debug parameters and add ldd/env commands before “exec” line as shown below.
 ldd $myPath/bin/XMLForm > /tmp/XMLForm.ldd_dump.txt
 env > /tmp/XMLForm.env_dump.txt
 exec $myPath/bin/XMLForm $* ORBtraceLevel 40  -ORBtraceThreadId 1
  • After that either restart your app server or kill XMLForms process instance(s) if running.
  • Render a form using FormsService or OutputService and new instance of XMLForms process should get launched.
  • Analyze the ldd_dump.txt, env_dump.txt, StdOut and StdErr logs looking for errors related to loading native shared libraries and/or Corba debug messages.

You can find further details on debugging in XMLForm here:

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)
LiveCycle ES2: XMLForm.exe terminated abnormally with error code {3}, 10.0 out of 10 based on 1 rating

One Response to LiveCycle ES2: XMLForm.exe terminated abnormally with error code {3}

  1. Pingback: LiveCycle ES2: XMLForm.exe terminated abnormally with error code {3} |