Posts tagged "abnormally"

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)

LiveCycleES: “The application has failed to start because omniDynamic403_rt.dll was not found”


When you are attempting to perform a render operation in LiveCycle ES, you may receive the following error in Windows itself:

The application has failed to start because omniDynamic403_rt.dll was not found.
Re-installing the application may fix the problem.

You should then check the server log for any exceptions. You may see the following exception:

Service XMLFormService: Starting native process with command line
-MyPath D:\bea\user_projects\domains\lc_domain\null\adobe\lc_server\XMLFormService................
BMC024: Service XMLFormService: Process ProcessResource(name=XMLForm.exe,pid=0) terminated abnormally with error code {3}

This could also be accompanied with an ALC-WKS-007-040 error in workspace if you are attempting to render into the browser. You may also see another error code in the server log ALC-FRM-001-004, which indicates a problem with the XMLFormService, of FontManager service. You can check that both of these services are running in the admin console for LiveCycle.


The underlying cause of this is that the XMLFormService could not be found. This is due to the “null” entry in the path to the XMLFormService as seen in the exception above. This actually creates a “null” directory on your server’s file system, and will populate it with the native files. However at runtime it cannot interpret this “null” in the path, and so reports that it cannot find the XMLFormService.


You will have to modify your weblogic startup script to set the adobeidp.RootDirectory property.
1. stop your weblogic server and any admin server that might be running
2. find the setDomainEnv.cmd or script and search for JAVA_OPTIONS (this is usually at the end of the file)
3. you will need to add the following argument to the JAVA_OPTIONS:
-Dadobeidp.RootDirectory=<path to LiveCycle Domain>  (e.g. D:\bea\user_projects\domains\lc_domain)
4. save the file
5. restart your weblogic server

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (2 votes cast)