---
title: "SignUp and Uniprint Web Pages Fail on Windows Server 2025 (JScript Engine)"
slug: "signup-and-uniprint-web-pages-fail-on-windows-server-2025-jscript-engine"
updated: 2026-11-06T00:58:30Z
published: 2026-11-06T00:58:30Z
canonical: "kb.pharos.com/signup-and-uniprint-web-pages-fail-on-windows-server-2025-jscript-engine"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.pharos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SignUp and Uniprint Web Pages Fail on Windows Server 2025 (JScript Engine)

On Windows Server 2025, the Pharos SignUp Nerve Center and the Uniprint web pages can fail intermittently with an HTTP 500 error, and under load the web service can stop responding altogether. This document explains the cause, how to tell whether your site is affected, and how to correct it with one registry setting - and why the "Execute in MTA" workaround that has been circulating should be reversed.

## Overview

Windows contains two engines that can run JScript: the classic engine, `jscript.dll`, and a newer replacement, `jscript9Legacy.dll`. Windows decides which one to load through a policy setting called **Replace JScript by loading JScript9Legacy in place of JScript**.

When that policy is enabled *or not configured*, Windows loads `jscript9Legacy.dll` wherever JScript is requested. On a default installation of Windows Server 2025 the policy is not configured, so the replacement engine is the one that runs. Disabling the policy makes Windows use the classic `jscript.dll` again.

For Microsoft's description of the setting, see [Policy CSP - InternetExplorer: JScriptReplacement](https://learn.microsoft.com/windows/client-management/mdm/policy-csp-internetexplorer#jscriptreplacement).

### Why this affects Uniprint

The SignUp Nerve Center (`/SignUp`) and the Uniprint web pages (`/Uniprint`) are Classic ASP pages written in server-side JScript. IIS runs them through ASP, and ASP asks Windows for a JScript engine for every request. To keep pages fast, ASP caches engines and reuses or clones them between requests.

On Windows Server 2025, the `jscript9Legacy.dll` engine fails when ASP reuses or clones it. The failure is an access violation inside the engine, so the page returns HTTP 500 and the IIS worker process can crash. Under concurrent use the crashes repeat quickly enough for IIS to stop the application pool, after which every application in that pool returns HTTP 503 until the pool is restarted.

This is one root cause with several faces. You may see any or all of the following:

- The SignUp Nerve Center, or SignUp logon page, intermittently shows an HTTP 500 error, often succeeding when the page is refreshed.
- The Uniprint web pages intermittently show an HTTP 500 error.
- All SignUp and Uniprint pages, and other applications in the same application pool (such as Pharos EDI), return HTTP 503 Service Unavailable after a period of use.
- The problem is worse when several people use the pages at the same time, and may not reproduce for a single user testing alone.

## Am I affected?

Check the Windows **Application** event log on the web server. If you are affected you will find one or more of these entries, logged at the time of the failures:

| Event source | Event ID | What it says |
| --- | --- | --- |
| Active Server Pages | 5 | Script Engine Exception. A ScriptEngine threw exception 'C0000005' in 'IActiveScript::...' from 'CActiveScriptEngine::...'. The method names vary, for example `SetScriptState()` from `ReuseEngine()`, `SetScriptSite()` from `MakeClone()`, `AddNamedItem` from `RequestItems()`, or `Close()` from `FinalRelease()`. A related entry reads "A trappable error (C0000005) occurred in an external object" |
| Application Error | 1000 | Faulting application name: w3wp.exe … Faulting module name: jscript9Legacy.dll. Some of the crashes may name `KERNELBASE.dll` instead |

In the **System** event log, Windows Process Activation Service (WAS) may also report that a worker process serving the application pool terminated unexpectedly or had a communication error (events 5009 and 5011), and that the pool was disabled after a series of failures (event 5002).

| Your web server | What you need to do |
| --- | --- |
| Windows Server 2025 hosting Pharos Web Services (SignUp and/or Uniprint web pages) | **Affected.** Apply the registry setting in [Resolution](/docs/signup-and-uniprint-web-pages-fail-on-windows-server-2025-jscript-engine#resolution). If "Execute in MTA" has been set to True, return it to False. |
| An earlier version of Windows Server hosting Pharos Web Services | Not known to be affected: the failure has been observed on Windows Server 2025 only, and no manual step is needed unless you see the event log entries above. |
| A server that does not host Pharos Web Services | Not affected. No Uniprint component on that server runs Classic ASP. |

## Resolution

Perform these steps on every Windows Server 2025 machine that hosts Pharos Web Services. You need local administrator rights.

> **All commands in this document are Windows PowerShell commands.** Run them in a PowerShell window opened with **Run as administrator**. (If you use a Command Prompt instead, drop the leading `& ` and write `$env:windir` as `%windir%`, for example `%windir%\system32\inetsrv\appcmd.exe`; the `reg` and `iisreset` commands are the same.)

### A. Use the classic JScript engine

1. Open **Windows PowerShell** with **Run as administrator** and run:

```
reg add "HKLM\SOFTWARE\Policies\Microsoft\Internet Explorer\Main" /v JScriptReplacement /t REG_DWORD /d 0 /f /reg:64
```

A value of `0` disables the replacement, so Windows loads the classic `jscript.dll`.

If you manage servers with Group Policy, the equivalent policy is at **Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Replace JScript by loading JScript9Legacy in place of JScript**. Set it to **Disabled** and keep the policy scoped to the web servers. If the policy is later removed or the server is moved out of its scope, Windows deletes the value and the failures return: run the `reg add` command above again.
2. Restart IIS so that running worker processes pick up the change:

```
iisreset
```

A server restart is not required.

### B. Return "Execute in MTA" to False

The workaround of setting ASP **Execute in MTA** to True can appear to help, because it changes how requests are scheduled. It does not fix the faulty engine: under concurrent load the HTTP 500 errors and worker process crashes return. Combined with the registry setting above, it causes a different problem: the Pharos components that the web pages call are single-threaded-apartment COM objects, so in MTA mode requests queue behind one another and some pages stall for 30 seconds or longer.

If Execute in MTA has been set to True on either web application, return it to False (the IIS default). Reinstalling or upgrading Uniprint does not do this for you.

1. Open **IIS Manager**.
2. Go to **Default Web Site**, then **SignUp**.
3. Double-click **ASP**.
4. Expand **Com Plus Properties**.
5. Set **Execute in MTA** to **False**, and click **Apply**.
6. Repeat steps 2 to 5 for **Uniprint**.
7. Restart IIS with `iisreset`.

Alternatively, in an administrator PowerShell window:

```
& "$env:windir\system32\inetsrv\appcmd.exe" set config "Default Web Site/SignUp" /section:system.webServer/asp /comPlus.executeInMta:false /commit:apphost
& "$env:windir\system32\inetsrv\appcmd.exe" set config "Default Web Site/Uniprint" /section:system.webServer/asp /comPlus.executeInMta:false /commit:apphost
iisreset
```

### C. Verify

1. Confirm the registry value:

```
reg query "HKLM\SOFTWARE\Policies\Microsoft\Internet Explorer\Main" /v JScriptReplacement /reg:64
```

The result should show `JScriptReplacement REG_DWORD 0x0`.
2. Confirm Execute in MTA is False on both applications (PowerShell):

```
& "$env:windir\system32\inetsrv\appcmd.exe" list config "Default Web Site/SignUp" /section:system.webServer/asp /text:comPlus.executeInMta
& "$env:windir\system32\inetsrv\appcmd.exe" list config "Default Web Site/Uniprint" /section:system.webServer/asp /text:comPlus.executeInMta
```

Each command should return `false`.
3. Open the SignUp Nerve Center and the Uniprint web pages, ideally with several people using them at once, and confirm they load without error.
4. Check the Application event log again. The Active Server Pages event 5 and Application Error event 1000 entries described in [Am I affected?](/docs/signup-and-uniprint-web-pages-fail-on-windows-server-2025-jscript-engine#am-i-affected) should no longer appear.

## Things to be aware of

- **The setting applies to the whole server.** Every program on the server that runs JScript uses the classic engine, not only the Pharos web pages. On a server shared with other applications, consider whether any of them rely on `jscript9Legacy.dll`.
- **The setting is per server.** It is stored under `HKEY_LOCAL_MACHINE` and is not distributed by Pharos Administrator or Change Control. Apply it on each web server.
- **Uninstalling Pharos Web Services does not remove the setting.** It is a Windows policy, not a Pharos file. To return to the Windows default, delete the value and restart IIS:

```
reg delete "HKLM\SOFTWARE\Policies\Microsoft\Internet Explorer\Main" /v JScriptReplacement /f /reg:64
iisreset
```
- **A Group Policy setting takes precedence.** If a domain Group Policy configures the same policy, it overwrites a value set locally at the next policy refresh. If the problem returns after a while, check with `gpresult /h report.html` whether a domain policy sets **Replace JScript by loading JScript9Legacy in place of JScript** to Enabled, or whether a policy that set it to Disabled no longer applies to the server.

## Troubleshooting

| What you see | Likely cause | What to do |
| --- | --- | --- |
| HTTP 500 errors continue, and event 1000 still names `jscript9Legacy.dll` | The setting has not taken effect | Confirm the value with the `reg query` command above, check that no Group Policy re-enables the replacement, and run `iisreset` again |
| SignUp and Uniprint pages return HTTP 503 | The application pool was stopped after repeated failures | Apply the resolution, then run `iisreset`, or start the pool in IIS Manager under **Application Pools** |
| Pages respond slowly or stall for about 30 seconds | Execute in MTA is still True | Return it to False as described in [step B](/docs/signup-and-uniprint-web-pages-fail-on-windows-server-2025-jscript-engine#b-return-execute-in-mta-to-false) |
| HTTP 500 errors continue, but the event log does not mention a script engine | A different cause | Contact Pharos Support with the Application event log entries from the time of the failure |

## More information

- [Policy CSP - InternetExplorer: JScriptReplacement](https://learn.microsoft.com/windows/client-management/mdm/policy-csp-internetexplorer#jscriptreplacement) - Microsoft's description of the policy that selects the JScript engine.
- [System Requirements for Servers](/InstallationGuide/SystemRequirementsServers.htm) - the Uniprint server prerequisites.