# FRM-92101: There was a failure in the Forms Server during startup > Source: https://netray.co/erp-help/ebs-frm-92101-forms-server-startup-failure-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer FRM-92101 fires when the browser cannot complete the handshake with the Forms listener servlet, almost always because the Forms server process did not start, formsweb.cfg or jserv.conf has a bad entry, or a client-side Java/JRE version mismatch is blocking the applet. Check the apps tier Forms log first, then the client Java version, then the config files. ## Kind error ## System oracle-ebs ## Erp Oracle E-Business Suite (11i / R12 / 12.2) ## Module Forms / Application Tier ## Query FRM-92101 There was a failure in the Forms Server during startup ## Alternate Queries - FRM-92101 EBS forms will not launch - Oracle EBS forms server startup failure fix - FRM-92101 invalid configuration look at web-server log file ## Applies To Oracle E-Business Suite 11i, R12.1, R12.2 (Forms 6i, 10g, and 11g/12c Forms & Reports tiers) ## Steps ### Diagnose and fix FRM-92101 **Items:** On the application tier, tail $INST_TOP/logs/ora/10.1.2/Apache/forms_*.log (or $INST_TOP/logs/ora/11.1.2/Apache for 12.2) for the exact stack trace behind the failure. Confirm the Forms services are actually up: on 12.2 run adopmnctl.sh status and check the FORMS component in $INST_TOP/admin/scripts; on 11i/12.1 check the Forms listener process with ps -ef | grep f60srv or frmsrv. Check formsweb.cfg (11i/12.1) for a bad serverURL, envFile or codeBase entry, or forms-c4ws-config.xml on 12.2 - a stale hostname after a clone or a rename job (adclonectx/adautocfg) is the most common cause. On the client, verify the JRE/JInitiator version matches what EBS expects (check My Oracle Support Note 313800.1 for the certified matrix) and clear the Java cache from the Java Control Panel. If using SSL, confirm the wallet/certificate on the Forms/web tier has not expired and that the browser trusts it - an untrusted or expired cert silently kills the applet handshake. Check ulimit / open file descriptors and available memory on the apps tier - Forms server processes fail to spawn silently when the OS hits a resource ceiling. Bounce just the Forms/web tier services (adopmnctl.sh stop/start FORMS or adstpall.sh/adstrtal.sh) rather than the whole instance to isolate the fix. ## Sections ### Why the error text is misleading **Body:** FRM-92101 is a generic client-side message raised by the Forms applet or the Forms servlet whenever it cannot complete its startup sequence with the server. It almost never tells you what actually broke - Oracle deliberately keeps the client-facing text vague and pushes the real diagnosis to the web-server and Forms server logs on the application tier, which is exactly where you should look first instead of guessing at the browser end. The four most common root causes, in order of frequency, are: the Forms listener/servlet process is not actually running (often after an incomplete autoconfig or a failed bounce), a hostname or port mismatch in formsweb.cfg/forms-c4ws-config.xml after a clone or refresh, an incompatible or corrupted client JRE/JInitiator cache, and an expired or untrusted SSL certificate on an HTTPS-enabled instance. **Code:** - $INST_TOP/logs/ora/10.1.2/Apache/forms_stdout.log $INST_TOP/logs/ora/10.1.2/Apache/forms_stderr.log $INST_TOP/admin/log//appl/admin/log ### Post-clone and post-autoconfig regressions **Body:** The single most frequent scenario reported in customer environments is a database or apps-tier clone where autoconfig ran but the Forms configuration files still reference the source hostname or a stale port because a manual edit was made after the last autoconfig run and then overwritten, or vice versa. The safe fix is always to re-run autoconfig from the context file rather than hand-editing formsweb.cfg, then verify the generated file actually has the new hostname before restarting services - autoconfig template overrides in $AD_TOP/admin/template can silently reintroduce the old value if a customization was applied incorrectly. ### Client-side Java and browser factors **Body:** On EBS versions that still use the Java applet-based Forms client, mismatched or multiple installed JRE versions on the user's machine are a very common cause - the browser plugin picks an uncertified version, the applet fails silently during initialization, and the user only ever sees FRM-92101. Clear the Java Web Start cache (javaws -uninstall or via the Java Control Panel), confirm the exact certified JRE version for your EBS release and OS combination against My Oracle Support's Java compatibility notes, and pin that version explicitly in the browser's Java plugin settings rather than letting auto-update change it mid-project. ## Pitfalls - Restarting the whole application tier instead of checking the Forms-specific log first wastes an outage window without addressing the actual cause. - Editing formsweb.cfg by hand after a clone instead of re-running autoconfig - the next autoconfig run silently reverts the manual fix. - Assuming FRM-92101 is a database-tier problem; in the large majority of cases the database is healthy and the fault is on the Forms/web tier or the client. - Ignoring an expired SSL certificate because the error text does not mention certificates at all. - Not checking OS-level resource limits (file descriptors, memory) on a heavily loaded apps tier where the Forms process fails to fork. ## Ai Angle ERPray can be grounded on your EBS instance's log locations and topology, so when FRM-92101 is reported it walks the actual forms_*.log entries, cross-checks the formsweb.cfg or forms-c4ws-config.xml hostname against the current context file, and flags a mismatch or a stale certificate directly instead of leaving support staff to manually tail four different log files after every clone. ## Faq ### Does FRM-92101 mean the database is down? **Answer:** Rarely. FRM-92101 is raised at the Forms/web tier or on the client before a database connection is even attempted in most cases, so check the Forms listener log and client Java setup first; only escalate to the database tier if those come back clean. ### Why did FRM-92101 start right after a clone? **Answer:** Clones frequently leave formsweb.cfg or forms-c4ws-config.xml pointing at the source hostname or port. Re-run autoconfig from the target context file rather than editing the config manually. ### Can a browser update cause this error? **Answer:** Yes, on EBS versions using the Java applet Forms client, browsers dropping NPAPI/Java plugin support or auto-updating the JRE to an uncertified version is a known trigger. Pin a certified JRE version per My Oracle Support's compatibility notes. ### Is FRM-92101 specific to on-premises EBS or does it happen on Oracle Cloud Infrastructure hosted EBS too? **Answer:** It happens on both, since it is a Forms/web tier and client issue rather than an infrastructure platform issue. On OCI-hosted EBS, also check security list/NSG rules for the Forms servlet port in addition to the usual causes. ## Search terms FRM-92101 fix, EBS forms will not start, forms server startup failure Oracle EBS, formsweb.cfg hostname wrong, EBS forms applet not loading, JInitiator FRM-92101, adopmnctl forms status, EBS forms after clone not working --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json