Resolving WinCC Explorer Hangs Opening Graphics Designer

Siemens WinCC V7.x SCADA stations occasionally exhibit a hard hang of the WinCC Explorer shell the moment an engineer opens the Graphics Designer (process grafexe.exe). The Explorer window turns white, the mouse pointer changes to an hourglass, the WinCC Runtime is unaffected, and ApDiag logs nothing. After one or two Task Manager kills, the shell refuses to recover and a full OS reboot is required. This reference documents the root causes observed in field installations, the immediate workarounds, and the permanent fixes that restore stable behavior on engineering and dedicated server machines.

1. Problem Details and Symptoms

The hang is reproducible only in interactive configuration mode (WinCC Configuration), not in Runtime. The typical symptom set is:

• User double-clicks Graphics Designer in the WinCC Explorer tree.
• WinCC Explorer freezes immediately; window contents are replaced with a blank/white client area.
• Cursor changes to hourglass (IDC_WAIT) when hovered over the window.
• Alt-Tab cycle back to the Explorer shows the window still drawn, but no input is processed.
• WinCC Runtime (if already started independently at machine boot) continues to run unaffected.
• ApDiag (C:\Program Files\Siemens\WinCC\bin\ApDiag.exe) shows no active alarm, no deadlock entry, and no license violation at the moment of the hang.
• Task Manager reveals grafexe.exe in a "Not Responding" state, and CCExplorer.exe is blocked on a wait for the child handle.
• Killing grafexe.exe from Task Manager frees the Explorer the first 1–3 times, then the shell stops opening Graphics Designer entirely until the OS is rebooted.
• Behavior is most commonly reported on dedicated WinCC engineering servers and corporate development PCs; it is not consistent across machines working on the same project.

Because the runtime is unaffected, the plant does not stop, which is why the symptom is treated as a configuration-engine nuisance rather than a process safety issue, but it becomes a hard production blocker the moment modifications are performed against a live controlling WinCC Server.

2. Affected Configurations and Versions

The hang is independent of project size; projects with only 5 PDL screens reproduce the issue if the engineering environment matches the conditions listed below.

3. Root Cause Analysis

Field experience and Microsoft kernel/driver documentation converge on four overlapping root causes. In many real installations, more than one is present, and a fix must address all of them.

3.1 Corrupted or outdated graphics driver

Graphics Designer relies on Win32 GDI primitives plus a small layer of GDI+ and Direct2D for vector rendering. If the WDDM driver in use is mismatched with the OS (for example, an older certified driver reinstalled after a Windows update, or a Windows-provided Microsoft Basic Display Adapter driver that replaced the OEM driver), grafexe.exe can deadlock inside win32k.sys. This matches the pattern documented in the Microsoft Support article Error: "Windows Explorer has stopped working": "Outdated or corrupt video drivers can cause Windows Explorer to stop working. Downloading and installing the latest video driver can solve many of these issues." WinCC Explorer's shell is a similar Win32 owner-drawn application and is affected by the same driver path.

3.2 DCOM / inter-process handle starvation

WinCC Explorer launches grafexe.exe as a child process and synchronously waits on the named-pipe or shared memory handle. If the user is not a true local administrator (Power User, RDP user, UAC-restricted developer), the handle inheritance can fail in a way that leaves CCExplorer.exe blocked on an WaitForInputIdle or WaitForSingleObject with no timeout. The child appears started in Task Manager, the parent never returns, and the entire shell turns white.

3.3 ALM license server reachability during startup

When a WinCC engineering station is configured for network licensing through the Automation License Manager, the Graphics Designer queries ALM on activation to validate the editor entitlement. If the ALM server is on a different subnet, behind a firewall that blocks TCP port 4410/4411, or temporarily unreachable, the call can block for the full TCP retransmit window (~75–180 s) while grafexe.exe remains in a startup splash state. The Explorer shell is single-threaded for child process bring-up, so the user sees a permanent hang.

3.4 SQL Server / WinCC project database contention

Graphics Designer reads the active project's .MCP file, the GraCS directory, and a set of tables in the CC_<ProjectName>_<TS> database. If the SQL Server service is in transition (restart after a Windows update, the VSS writer is rebuilding the database, or the WinCC database user lacks the db_owner role), grafexe.exe can hang inside an ODBC SQLDriverConnect call. ApDiag will not report this because the deadlock is between the child process and the SQL service, not within the WinCC internal alarm pipeline.

4. Diagnostic Procedure

Run the steps in order. Each step confirms or eliminates one root cause; do not skip to the permanent fix until all four checks are made.

1. Capture the process tree. Open Task Manager → Details, add columns Command line and User name. Confirm grafexe.exe is started by CCExplorer.exe under the same account that launched WinCC. Note the PID of the hung grafexe.exe.
   • If the user is DOMAIN\user but the project was created under a different account, DCOM context is mismatched (root cause 3.2).
2. Inspect Windows Event Viewer. Open eventvwr.msc and filter:
   • Windows Logs → Application, source = Application Error, grafexe.exe.
   • Windows Logs → System, source = Application Popup, Win32k, DCOM.
   • Custom Views → Administrative Events for time of hang.
   A Faulting application name: grafexe.exe, Faulting module name: atio6axx.dll (or similar vendor DLL) is the smoking gun for root cause 3.1.
3. Confirm the video driver. Run dxdiag → Display tab. Note the Driver Model and Driver Version. Compare against the latest certified driver from the GPU vendor (Intel, NVIDIA, AMD). A driver dated before the Windows update that introduced the hang is the typical cause.
   • Check pnputil /enum-drivers for duplicate display class drivers; the active one must match the GPU hardware, not a generic Microsoft Basic Display Adapter.
4. Validate the WinCC database connectivity. Start SQL Server Management Studio (or ssms.exe) and connect to localhost\WINCC for the SQL Express shipped with WinCC, or the configured SQL instance. Run:
   • SELECT name, state_desc FROM sys.databases WHERE name LIKE 'CC_%';
   • SELECT name, type_desc, create_date FROM sys.database_principals WHERE name = 'WinCC';
   If any CC_<project>_<TS> database is in RECOVERING or SUSPECT state, root cause 3.4 is confirmed.
5. Probe the ALM license server. From the engineering station, run telnet <almserver> 4410. A successful TCP handshake indicates a reachable license service. A timeout indicates root cause 3.3.
   • Inspect C:\Program Files\Siemens\Automation License Manager\LogFiles\almservice.log for the timestamp around the hang.
6. Run ApDiag in trace mode. Launch ApDiag.exe with -trace. Reproduce the hang. The output PDL init: blocking on handle 0x... immediately before the hang localizes the problem to the Graphics Designer startup path.
7. Collect a process dump. Use procdump -ma grafexe.exe from Sysinternals ProcDump. A stack walking on the hung thread typically shows ntdll!ZwWaitForSingleObject or win32u!NtUserGetMessage, pointing back to driver wait (3.1) or DCOM wait (3.2).

5. Immediate Workarounds

These restore edit capability quickly. They are not permanent fixes; treat them as the bridge while root cause is resolved.

5.1 Kill the hung child process

Open Task Manager, switch to the Details tab, locate grafexe.exe in Not Responding state, and end the task. WinCC Explorer normally releases and either re-opens Graphics Designer automatically or allows a new attempt. This works reliably for the first 1–3 occurrences per OS session; after that the parent shell needs to be reset (5.2).

5.2 Reset the WinCC project shell

Execute the reset script shipped with the WinCC installation:

cscript "C:\Program Files\Siemens\WinCC\bin\Reset_WinCC.vbs"

The script clears the WinCC project lock files in <ProjectPath>\<ProjectName>.MCP.lock and resets the per-user Explorer view settings stored under %APPDATA%\Siemens\WinCC\WinCCExplorer\. After the script completes, WinCC Explorer can be relaunched and the project reopened. This workaround is sufficient on development PCs where a full OS reboot is acceptable, but it is not acceptable on a live SCADA server (next section).

5.3 Edit PDLs outside the Explorer

Open grafexe.exe directly with the PDL as a command-line argument, bypassing the Explorer shell:

"C:\Program Files\Siemens\WinCC\bin\grafexe.exe" "C:\Siemens\WinCC\Projects\<ProjectName>\GraCS\<ScreenName>.pdl"

This works because the hang lives in the parent-child synchronization path; grafexe.exe launched standalone initializes the same way and saves normally. Use this path for emergency edits on a live system.

6. Permanent Fixes by Root Cause

6.1 Update the graphics driver (root cause 3.1)

1. Identify the GPU hardware via msinfo32 → Components → Display.
2. Download the latest OEM-certified driver from the manufacturer (NVIDIA Studio / Quadro, AMD Pro, Intel Graphics - Windows DCH).
3. Uninstall the current driver with pnputil /remove-device and reboot into Safe Mode to delete leftovers in C:\Windows\System32\DriverStore\FileRepository\ if it is a major version jump.
4. Install the new driver, reboot, and confirm dxdiag reports the new version and no Microsoft Basic Display Adapter.
5. Open WinCC Explorer and verify Graphics Designer opens within 5 seconds.

6.2 Restore proper UAC / DCOM context (root cause 3.2)

1. Add the engineering user account to the local Siemens TIA Engineer-style engineering group, or grant explicit Log on as a service and Act as part of the operating system privileges via secpol.msc → Local Policies → User Rights Assignment.
2. Open dcomcnfg → Component Services → Computers → My Computer → DCOM Config. Locate the Siemens WinCC Graphics Runtime and WinCC Explorer entries. Set Authentication Level to Connect and Impersonation Level to Identify at minimum; Impersonate is recommended for engineering PCs.
3. Set the Launch and Activation Permissions to allow the engineering group Local Launch and Local Activation.
4. Reboot and re-test Graphics Designer open from Explorer.

6.3 Stabilize ALM / licensing (root cause 3.3)

1. Pin the ALM service in the Automation License Manager as a service dependency. The service binary is almservicex64.exe; ensure its Startup Type is Automatic (Delayed Start).
2. On the engineering station, edit C:\Program Files\Siemens\Automation License Manager\almsrv.ini and set the LicenseServer entry to the FQDN (not the short hostname) to avoid NetBIOS broadcast fallback that adds startup latency.
3. Open Windows Firewall with Advanced Security and create an inbound rule for almservicex64.exe on TCP 4410–4411 on the engineering station, even if the server is local, to avoid the firewall from being silently reactivated by a GPO push.
4. For machines that lose connection to the ALM server, configure a local license fallback by exporting a license ticket to a USB dongle and assigning it to the engineering PC so that Graphics Designer can validate entitlements even when the network is down.

6.4 Repair the WinCC SQL database (root cause 3.4)

1. Stop the WinCC project. Confirm no CCEsg.exe, CCAlg.exe, or grafexe.exe is running.
2. Open SQL Server Management Studio and connect to the WinCC instance.
3. Run against the project database:

   ALTER DATABASE [CC_<ProjectName>_<TS>] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
   DBCC CHECKDB('CC_<ProjectName>_<TS>', REPAIR_REBUILD) WITH NO_INFOMSGS;
   ALTER DATABASE [CC_<ProjectName>_<TS>] SET MULTI_USER;

4. Verify the SQL Server service account has db_owner on the project database. Re-grant if necessary:

   USE [CC_<ProjectName>_<TS>];
   ALTER ROLE db_owner ADD MEMBER [WinCC];

5. Restart the WinCC project and test Graphics Designer.

7. Process Architecture of the Hang

The WinCC engineering shell is a parent–child process tree. Understanding the exact wait point is the fastest way to decide which fix to apply first.

CCExplorer.exe (PID 100, "Not Responding")
   |
   +-- grafexe.exe (PID 210, "Not Responding")
   |     blocked on:
   |       ntdll!NtWaitForSingleObject  (root cause 3.1 / 3.2)
   |         OR
   |       sqlncli11!SQLDriverConnectW   (root cause 3.4)
   |         OR
   |       almservicex64!RpcSend        (root cause 3.3)
   |
   +-- ccevent.exe
   +-- scripts.exe
   +-- CCEsg.exe

The hang is not a CPU spin; the kernel shows 0% CPU on the grafexe.exe thread, confirming a wait. Use the stack at the wait site to identify the source DLL and route the fix to the right section above.

8. Reinstall-When-All-Else-Fails Path

When the previous fixes do not resolve the hang, and the engineering machine is dedicated to WinCC, a clean reinstall is the documented path of least risk:

1. Back up the project: <ProjectPath>\<ProjectName>.MCP and the entire GraCS\ directory.
2. Uninstall WinCC via Control Panel\Programs and Features; reboot.
3. Delete the residual folders: C:\Program Files\Siemens\WinCC\, %APPDATA%\Siemens\WinCC\, %LOCALAPPDATA%\Siemens\.
4. Uninstall the SQL Server instance, then delete C:\Program Files\Microsoft SQL Server\.
5. Update the graphics driver (section 6.1) and the chipset driver while the system is bare.
6. Reinstall the matching WinCC version with the same SP level, then restore the project from backup.
7. Open Graphics Designer; the hang should be gone on a clean environment.

This matches the field observation that on a bare-bones dedicated WinCC server the hang is consistently absent, while a machine with additional post-install software (Office, remote-control agents, monitoring tools) reproduces the hang more often. The pattern is consistent with display-driver interaction with overlay or GDI hooks installed by those third-party products.

9. Prevention and Engineering Best Practices

• Use dedicated engineering machines. Do not install Office 365, antivirus with HIPS, PCAnywhere, TeamViewer, or remote-control agents on a WinCC engineering PC. Each introduces GDI hooks that have been observed to deadlock grafexe.exe.
• Pin graphics drivers. Use Group Policy → Computer Configuration → Administrative Templates → Windows Components → Windows Update → Do not include drivers with Windows Updates enabled on engineering PCs. The Microsoft KB "Windows Explorer has stopped working" notes that a freshly-installed video driver is a primary resolution; the corollary is that an OS-pushed driver replacement is a primary cause.
• Keep ALM on the same subnet as engineering PCs. Cross-subnet license lookups add 30–180 s of blocking time to the Graphics Designer startup path.
• Maintain SQL Server. Run DBCC CHECKDB monthly on the CC_<ProjectName>_<TS> database. Run a full backup before every project modification window.
• Maintain a project-side change log. Use the WinCC Version Tracking tool (under Project → Properties → Change Log) so that emergency edits made via the standalone grafexe.exe workaround (section 5.3) are recorded for production audit.
• Maintain a recovery USB stick with the same WinCC version, the project's .MCP, and a copy of Reset_WinCC.vbs for the production server room, so an engineer can recover the Explorer without a full OS reboot.

10. Verification Checklist

Run the following checklist after applying any fix. The system is considered fully recovered only when every row passes.

11. Frequently Asked Questions