WinCC 7.4 Server Not Available: Restoring Missing projectname.mdf and projectname.ldf Databases

When a running WinCC V7.4.x project fails to start with a Server not available / Cannot connect to server message immediately after a PC restart, the root cause is almost always the loss of the SQL Server database files (projectname.mdf and projectname.ldf) that back the WinCC project configuration. This article documents the failure mode, isolates the root cause, and provides a verified recovery path for systems where the database files are missing from the project directory.

1. Problem Description and Symptoms

After an uncontrolled shutdown or forced reboot, the WinCC Runtime (or WinCC Explorer) reports the following symptoms when the project is launched:

• Status bar message: Server not available
• Dialog: Cannot connect to server when activating Runtime
• WinCC Explorer may launch, but the project shows a red status icon
• Activating Runtime fails immediately; the project does not start
• An older backup of the same project opened on the same or a different PC reproduces the same error, confirming the fault is in the project files, not the host
• Manual procedures that normally clear transient issues have no effect: deleting *.dcf / *.dc files, removing projectname.lck, and Save As project all fail
• No recent Windows Update has been installed that would explain the regression

When the project folder is inspected, two files are missing that are normally always present:

• projectname.mdf — primary SQL Server data file
• projectname.ldf — SQL Server transaction log

2. WinCC 7.4 Project Architecture: Where the Database Lives

Every WinCC 7.x project is, from SQL Server's perspective, a pair of attached databases. WinCC uses Microsoft SQL Server (the bundled Express instance, default instance name WINCC) to persist configuration, tag definitions, alarms, and tag logging.

When WinCC Runtime starts, the WinCC service attaches the project database to the local SQL Server instance. On a clean exit the database is detached. A power loss, BSOD, or forced kill of sqlservr.exe during a write can leave the database in an attaching or recovery state; a disk fault or accidental deletion can remove the files entirely.

3. Root Cause Analysis

The fundamental reason the standard recovery steps fail is that WinCC's .dcf, .dc, and .lck files are not the source of truth. They are derived and lock artifacts. The source of truth for the WinCC configuration database is the SQL Server .mdf/.ldf pair.

When those files are gone:

1. SQL Server has no database to attach for the project.
2. WinCC Explorer cannot read the tag list, user list, or picture references.
3. Save As Project reads from the same missing DB, so it also fails.
4. Reactivating the project produces Server not available because the WinCC server data manager (the SQL-backed internal data manager) has nothing to bind to.

Typical scenarios that produce the loss:

• Disk I/O error or sector reallocation just before shutdown.
• Antivirus or backup software quarantined .mdf/.ldf on a folder scan during the restart.
• Manual or scripted cleanup of the project directory.
• Restore from a corrupted or partial backup that excluded the project root.
• SQL Server service started before the disk on which the project resides was online, attaching to a transient empty path.

4. Pre-Recovery Diagnostics

Before attempting any restore, verify the state of the SQL Server service and the file system.

4.1 Confirm SQL Server Is Running

1. Open Task Manager → Details tab.
2. Locate sqlservr.exe. If it is not present, the SQL Server (WINCC) service has not started.
3. Open services.msc, sort by Name, and verify SQL Server (WINCC) is in state Running and Startup Type Automatic.
4. If the service is stopped, start it manually and observe the Windows Event Log (Application channel) for the source MSSQL$WINCC.

4.2 Verify File System State

1. Navigate to the project root, typically C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<projectname>\.
2. Confirm whether projectname.mdf and projectname.ldf exist. Note exact sizes if they are present.
3. Open the project folder properties → Previous Versions tab. If Shadow Copies is enabled, a recoverable prior version of the files may be available from before the restart.
4. Check the Recycle Bin on all drives; accidental deletes land there first.
5. If a UPS or storage event occurred, inspect the disk's SMART counters and eventvwr.msc for disk / ntfs / volmgr errors around the failure time.

4.3 Confirm With SQL Server Management Studio

1. Launch SQL Server Management Studio (SSMS) and connect to localhost\WINCC with Windows Authentication.
2. Expand Databases. A healthy WinCC project will show a database with the project name (for example, CC_PCS_07_2018_09_30__11_22_33) in the Online state.
3. If the project database appears with state Recovery Pending, Suspect, or Restoring, the MDF/LDF are present but inconsistent. If it is missing entirely, the files have been removed.

5. Step-by-Step Recovery Procedure

The recovery strategy depends on whether at least one intact copy of the MDF/LDF pair exists. Walk through the options in order, least destructive first.

5.1 Option A — Restore From Shadow Copy or Recycle Bin

1. If Shadow Copies were enabled, right-click the project folder → Restore previous versions → select a snapshot taken before the failure → Restore.
2. If the files are in the Recycle Bin, restore them to the project root with their original names.
3. Confirm file sizes match an expected MDF (often 5–50 MB for typical projects) plus a smaller LDF.
4. Re-attempt WinCC Runtime activation.

5.2 Option B — Reuse Files From the Last Known-Good Backup

This is the practical path when no local copy remains.

1. Identify the most recent backup of the project that opened cleanly on a different PC. WinCC Configuration Studio backs up projects as complete folder copies; if the customer's backup script copies only .mdf/.ldf, ensure it includes GraCS\, Library\, and the projectname.mdf / projectname.ldf files.
2. On a different PC that has a working copy of the same project (or on the same PC under a different Windows user), locate the two files.
3. Copy projectname.mdf and projectname.ldf from the working source into the broken project's folder, overwriting any zero-byte stubs.
4. Start WinCC on the broken PC. The data manager will attach the restored database to the local SQL Server instance.
5. Confirm the project activates and the tag list populates.

5.3 Option C — Reuse Files From the Same Project Running on a Different SQL Server

If the project is currently running successfully on PC A but missing the database on PC B, the MDF/LDF from PC A can be detached and copied.

1. On PC A, stop WinCC Runtime and close WinCC Explorer so SQL Server detaches the database cleanly.
2. Open SSMS on PC A, connect to localhost\WINCC, right-click the project database → Tasks → Detach.
3. Copy projectname.mdf and projectname.ldf from PC A's project folder to PC B's project folder.
4. On PC B, the next WinCC launch will re-attach the database. If SQL Server reports an orphan, attach manually via SSMS: right-click Databases → Attach → Add, point to projectname.mdf, ensure the LDF path resolves, and confirm.

5.4 Option D — Recreate Project From CS Files When No Database Exists

If no copy of the MDF/LDF exists anywhere, the configuration database is irrecoverable. The project must be rebuilt. Recovery is limited to whatever CS sources are still on disk or in version control:

• WinCC pictures (GraCS\*.pdl) are stored as independent files and can be retained.
• Tag definitions, alarm classes, user administration, time schedules, and the connection to the AS (PLC) live in the SQL DB and are lost.
• Re-create the project in WinCC Configuration Studio, re-import the PDLs, and re-enter the tag database by re-linking to the AS or by importing a previously exported tag list (CSV / TLG).

6. Why the Standard Quick Fixes Do Not Work Here

The pattern is consistent: every operation that depends on the SQL database fails in the same way. That is the diagnostic that points to a missing MDF/LDF.

7. Verification Checklist

After the recovery, run this checklist to confirm the project is healthy:

1. In SSMS connected to localhost\WINCC, the project database is in state Online and its Compatibility level matches WinCC V7.4 expectations (SQL 2008 R2 / 2014).
2. In WinCC Explorer, the project's tag count matches the pre-failure total. Drill into Tag Management → confirm structure, PLC connections, and tag names.
3. Activate Runtime. The status bar transitions from yellow (starting) to green (running) within 30–60 seconds, with no Server not available dialog.
4. Open a picture from GraCS in Graphics Designer; static and dynamic elements render.
5. Force a tag update from a connected AS; the value should appear live in an I/O field.
6. Trigger a configured alarm; verify it appears in Alarm Control and is logged to AlarmLogging tables.
7. Stop Runtime cleanly. Verify the MDF and LDF remain in the project folder, that the LDF size did not balloon (indicating an un-checkpointed transaction), and that the next cold start is also clean.

8. Preventive Measures

Loss of the project database is the most common cause of unrecoverable WinCC 7.4 downtime. Apply the following controls in the same change window as the recovery:

• Image-based backups: Use Windows Server Backup or a disk-imaging product that captures the entire WinCCProjects\<projectname>\ directory, including hidden/system files and *.mdf/*.ldf. File-copy backups that filter by extension will silently skip the database.
• Enable Shadow Copies on the volume hosting the project, with a minimum of 25% free space allocated to the System Volume Information.
• Exclusion rules for antivirus: Exclude *.mdf, *.ldf, and the WinCCProjects tree from real-time scanning. Document the exclusion in the customer's IT change record.
• SQL Server service dependency: Ensure the SQL Server (WINCC) service has a dependency on any volume that hosts the project. If the volume mounts late, the service can start in a state where the DB is unavailable.
• Pre-shutdown grace on UPS: Configure the UPS shutdown sequence to stop the WinCC service (which detaches the DB cleanly) before killing sqlservr.exe.
• Daily integrity check: Schedule a script that uses DBCC CHECKDB against the project database during a maintenance window. Surface corruption early, before the next restart.
• Document the recovery source: Record the location of an offline, known-good MDF/LDF copy (e.g., a hot spare PC, a versioned repository, or a read-only network share) so the recovery procedure does not depend on the customer's word of mouth.

9. Related Error Patterns

10. Field Notes and Edge Cases

• When copying .mdf/.ldf between PCs, both machines must run the same WinCC major version and compatible SQL Server build. A V7.4 database will not attach cleanly on a V7.3 host.
• If the original project path is on D:\WinCC\… and the recovery PC mounts the project at C:\WinCC\…, the MDF's internal file pointers will still reference the original paths. Update the file paths in SSMS → Database → Files after attach, or re-copy the files to the original path.
• Do not start the SQL Server (WINCC) service while a copy of the database is in progress. The attach can race with the file write and produce a torn state.
• If the customer reports the same error on multiple projects on the same PC, the root cause is the SQL Server instance itself, not individual projects. Investigate ERRORLOG in C:\Program Files (x86)\Siemens\Automation\WinCC\SQL\LOG\ first.
• Tag logging runtime databases (CC_TLG_…) and alarm logging runtime databases (CC_ALG_…) are separate from the configuration database. They are typically archived in segments and are more resilient to single-file loss.