Troubleshooting COMOS Web 500 Internal Server Error After Login

Problem Overview: COMOS Web HTTP 500 After Successful Login

COMOS Web is the browser-based front end of the Siemens COMOS plant engineering platform. The deployment is built on Microsoft Internet Information Services (IIS) and uses a separate COMOS Web Gateway service as a relay between the HTTP request and the COMOS database (the iDB, FEED, or SQL backend). The standard install sequence is documented in the official COMOS Web Installation Manual (PDF).

A recurring field issue is that the installer completes, IIS is bound to the correct port, the login screen renders, the operator enters valid credentials, and the page returns Status: 500 internal server error: Unexpected error instead of the project tree. The user is authenticated, but the first post-login call to the gateway fails. This article collects the root causes documented in Siemens Support deliverables, the COMOS DokuPack, and field-proven remediation steps, then walks the engineer through an ordered diagnosis and resolution procedure.

COMOS Web Architecture and Where the 500 Originates

Before changing configuration, identify the failing layer. COMOS Web has three distinct tiers, and HTTP 500 can originate in any of them:

The error "Unexpected error" is the COMOS Web front end's generic catch-all wrapper around a deeper exception. To localize the failure, open the browser's developer tools (F12 → Network tab) and inspect the failing request. The 500 response is usually returned by the gateway endpoint, not by the static IIS page. A typical stack trace line points to Comos.Web.Gateway.Service or a database connection string, which immediately tells you which tier failed.

Prerequisites for the Remediation Steps

Apply the checklist below before changing any setting. Each item removes one of the common false positives that mimic the 500 error.

1. Local administrator rights on the COMOS Web server (required to edit IIS, restart services, and write to the gateway config directory).
2. COMOS Desktop installed on the same machine, version-matched to the COMOS Web server (the gateway reads its license and DB-Config from the COMOS install path, typically C:\Program Files\Siemens\COMOS\).
3. Access to the COMOS DB-Config tool (Desktop menu → COMOS → DB-Config) to verify the connection string consumed by the gateway.
4. Microsoft IIS 7.5 or higher with the ASP.NET role service installed, Windows Authentication enabled on the COMOS Web site, and the Application Pool Identity configured for No Managed Code with .NET CLR version v4.0.
5. TCP port 80 / 443 reachable between the browser client and the web server; TCP port 1433 (or the named-instance port) reachable between the web server and the SQL Server hosting the COMOS database.
6. The DokuPack for the installed COMOS version. Download from the Technische Dokumentation COMOS: Doku-Portal (ID 109776498) and open the included PDX file with the COMOS help viewer. Search for "COMOS Mobile Solutions" or "COMOS Web" to cross-check the steps performed against the official procedure for the exact version.

Root Cause Analysis: The Four Documented Triggers

Siemens Support and field engineers have converged on a list of four configuration defects that produce the post-login HTTP 500. They are listed in the order in which they should be checked because they are also the most-to-least frequent.

RC-1 – COMOS User Lacks Administrator Rights

The gateway delegates permission checks to the COMOS server. A non-admin COMOS user can authenticate against the iDB, but the gateway's first post-login call requires ComosAdmin rights to enumerate the project structure. If the account does not have those rights, the gateway returns HTTP 500 with the generic Unexpected error message rather than a granular permission fault.

Resolution:

1. Open COMOS Desktop and log in with a user that already has COMOS Administrator rights.
2. Navigate to Administration → Users and Groups.
3. Locate the account used for the COMOS Web login. Open its properties → Roles tab.
4. Add the role ComosAdmin (or assign to the Administrators group, depending on the COMOS release).
5. Click Apply and confirm the role change is persisted to the iDB.

RC-2 – COMNET Service User Missing, Lowercase, or Without Admin Rights

The COMNET layer is the COMOS process that brokers project data over the network. The COMOS Web gateway calls COMNET under a Windows service account that must be registered inside COMOS itself. The documented case is that this COMNET user is either absent, created in lowercase (which breaks the case-sensitive lookup the gateway performs on some COMOS versions), or present but without admin rights.

Resolution:

1. Open COMOS Desktop with an admin login.
2. Go to Administration → COMOS Users and verify a user named COMNET exists. If absent, create it.
3. The username MUST be uppercase COMNET. Rename any lowercase or mixed-case entry.
4. Grant the ComosAdmin role to the COMNET user, exactly as in RC-1.
5. Save the change and exit COMOS Desktop.

RC-3 – DB-Config in the Gateway Is Inconsistent with COMOS

The gateway reads its database connection parameters from its own config file, not directly from the COMOS Desktop registry. If those parameters drift (different SQL instance, different database name, different authentication mode) the gateway connects, the login succeeds (the login only validates the user, not the DB), and the first real query 500s when the schema lookup fails.

Resolution:

1. Open COMOS Desktop → DB-Config and note the exact values: Server, Database, Authentication (Windows / SQL), and the project node.
2. Open the gateway configuration file. Default path: C:\Program Files\Siemens\COMOS\Web\Gateway\Comos.Web.Gateway.exe.config.
3. Compare the <connectionStrings> section and the ComosDb entries with the values from DB-Config. Correct any drift.
4. Confirm the ComosAdminUser and ComosAdminPassword keys point to a valid COMOS admin account. Where the gateway supports integrated security, the Windows service account used to start the gateway must have db_owner rights on the COMOS database.

RC-4 – IIS Application Pool Stale State

IIS caches COMOS Web assemblies and the gateway endpoint URL. A configuration change in COMOS, an updated .config file, or a partial install (DLLs copied but COM registration skipped) leaves the application pool in a state where the worker process throws an unhandled exception on the next call. The standard, documented reset is iisreset from an elevated command prompt.

Resolution:

1. Open Command Prompt (Run as administrator).
2. Run iisreset and wait for "Internet services have been successfully restarted".
3. Optionally recycle just the COMOS Web application pool via appcmd recycle apppool /apppool.name:"ComosWebAppPool" if a full iisreset is too disruptive.
4. Clear the browser cache and retry the login.

Step-by-Step Remediation Procedure

The procedure below applies RC-1 through RC-4 in sequence, with verification after each step. Engineers who reach Step 4 with no resolution should escalate through the Siemens support channel with the artifacts listed in the Escalation section.

1. Confirm versions are aligned. Open COMOS Desktop → Help → About and the gateway's About dialog. The major.minor versions must match. A common source of the 500 is a gateway shipped with a different COMOS service pack than the desktop installation.
2. Apply RC-1. Grant ComosAdmin to the COMOS Web login user.
3. Apply RC-2. Create or correct the COMNET user in uppercase and grant ComosAdmin.
4. Apply RC-3. Cross-check the gateway's .config against DB-Config in COMOS Desktop.
5. Apply RC-4. Run iisreset from an elevated command prompt.
6. Capture diagnostics. Before each retry, reproduce the error, save the browser HAR trace (F12 → Network → Export HAR) and pull the latest gateway log file.
7. Retry login. Use a clean browser session (incognito / InPrivate) to bypass cached authentication cookies.

Verification After Each Fix

For a clean end-to-end verification, open a remote browser session from a workstation (not the server's localhost loopback), authenticate with the corrected user, and confirm that the project tree loads in under 5 seconds for a small reference project. The 5-second budget is the standard COMOS Web response time for a single-project load and confirms that the gateway is not silently falling back to a slow code path because of a partial permission failure.

Reading the Gateway Log

When the four root causes have been eliminated and the 500 still appears, the next signal is in the gateway log. The default location is %ProgramData%\Siemens\COMOS\Web\Gateway\Log. Open the most recent file (rolling, one per day) and search for the timestamp of the failing request. The most useful exception types and their meanings are tabulated below.

Enabling Verbose Logging

By default the gateway writes only warnings and errors. To escalate the verbosity for a single diagnosis session:

1. Edit the gateway's .config file (see RC-3 for the path).
2. Locate the <log4net> section and change the root logger level from WARN to DEBUG.
3. Save the file, restart the gateway Windows service (services.msc → COMOS Web Gateway → Restart).
4. Reproduce the 500 and reload the log.
5. Return the level to WARN after the diagnosis to keep the log file from growing beyond its rolling size.

Escalation: Opening a Siemens Support Ticket

When the in-house procedure does not clear the 500, escalate. The official procedure for submitting a COMOS query is documented in Siemens Support entry ID 109474501. The high-value artifacts to attach are:

• COMOS version (Desktop Help → About) and the installed COMOS Web version.
• Browser used, including version (Chrome, Edge, IE 11 — IE 11 is still the only fully-supported browser for some COMOS Web 10.x releases).
• HAR file from the failing session.
• Full gateway log directory zipped.
• Windows Event Viewer Application log exported as .evtx for the time window of the failure.
• A short screen recording (MP4) of the login attempt, captured on the failing workstation.
• Output of iisreset /status and sc query "Comos.Web.Gateway" immediately after the failure.

For on-site, hands-on remediation, Siemens Services or an authorized COMOS Customizer can be engaged. The general COMOS Services overview is in Siemens Support entry ID 109739837.

Troubleshooting Matrix

Preventive Maintenance Checklist

After the 500 is cleared, apply the following to reduce the chance of recurrence:

• Version discipline. Apply COMOS Desktop service packs together with the matching COMOS Web service pack. Do not upgrade one tier without the other.
• User provisioning SOP. Any user that needs COMOS Web access must have the ComosAdmin role assigned in COMOS itself, and the COMNET user must remain uppercase and admin-privileged.
• Gateway config audit. Quarterly, compare the gateway .config with DB-Config. Any drift is the early signal of a configuration divergence that will eventually present as 500.
• IIS recycle schedule. Schedule a daily application pool recycle (off-peak) for the COMOS Web app pool. This prevents the gradual accumulation of stale state that triggers the 500 on first contact after a long idle window.
• Log retention. Keep gateway logs for at least 30 days. The first symptom of a 500 is often a stack trace in the log several days before the user actually reports the failure.

FAQ