Contents

Click any entry to jump to that section.

1.  At a glance

2.  The root cause

3.  Symptom A — Crystal Report fails with “Class not registered”

4.  Symptom B — Package import fails with 0x800703FA

5.  Symptom C — RightFax InvalidCastException 0x80004002

6.  Symptom D — COM class factory fails with 0x8000401A

7.  Resolution 1 — Run as the Network Service account

7.1  IIS 7.0 and later (Windows Server 2008 R2 to 2022)

7.2  IIS 6 (Windows Server 2003)

7.3  The Manager Service and other STARLIMS services

8.  Resolution 2 — Do not forcefully unload the user registry at logoff

9.  After applying the fix

10.  Error code reference

1.  At a glance

Four failures that look unrelated — a Crystal Report that will not print, a package import that crashes the browser, a RightFax job that will not send, and a COM object that cannot be created at all. They share one root cause and one pair of resolutions, which is why they are treated together here.

The fix, in one line: Set the application pool identity to Network Service (Section 7), and enable the Windows policy “Do not forcefully unload the user registry at user logoff” (Section 8). Apply them in that order.

2.  The root cause

The short form of the cause: The application pool, or the Manager Service, is running as a domain user account instead of Network Service. Every symptom in this document follows from that one configuration choice.

All four failures are the same Windows behaviour seen from different directions. When the application pool or service runs under an identity that loads a user profile, Windows may forcefully unload that profile's hive when the session logs off — even while STARLIMS still holds handles into it. The hive is then marked for deletion, and any subsequent read against it fails.

COM depends on those registry reads. Instantiating a COM object means looking up its class registration, so once the hive is gone the lookup fails, and the failure is reported differently depending on how far the call got:

• The registry read itself fails — reported literally as 0x800703FA, “Illegal operation attempted on a registry key that has been marked for deletion” (Symptom B).
• The class registration cannot be resolved — reported as “Class not registered”, with 0x800703FA visible in the Event Viewer behind it (Symptom A).
• The object is created but its interface cannot be resolved — reported as E_NOINTERFACE, 0x80004002, “No such interface supported” (Symptom C).
• The COM server process cannot be started under the configured identity at all — reported as 0x8000401A, “the configured identity is incorrect” (Symptom D). This one names the cause outright.

Why the symptom differs but the fix does not: The error text depends on which COM component STARLIMS happened to be calling — the Crystal Reports engine, the script compiler, or the RightFax API. Correct the identity and all four stop.

This also explains a detail worth noticing: a report failure may show “Class not registered” in the STARLIMS server error while the Windows Event Viewer shows 0x800703FA at the same moment. Those are not two problems. The Event Viewer entry is the cause, and the STARLIMS message is the consequence.

3.  Symptom A — Crystal Report fails with “Class not registered”

Reported on Technology Platform 12.6, generating a Crystal Report through the Manager Service on Microsoft Windows Server 2022. The STARLIMS server error is:

---------------Server Error---------------

Exception of type: SSLRunException

Description: Error running report.

Error opening/initializing report:

  \\data\Application_Workpath\ReportsCache\0BA0AEDD-8100-4291-AC7D-1B857BDD8058_MHAREB_ENG.rpt

Error setting the report parameters.Class not registered

Class not registered

   at Starlims.Server.Reporting.LimsReport.Initialize(IAppConfig config, DataSet dataSource)

   at Starlims.Server.Reporting.ReportingSupport.Execute(String strXML, IAppConfig config, DataSet dataSource)

Location: LPrint_2.LPrintWithRetry

Code: -1

The execution stack shows the report path through the runtime support scripts:

ServerScript.Runtime_Support.LPrint_2.lprintwithretry() : line: 126

ServerScript.Runtime_Support.LPrint_2.main_ñ()       : line: 80

ServerScript.Runtime_Support.LPrint.main_ñ()         : line: 27

ServerScript.ReportsViewer.Reporting_PrepareReport.main_ñ() : line: 34

ServerScript.Runtime_Support._GetReport.main_ñ()     : line: 49

ServerScript.Runtime_Support.GetReport.main_ñ()      : line: 4

Check the Event Viewer — this is the confirming evidence: The Windows Event Viewer shows the underlying exception: “Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA)”. Finding this alongside a “Class not registered” report failure confirms you are looking at this issue and not at a genuinely unregistered or missing Crystal Reports component.

4.  Symptom B — Package import fails with 0x800703FA

When importing a package, the browser session crashes. The log file records a compiler error against a server script, with the registry exception reported directly:

Compiler error in: ServerScript.MATERIAL_MANAGER.scUpdateImage, line: 0, char: 0

Exception | Illegal operation attempted on a registry key that has been

marked for deletion. (Exception from HRESULT: 0x800703FA)

This is the clearest of the three presentations: the HRESULT appears in the message with no COM indirection in front of it. The script named in the compiler error is incidental — it is simply whichever script was being compiled when the registry read failed, so do not expect the same script name on your system.

5.  Symptom C — RightFax InvalidCastException 0x80004002

Faxes are not sent. The fax queue monitor service reports a failed cast of the RightFax COM object:

---------------Server Error---------------

Exception of type: System.InvalidCastException

Description: Unable to cast COM object of type 'System.__ComObject' to interface

type 'RFCOMAPILib.FaxServer'. This operation failed because the QueryInterface call

on the COM component for the interface with IID

'{24B5EE30-AA31-4554-A36F-F77009E855C3}' failed due to the following error:

No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

Execution Stack:

ServerScript.RightFaxInterface.FaxQueueMonitorService.sendnewfaxes() : line: 181

ServerScript.RightFaxInterface.FaxQueueMonitorService.main_ñ()      : line: 23

ServerScript.SSLDynType.SLL_D53836CF93237520C833A530A9B07C8F23FDF5D2.main_ñ() : line: 2

----------End Server Error----------

Do not chase the RightFax installation first: An E_NOINTERFACE on RFCOMAPILib.FaxServer reads like a broken or mismatched RightFax client installation, and that is the natural place to start looking. If the application pool identity and the registry policy have not been set as described in Sections 7 and 8, address those first — the same cause produces this error.

6.  Symptom D — COM class factory fails with 0x8000401A

The COM object is never created at all. Instead of a cast or interface failure, Windows reports that it could not start the COM server process under the account it was told to use. The example below was seen on the RightFax RFComApi server object, but the error is not specific to RightFax — any COM component can produce it.

SSL Error when creating RFComApi Server object.

Error: Retrieving the COM class factory for component with CLSID

{D7CA3941-DA83-4C87-949A-60DF378DD68E} failed due to the following error:

8000401a The server process could not be started because the configured identity

is incorrect. Check the username and password.

(Exception from HRESULT: 0x8000401A).

This is the most useful of the four messages: It states the cause in plain words — the configured identity is wrong. The instruction to “check the username and password” invites you to go and correct a password, which is usually the wrong move. The fix is not a better password for the domain account; it is to stop using a domain account and run as Network Service (Section 7).

Because the failure happens before any interface work, you will not see E_NOINTERFACE or a registry error alongside it. A CLSID that cannot be launched under one identity will usually launch correctly under Network Service with no other change.

7.  Resolution 1 — Run as the Network Service account

This is the recommended resolution. The Network Service account does not carry a user profile that gets unloaded at logoff, so the registry hive the COM calls depend on stays available.

Further reading: A separate STARLIMS server tip, “Using the Network Service account for the application pool identity”, covers the same procedure in more depth. Request it from STARLIMS Support if you need it; the steps below are sufficient in most cases.

7.1  IIS 7.0 and later (Windows Server 2008 R2 to 2022)

Which subsection applies to you: Use this subsection for any currently supported Windows Server version. Section 7.2 covers the legacy IIS 6 procedure, retained for Windows Server 2003 systems.

1.    Open Internet Information Services (IIS) Manager on the application server.

2.    Expand the server node and select Application Pools.

3.    Select the application pool used by STARLIMS.

4.    In the Actions pane, click Advanced Settings.

5.    Under Process Model, select Identity, then click the … button.

6.    Choose Built-in account, select NetworkService from the list, and click OK.

7.    Click OK to close Advanced Settings, then recycle the application pool.

ApplicationPoolIdentity is the modern default: On IIS 7.5 and later a new pool defaults to ApplicationPoolIdentity, not Network Service. That default is what leaves you exposed to this issue, so an otherwise healthy, freshly created pool still needs this change.

7.2  IIS 6 (Windows Server 2003)

For legacy systems only:

1.    Start IIS Manager from Administrative Tools.

2.    Navigate to the application pool item that you want to change.

3.    Right-click it and select Properties.

4.    Select the Identity tab, then select the Predefined option.

5.    From the combo box select Network Service.

6.    Click Apply / OK.

Figure 1 — IIS 6 — Application Pools > pool > Properties > Identity, with Predefined set to Network Service.

On STARLIMS v10 R2 and later: The installer already sets the application pool to use the Network Service account. Verify it rather than assuming it — a pool created or reconfigured by hand afterwards will not have it.

7.3  The Manager Service and other STARLIMS services

The application pool is the usual culprit, but it is not the only identity involved. The STARLIMS Manager Service runs under its own account, and a report generated through the Manager Service fails in exactly the same way if that account is a domain user.

1.    Open the Windows Services console on the application server.

2.    Locate the STARLIMS Manager Service, and any other STARLIMS service running under a named account.

3.    Open its Properties and select the Log On tab.

4.    Set it to This account and enter NT AUTHORITY\NetworkService with an empty password, or select Local System if your environment requires it.

5.    Restart the service.

Check both before concluding the fix did not work: A common outcome is that reports print correctly from the web client but still fail from the Manager Service, because only the application pool identity was changed. The two are configured separately.

8.  Resolution 2 — Do not forcefully unload the user registry at logoff

This is the second resolution, and it addresses the cause directly: it stops Windows from unloading a user's registry hive while handles into it are still open.

1.    Type gpedit.msc in the Windows Run box to start the Group Policy Editor.

2.    Navigate to Computer Configuration > Administrative Templates > System > User Profiles.

3.    Open the setting “Do not forcefully unload the user registry at user logoff”.

4.    Set the policy to Enabled, then click OK.

Figure 2 — Local Group Policy Editor — Computer Configuration > Administrative Templates > System > User Profiles, with “Do not forcefully unload the users registry at user logoff” set to Enabled.

What Microsoft's own description says: The policy help text notes that enabling it is “not recommended … by default” and should be used for cases where you are running into application compatibility issues. This is exactly such a case, which is why this document recommends it — but it is also why Resolution 1 is listed first.

9.  After applying the fix

1.    Recycle the STARLIMS application pool, and restart the Manager Service or the fax queue monitor service if the failure was in one of those.

2.    Re-run whichever operation failed — print the report, re-import the package, or release a fax.

3.    Check the Windows Event Viewer and confirm no new 0x800703FA entries appear.

4.    Confirm the application pool identity has actually persisted as Network Service, that the Manager Service Log On account has too, and that the Group Policy setting still reads Enabled — a later policy refresh from the domain can overwrite a locally set value.

If the errors continue: Only at this point is it worth investigating the specific component — the Crystal Reports runtime registration, or the RightFax client installation and its RFCOMAPILib version. Raise a support ticket with the full server error, the Event Viewer entry, and confirmation of both settings above.

10.  Error code reference