Posts in Category "Forms"

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 Forms ES: text-overlapping on page break using nested subforms


If you are using LiveCycle Forms ES to render complex XFA forms as PDF and the forms contain subforms/tables which can split over multiple pages, you may notice some text-overlapping following a page break as follows:


You can use some processing instructions in the XDP template to control how the page break affects the field content.  There are 2 processing instructions that can be used in this case to fix the text-overlapping issue, so that the contents no longer overlap the field boundaries:

<?layout allowDissonantSplits 1?>
<?layout allowJaggedRowSplits 1?>

You should add these PI’s to your XDP templates only if you are encountering the issue described above.  You can test these PI’s in LiveCycle Designer ES by using the PDF Preview tab.

By adding these PI’s the text-overlapping is resolved and appears as follows on the rendered PDF form:

reference: (182616383/2959283)

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

LiveCycle Forms ES: read-only pop-up menu values modified when navigating through XHTML forms


The values in pop-up menus change when you move between pages on an XHTML form rendered from an XDP template with LiveCycle Forms ES.  Some drop-down lists (DDLs) show the empty value, whereas others actually have a different entry from the original value.

This behavior is not expected, as the drop-down lists are marked as read-only. This issue is serious, as it affects data integrity in the submitted forms. You can test this behavior using FormsIVS in LiveCycle ES with the NoScriptXHTML transformation.


Adobe has resolved this issue in LiveCycle ES and 10.  There is a patch available for LiveCycle ES 8.0.1, so contact enterprise support if you require this patch in your environment.

reference: (181801041/2734988)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 9.0/10 (1 vote cast)

LiveCycle ES: warning in server log when passivating document


A Form Guide stitches a PDF from multiple XDP fragments and then returns the PDF to the process in LiveCycle ES 8.2.1 or 9. When you submit this Form Guide, a warning appears in the server log:

[12/18/09 15:34:08:003 EST] 0000015a SystemOut
 O XDP form1.xdp,form2.xdp,form3.xdp,form4.xdp,form5.xdp,form6.xdp
[12/18/09 15:34:08:004 EST] 0000015a SystemOut O OPS form1.xdp
[12/18/09 15:34:08:234 EST] 0000015a AdobeCacheImp W com.adobe.repository.cache.AdobeCacheImpl put Document error while passivating document [<document state=”passive” senderVersion=”3″ persistent=”false” senderPersistent=”false” passivated=”true” senderPassivated=”true” deserialized=”true” senderHostId=”″ callbackId=”0″ senderCallbackId=”4228″ callbackRef=”com.adobe.idp._IDocumentCallbackStub:


This warning is an informational message from the repository cache and can be ignored. In the ADEP platform (ES3) Adobe will downgrade this warning to an INFO or FINE level message, so it doesn’t appear in the logs.

reference: (181308950/2523516)

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

LiveCycle ES2: renderPDFFormWithUsageRights() doesn’t respect locale settings


When you use the renderPDFFormWithUsageRights() method to render and reader-extend PDF documents, there are issues with the locale on the resulting PDF form.

For example, if you use this method to render XDP documents with German locale settings, then those settings are lost. Numeric fields are rendered using the default English locale. If you enter 4555 in a decimal field, it is displayed with the English locale 4,555.00, rather than 4.555,00 in the German locale.


In LiveCycle ES2 (, specify the default locale in the AdminUI under the Forms service Internationalization settings to handle all cases for your default language. For XDP templates that deviate from your default language, specify the language on the field/subform level in the XDP, or in the PDFRenderFormSpec setLocale() method.  These settings will then override the default locale.

Additional information

There are a few ways to define the locale for a form rendered through the Forms service in ES2.

  • AdminUI
  • PDFRenderFormSpec
  • XDP form-level
  • XDP field/subform level

The default locale for rendered forms is configured in the AdminUI under Home > Services > LiveCycle Forms ES2 > Internationalization. If  no locale is specified in the PDFRenderFormSpec in the API or render call, then the form is rendered in the default English locale.

Similarly, you can specify a default locale in the XDP form template with LiveCycle Designer. You can also specify the locale on a field/subform level within the XDP template by using “default” (which inherits the form-level locale). You can also explicitly define the locale in the field/subform properties.

LiveCycle ES2 ( ignores the form-level locale and respects the locale hierarchy as follows: field/subform, then PDFRenderFormSpec, then AdminUI.  This means that a locale (locale 1) specified on the field/subform level will override any different locales (locale 2) specified in the PDFRenderFormSpec and AdminUI. The individual field/subform will then be rendered in the final PDF with locale 1, and the rest of the form with locale 2. It is a product bug that the form-level locale is ignored.

In LiveCycle ES2 SP2 and later versions, Adobe has added add an “Auto” value to the PDFRenderFormSpec setLocale() method, which respects the XDP form-level locale. Then, the locale hierarchy is as follows: field/subform, then form-level, then PDFRenderFormSpec, then AdminUI.

reference: (181618235/2634790)

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

LiveCycle ES: what is the AdobeFnt11.lst file?

The AdobeFnt11.lst file is created by the XMLForm process when CoolType is started and the fonts are enumerated.  The file is used when generating PDF, Postscript, PCL and ZPL output to find the correct fonts for the document content.

If you have added a font and it is not being picked up you can force an update on the file by stopping the XMLForm process (e.g. manually in task manager), deleting the file and then restarting the XMLForm service (e.g. by re-starting the original document generation/conversion process). The AdobeFnt11.lst file will be recreated with all of the new fonts added. Normally you don’t have to do this, as the new font should be located and added automatically.

PDFMM also uses this file, as it deals with PDF files, which also use fonts.

reference: (181025376/2371040)

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

LiveCycle Forms ES: Select which fonts get embedded at render-time


If you would like to control which fonts should be embedded in the final PDF when rendered using LiveCycle Forms ES, then please follow the steps below.


This could be a common requirement if you are producing PDF documents for multiple environments:

  1. the internal environment, where the user’s systems have all of the fonts available already
  2. the external environment, where you would need the additional fonts to be embedded

At render-time, you know which environment is making the call, but do not know how to control the fonts which are getting embedded.


The XCI file, or XCI options string in FormsIVS, is what controls the render options used by Forms. To control what fonts are embedded, you must create your own custom XCI file, and pass that as a parameter to the renderPDFForm method, or as an option to FormsIVS. There are two options which you can use in the XCI file to control what fonts get embedded (alwaysEmbed), or what fonts do not get embedded (neverEmbed).

1. Copy the default pa.xci file and create a custom.xci file (for the purposes of this example, we will assume you create the custom.xci file on the root of the D drive)

2. Set the value for alwaysEmbed/neverEmbed as follows in the custom.xci file:


3. Call the renderPDFForm method setting the XCIURI property, or FormsIVS with the following parameter in the options String:


or on some platforms:


By editing the custom.xci file manually you will be able to generate PDF files controlling the fonts which are embedded. You could generate multiple XCI files for various environments and just call the respective XCI file to use for each document.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 9.0/10 (1 vote cast)

LiveCycle Forms7: FormServerException: java.lang.IlgalStateException: Connection to failed service


 FormsIVS was installed and working fine on one Solaris box.  When trying to use the FormsIVS interface from other Solaris boxes the following exception occured:


com.adobe.formServer.interfaces.FormServerException: java.lang.IlgalStateException: Connection to failed service.

at ros.core.technicalservices.service.docgen.ejb.impl.DocumentGenerationManagerBean.generateViewablePDF


 This is because the following packages were not installed on the other Solaris servers:

SUNWxwplt, SUNWxwpltx, SUNWxwrtl, SUNWxwrtx

These pacakages install into:






 Installing these packages to the other Solaris servers, and making sure the file is on the classpath will resolve the issue.

reference: (1-32957277)

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

LiveCycle Forms7: how to disable client-side caching


 If you are using FormServer 7.1 you may want to disable client-side caching.  This will prevent previously entered values from appearing on a new form when you open it in a fresh browser instance.


The problem is that Acrobat/Reader is caching the form (along with its data). It does this based on the URL address (same URL = same form/data). Unfortunately, since this is a client setting there is no easy way to disable it.


Here are some suggestions to achieve this:

1) on the form (i.e. will be on a form by form basis):

add this code into the form:ready event –

var oDoc =; 

oDoc.nocache = true;

2) make the URL unique:

An easy way of doing this is to return a date/time stamp as an unused parameter in the URL. This can be easily added by either the JSP or the servlet. For example:


3)  Also consider setting the cache control headers in your response:

// Set content to expire far in the past. 
response.setHeader("Expires", "Thu, 1 Jan 1970 12:00:00 GMT"); 

// Set standard HTTP/1.1 no-cache headers. 
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate"); 

// Set special IE extended HTTP/1.1 no-cache headers (use addHeader). 
response.addHeader("Cache-Control", "post-check=0, pre-check=0"); 

// Set standard HTTP/1.0 no-cache header. 
response.setHeader("Pragma", "no-cache");


reference: (1-28022235)

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

LiveCycle Forms7: importXMP() throws a PDFOperationFailure if the data contains accented characters


 If you are using the importXMP() method from the FormServer 7 API to import XMP metadata to a PDF you may receive a PDFOperationFailure exception in the log similar to the following:

[11.07.06 13:55:50:837 CEST] 16fd9246 SystemErr R omniORB: WARNING --method 'importXMP' 
on: root/req-66<16777216> raised the exception: IDL:com/adobe/document/pdf/PDFOperationFailure:1.0
[11.07.06 13:55:50:838 CEST] 31281245 SystemErr R
org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x0 minor code: 0 completed: Maybe
[11.07.06 13:55:50:838 CEST] 31281245 SystemErr R
[11.07.06 13:55:50:838 CEST] 31281245 SystemErr R


This exception is caused by accented characters in the XMP metadata.  Removing the accented characters will allow the importXMP() to complete successfully, so there is obviously a problem with the encoding.


 You may be using the following code to generate the data:


To resolve the issue you must set the encoding to UTF-8 if there are accented characters:


reference: (1-27943601)

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

LiveCycle 7: how to create a WebDAV connection to the Forms appstore


 You can use Web Folders to browse the appstore from FormManager, or to publish forms directly from Designer, however you may encounter problems trying to connect to it using the following URL:



You will need to apply this fix first to enable Web Folders on your system: (Follow method 2)

Then follow these instructions to connect to the WebDAV server:

For XP and W3K:

1.) Navigate to My Network Places

2.) Select Add a network place

3.) Enter http://<server>:<port>/appstore/Forms

4.) When prompted enter the username and password of a user that has the roles of Adobe Administrative Console User and LiveCycle Form Manager Administrator.

5.) You will be prompted for the credentials once again then the add network wizard will display a panel letting you identify a name for the network place.

6.) Select Next

7.) Select the check box to open this connection and select finish.

8.) You have now a webdav connection to the root of the appstore and can publish forms directly to it.

You can then use this Network place directly from Designer to publish/edit forms in the appstore.

reference: (1-22309006)

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