Fix WinCC Explorer Logon Failure: Unknown User Name Bad Password

1. Problem Overview

The dialog "Logon failure: Unknown user name or bad password" displayed inside SIMATIC WinCC Explorer originates from the Microsoft OLE DB provider that WinCC uses to communicate with its backing SQL Server instance. The exact error string is identical to the one documented in Microsoft SQL Server Reporting Services connectivity guides (see Troubleshoot Reporting Services database and server connection problems) because both WinCC and Reporting Services attach to a SQL Server master database through the same data-access stack (SQLOLEDB / MSOLEDBSQL).

WinCC V7.0 through V7.5 SP2 store every project configuration in the SQL Server instance WINCC installed by the WinCC setup. Each project consumes databases named CC_<projectname>, CC_<projectname>_MCP, and CC_<projectname>_RT. Windows-authenticated principals created during setup own these databases, and the runtime CCAgentHost service uses the same principal to open them. Any drift between three sources of identity surfaces as the same dialog:

• The Windows account under which WinCC Explorer is currently running (the logged-in interactive user).
• The Windows account assigned to the CCAgentHost and WinCC RT services inside services.msc.
• The SQL Server login mapped to either of the above inside the WINCC master database (sys.server_principals).

If any of the three identities is invalid - because the password was rotated, the SID was deleted in Active Directory, or the DBA dropped the SQL Server login - WinCC Explorer cannot authenticate and the dialog appears before the project tree ever renders.

2. Confirmed Symptoms and Log Signatures

Engineers see this dialog in four distinct contexts. Each carries a specific log signature that confirms identity drift rather than a database or project file problem.

3. Affected Versions and SQL Server Pairings

WinCC versions pair to specific Microsoft SQL Server versions per the official release notes. The pairing determines which authentication mode WinCC uses (Windows auth only, or Windows + SQL auth fallback).

4. Root Cause Analysis

The error is a SQL Server authentication failure intercepted by WinCC. Microsoft catalogs it as Login failed for user with HResult 0x80040E07; WinCC surfaces the human-readable OLE DB message. The technical definition of state codes is documented at MSSQLSERVER_18456. The three identity layers that must agree are:

1. Windows security principal. The domain account DOMAIN\WinCCUser stored in Active Directory Users and Computers. If the account is locked, disabled, or the password is older than the configured fine-grained password policy, winlogon rejects it before it ever reaches WinCC.
2. WinCC service logon. The credential used to start CCAgentHost, WinCC RT, and the rest of the WinCC service family in services.msc > Log On As. WinCC services run as DOMAIN\WinCCUser by default; if the password is rotated externally (for example by group policy that pushes complexity changes), the service still holds the old password.
3. SQL Server login. The principal in the WINCC master database sys.server_principals view, mapped to the same Windows user. Dropping this login from SQL Server or detaching the CC_* databases severs WinCC's ability to bind.

When any single layer drifts, the SQL Server ERRORLOG records Error 18456, State 8 (password mismatch), or State 5 (login does not exist), or State 1 (login cannot be resolved). The WinCC Explorer dialog then inherits the OLE DB provider text. Identification is straightforward once you know which state is logged.

5. Diagnostic Step Sequence

Run the following checks in order. Stop as soon as one identifies the broken layer; everything downstream is fixable without reinstallation.

1. Open SQL Server Management Studio on the WinCC server (or on the workstation hosting WinCC) and connect to .\WINCC using Windows authentication as the same DOMAIN\WinCCUser used by the service. If SSMS reports the same 18456 dialog, the SQL Server login is broken. If SSMS connects cleanly, the SQL login is intact and the drift is at the WinCC service level.
2. Check the SQL Server ERRORLOG under C:\Program Files\Microsoft SQL Server\MSSQLxx.WINCC\MSSQL\Log. The latest entry will contain the date and time of the first WinCC Explorer login attempt, the state code, and the SID that failed.
3. Check the WinCC diagnose folder at %ProgramFiles(x86)%\Siemens\Automation\WinCC\Diagnose. Look for WinCC_SysLog_<date>.log. Lines beginning with HResult 0x80040E07 confirm the OLE DB rejection; lines starting with OpenProject: Logon failure confirm a project open failure rather than a database-attach failure.
4. Inspect service logon for CCAgentHost and WinCC RT in services.msc → Properties → Log On. If the password stored there does not match Active Directory Users and Computers → Account options → Reset password with show selected, the service logon is the broken layer.
5. Validate the SIMATIC Logon Database. When SIMATIC Logon (formerly known as SIMATIC Logon Server) is configured, it caches credentials in a SQL table on the central logon server. If only that table is unreadable, the WinCC Runtime service authentication fails locally even though all other paths are healthy.

6. Resolution Path A — WinCC Service Password Synchronization

Use this path when the SQL Server login is intact (SSMS connects cleanly), but the WinCC services still hold the old cached password.

1. Open services.msc on the affected workstation.
2. For each of the following services, right-click → Properties → Log On → This account → enter the latest password twice:
   • CCAgentHost
   • WinCC RT
   • WinCC Alarm Logging
   • WinCC Tag Logging
   • WinCC OS (Picture) or WinCC Graphics depending on the version
   • SIMATIC Logon (when a centralized SIMATIC Logon Server is in use)
3. Restart the services in reverse order (Graphics → Alarm Logging → Tag Logging → RT → CCAgentHost). Each service should report Starting; the previously failing Logon failure dialog will not appear when WinCC Explorer is reopened.

7. Resolution Path B — SQL Server Login Repair

Use this path when SSMS itself cannot connect to .\WINCC with the current Windows account, or when the DBA has confirmed a dropped login.

1. Start SQL Server Management Studio as a member of sysadmin on the WinCC server.
2. Connect to .\WINCC with Windows authentication (use a domain admin or local Administrator).
3. Open Security → Logins. Locate the missing principal (typically DOMAIN\WinCCUser or DOMAIN\<machine>$). If absent, recreate it:

4. Re-map the new login to the existing CC_* databases:

USE [CC_<projectname>];
CREATE USER [DOMAIN\WinCCUser] FOR LOGIN [DOMAIN\WinCCUser];
ALTER ROLE [db_owner] ADD MEMBER [DOMAIN\WinCCUser];
GO
USE [CC_<projectname>_MCP];
CREATE USER [DOMAIN\WinCCUser] FOR LOGIN [DOMAIN\WinCCUser];
ALTER ROLE [db_owner] ADD MEMBER [DOMAIN\WinCCUser];
GO

5. Repeat for _RT if the project is also running the OS Runtime.

6. Detach and re-attach the databases in SQL Server Management Studio to revalidate the SID linkage (Tasks → Detach → Re-Attach).

7. Restart CCAgentHost and reopen WinCC Explorer. The dialog should not return.

8. Resolution Path C — Project Restore from Archive

If both SQL Server and service paths fail to clear the dialog, the MCP file itself can become corrupted. This is rare but reproducible when the project was edited while the WinCC service was running detached from its database.

1. Confirm the local copy or network archive opens cleanly on a different VM in the same domain. This validates that the project files are not project-level corruption.
2. Export the project from the working copy using the WinCC Project Migrator (found on the start menu under Siemens Automation → WinCC → Tools):
   • Run CCProjectMigrator.exe /Source:\<archive> /Target:\<working copy> /Mode:Standard
3. Stop all WinCC services on the failed workstation.
4. Detach the existing CC_* databases in SQL Server Management Studio.
5. Delete the *.MCP and *.LDF files from the project path (default C:\WinCCProjects\<project>).
6. Restore the archived project files.
7. Re-attach the databases using the restored *.MDF/*.LDF files.
8. Restart the WinCC services and reopen the project.

9. WinCC UserAdmin and SIMATIC Logon Reconfiguration

After resolving SQL Server authentication, the WinCC internal user database must be reconciled. This is the most-frequently missed step in field service.

1. Open WinCC Explorer → Tools → User Administrator.
2. For each operator that previously logged in to WinCC RT, click Properties → Password and re-enter the same password set in the Windows account. WinCC hashes each password internally using its own AES config; if the hash is stale (older than a re-encryption cycle), runtime logon fails even when the SQL path is healthy.
3. If the project uses SIMATIC Logon for central user management, open SIMATIC Logon Console and confirm that the logon server is reachable. Clear the ticket cache (Actions → Clear Ticket Cache) so that no stale ticket survives.
4. If the WinCC project uses UMC (User Management Component) (typically on WinCC Unified or TIA Portal configurations), open the WinCC Unified Configuration and re-bind the WinCC Unified Database connection. The same Logon failure error can come from a wrong connection string here even after a perfect SQL repair.

10. Verification Checklist

Confirm every item before declaring the workstation healthy. A single missed layer means the next project open will fail again.

11. Preventive Measures

Once the dialog is cleared, three engineering controls prevent recurrence on the next Windows password rotation cycle.

1. Decouple WinCC service logon from user passwords by using a Group Managed Service Account (gMSA). The system rotates the password automatically and the WinCC service updates without manual intervention. This is the Microsoft-supported path documented for SQL Server 2016+; see MSSQLSERVER_18456 for the state codes that gMSA automatically prevents.
2. Set Maximum password age off for the WinCC service account in your domain Group Policy. Common policy is 42 days; an unmonitored rotation is exactly what strands the WinCC service.
3. Schedule a WinCC service logon sanity check every 90 days. Open services.msc → Properties → Log On for each WinCC service and confirm the password matches the value cached in Active Directory Users and Computers.
4. Archive the project weekly using WinCC Project Migrator so that Path C (Restore from Archive) is always available with a known-good MCP file. This is the shortest path back to runtime if the database becomes unsynced.

12. Related Fault Signatures

When the dialog persists after the above steps, the failure is no longer a Windows or SQL authentication problem. The following correlated errors indicate deeper issues and should be opened with Siemens technical support:

FAQ