WinCC Graphic Object Fails to Load External Pictures on Single Clients

When a WinCC 7.x server project displays external pictures (for example, product photos referenced by an internal WinCC tag of type String) using the Graphic Object smart object from the Graphics Designer toolbox, the picture renders correctly in the runtime on the server but appears as a blank or broken-image frame on each single client. The internal tag that carries the file path replicates fine to the clients, the Windows Explorer on the client can open the very same UNC path without issue, yet the Graphic Object on the client still does not paint. This article explains the root cause, the picture distribution architecture that governs the behavior, and the four field-proven solutions used to resolve the issue in production WinCC installations handling thousands of product images.

1. Problem Summary

A typical reproduction looks like the following sequence:

1. An internal WinCC tag (commonly a 16-char, 32-char, or 128-char string tag named, for example, strPicPath) is bound to the Picture property of a Graphic Object via a direct connection or a C/VBScript dynamic dialog.
2. The server runtime evaluates the tag and renders the picture at the bound UNC path, for example \\PANDORA\pictures\1.jpg, \\PANDORA\pictures\SKU_4711.png, or \\PANDORA\pictures\batchA\item023.bmp.
3. The same internal tag replicates to every connected single client. The Graphics Designer diagnostic view confirms the correct string is present on every node.
4. Despite identical tag values, the Graphic Object on each client fails to render. Windows Explorer on the client resolves the same UNC path with no error, proving that NTFS and share permissions are correct at the operating-system level.
5. The only configuration under which the picture renders on the client is when the file is placed inside the WinCC project's GraCS folder, which is unacceptable when the project must reference thousands of operator-managed product photos.

2. Affected Products and Versions

Configurations confirmed to exhibit the failure:

• Single-station projects where the client and server are the same machine (rare; usually masked by local filesystem access)
• Distributed single-client installations with one or more multi-client servers
• Redundant WinCC server pairs with standby clients

Configurations not in scope:

• WinCC Unified WebUX / WebClient pictures — handled by the Unified picture pipeline and not by the classic picture distribution service.
• WinCC/WebNavigator pictures published for browser clients — use a separate web-server picture folder.

3. Root Cause Analysis

The WinCC graphics runtime does not resolve picture paths against arbitrary UNC shares. It resolves them against a controlled list of directories that are part of the WinCC project deployment:

1. The project-local GraCS folder (the canonical location for all pictures referenced by name from Graphics Designer).
2. Sub-folders of GraCS registered through WinCC Explorer > Graphics Designer > Picture Manager.
3. Folders declared under WinCC Explorer > Server name > Standard Server > Picture (the picture distribution service list).

An absolute UNC path typed into a tag string is not in this list. The behavior diverges between the server and the client for the following reasons:

3.1 Service Account Context

WinCC runtimes on a server are commonly started under an interactive developer or service-engineer account, which typically has read permission on the network share where the pictures are stored. WinCC runtimes on single clients are commonly started by the CCWriteArchive / CCProjectMgr service under the LocalSystem account, a dedicated runtime user (WINCCUser), or a domain service account. That account frequently does not have a Kerberos ticket for the UNC server, has no NTLM credentials cached for the share, or has not been granted the explicit share and NTFS rights the developer's account enjoys.

3.2 Path Resolution Order

The graphics runtime walks the directory list, not the Windows filesystem, when it evaluates a path. A path beginning with \\ is treated as a candidate but is only used when the picture distribution service has explicitly listed it. Otherwise the lookup silently fails and returns a blank bitmap. Tag replication is independent and continues to deliver the string correctly.

3.3 Tag Length and Encoding

Internal WinCC string tags are configured with a fixed length when created. A tag declared as String (16 char) truncates any longer path silently, which can mask the real failure behind a different symptom. Path strings for network shares with deep folder structures routinely require 64-, 128-, or 256-character tags. Always declare the tag with sufficient length (typical engineering practice: 128 chars minimum for product pictures, 256 chars for nested batch structures).

3.4 Picture Distribution Service Behavior

The picture distribution service copies files from the server-side declared folders into the client's local GraCS mirror at the moment the client connects and whenever the source file changes. It does not poll arbitrary UNC paths. Files outside the declared list are not propagated to the client at all.

4. WinCC Picture Distribution Architecture

The diagram shows the two distinct channels:

• Solid blue paths: Pictures declared in the picture distribution list are pushed by the WinCC Picture Distribution Service to each client's local GraCS folder. The Graphic Object can resolve them.
• Dashed red paths: Pictures on the external share \\PANDORA\pictures are never registered, never copied, and the runtime on the client cannot reach them even though the tag string contains the path.

5. Solution 1 — Configure Picture Distribution on the Server

The most direct fix is to make the external picture folder a known picture distribution target so the WinCC runtime copies the files to every client at connection time.

5.1 Prerequisites

• The WinCC project is configured as a multi-client server (WinCC Explorer > Server name must exist in the project tree; not a single-station project).
• You have administrator rights on the WinCC server.
• The picture share is reachable from the server under the WinCC Runtime service account.

5.2 Step-by-Step Procedure

1. Open WinCC Explorer on the server.
2. In the project tree, expand Server name → Standard Server.
3. Right-click Picture and choose Add Folder….
4. Enter the UNC path to the operator-managed share, for example \\PANDORA\pictures. Local paths such as C:\ProductImages are also accepted.
5. Confirm with OK. The new entry appears under Picture.
6. Right-click the new entry and choose Update to push the folder contents to all connected clients immediately.
7. Verify on each client that the files have been copied into the client's local GraCS mirror (default: C:\Programs\Siemens\Automation\WinCC\GraCS\<declared-folder-name>).

6. Solution 2 — Server-Prefixed Path Strings

If the external share is hosted on the same machine that runs the WinCC server, or you can replicate the share to the server, you can simplify the picture-distribution topology by using a server-relative path rather than a UNC path. WinCC always resolves paths under the project root first.

The picture distribution service will copy the files from the declared folder into the client GraCS mirror. From the client's perspective, the picture is now local and the Graphic Object resolves it without network access.

7. Solution 3 — Siemens FAQ 15292178 Workaround

Siemens' own support FAQ 15292178 documents the runtime behavior of external pictures in WinCC. The FAQ confirms that picture files used by a Graphic Object must reside in directories the picture distribution service can enumerate. The recommended workarounds, paraphrased and extended for production use, are:

1. Symbolic link into GraCS. On the server, run mklink /D "C:\WinCC_Projects\<project>\GraCS\ExternalPics" "\\PANDORA\pictures" at server startup (Task Scheduler, startup script, or WinCC @PROJECT_STARTUP trigger). The WinCC runtime then sees ExternalPics\1.jpg as a local GraCS path.
2. Scheduled mirror. A Windows Scheduled Task invokes robocopy \\PANDORA\pictures C:\WinCC_Projects\<project>\GraCS\ExternalPics /MIR /Z /R:2 /W:5 every N minutes. WinCC picture distribution propagates the mirror to clients automatically.
3. WinCC-side copy. Use the WinCC script shown in Solution 4 to copy pictures into GraCS at project startup.

8. Solution 4 — Server-Side Picture Staging Script

For installations with thousands of operator-managed pictures where placing all files in GraCS is impractical, a startup script that mirrors the external share into a local GraCS sub-folder is the most maintainable option. The script must run in the WinCC server context (not the client).

8.1 VBScript Triggered at Server Startup

' WinCC server-side script - Project module
' Trigger: Project module -> standard function -> OnProjectStartup
Option Explicit

Sub OnProjectStartup()
    Dim fso, srcFolder, dstFolder, srcFile, dstFile
    Set fso = CreateObject("Scripting.FileSystemObject")

    srcFolder = "\\PANDORA\pictures"
    dstFolder = "C:\WinCC_Projects\MyPlant\GraCS\ExternalPics"

    If Not fso.FolderExists(dstFolder) Then
        fso.CreateFolder(dstFolder)
    End If

    ' Sync new files at startup; large folders may require throttling
    Dim f
    For Each f In fso.GetFolder(srcFolder).Files
        dstFile = dstFolder & "\" & f.Name
        If Not fso.FileExists(dstFile) Then
            f.Copy dstFile
        End If
    Next

    Set fso = Nothing
End Sub

8.2 Picture-Staging Tag Mapping

Once files exist in GraCS\ExternalPics, the tag values must be rewritten to the local GraCS path so the runtime can resolve them on every client. Update the C/VBScript that builds the path string:

' WinCC C-script - on tag change of strPicPath
// Replace UNC prefix with local GraCS path
char *p = strstr(szTagValue, "\\\\PANDORA\\pictures\\");
if (p == szTagValue)
{
    sprintf(szNewValue, "ExternalPics\\%s", szTagValue + strlen("\\\\PANDORA\\pictures\\"));
    SetTagChar("strPicPath", szNewValue);
}

On the server the path can stay UNC (the developer account has share access); the rewrite step happens on each client runtime, or the server-side staging script can also do the rewrite at copy time.

9. Solution 5 — Client-Side UNC Considerations

If the architecture requires that clients read pictures directly from the external UNC share (no server-side staging), the following checklist eliminates the most common silent failures:

9.1 WinCC Runtime Account Configuration

1. Open the Windows Services console (services.msc) on each client.
2. Locate CCProjectMgr and CCWriteArchive services.
3. Change the logon account to a dedicated domain service user that has read access to the picture share.
4. Restart the WinCC Runtime.
5. Verify by checking the Windows Security event log on the share host for successful logons from the runtime account.

10. Verification Procedure

After applying any of the five solutions, validate the configuration in the following order:

1. Open WinCC Explorer → Server → Standard Server → Picture and confirm the external folder is listed. If it is grayed out, the folder is unreachable from the server under the WinCC account.
2. Right-click the project node and choose Rebuild Pictures to force a recompile of the picture cache.
3. On the server, open the runtime and confirm the Graphic Object renders the picture.
4. From a single client, reconnect to the server (or use WinCC Explorer → Server → Update Clients).
5. Inspect the client's local GraCS mirror (typical paths: C:\Programs\Siemens\Automation\WinCC\GraCS for V7.x or C:\Siemens\Automation\WinCC\GraCS for older versions). Confirm the expected picture files exist locally.
6. Open the runtime on the client and confirm the Graphic Object renders.
7. Repeat with a cold boot of the client to confirm the picture is delivered at connection time, not just during a hot update.

11. Diagnostics and Logging

If the picture still does not appear on the client after applying the chosen solution, collect the following evidence before escalating:

• WinCC diagnostic files: %TEMP%\WinCC_<date>\<time>\ on the server and each client. Look for lines containing CCPic, CCDist, or graphic.
• Windows event log: Application channel, source CCWriteArchive / CCProjectMgr, event IDs 1xx to 9xx indicating picture distribution failures.
• SMB share access log on the file server: confirm whether the client runtime account reaches the share at all.
• Process Monitor trace filtered to the runtime process and to \\PANDORA\pictures: confirms whether the runtime opens the file.
• Tag monitor (WinCC Channel Diagnosis): confirms whether the picture-path tag is identical on server and client.

12. Troubleshooting Matrix

FAQ