WinCC flexible Faceplate Editor Won't Open: DLL, Not RAM

When Create faceplate spikes the CPU to ~90% for five to ten seconds and the window redraws with nothing new on it, the engineering shell has already created the faceplate object and then failed to start the editor that would host it. The failed instance still counts against the shell's ceiling of 20 concurrently open editors, so after a few retries the Output window reports Only a maximum of 20 editors can be open simultaneously. Close at least one editor to open another one. while a single screen is visible. The same failure on new script moves the fault off the faceplate component and onto the shared editor-hosting layer of the installation. Restarting the application clears the counter; reapplying the hotfix or repairing the WinCC flexible installation clears the fault.

Symptom Reading

Three terms, used consistently below. An editor is a document window the WinCC flexible engineering shell loads to edit one object — screen, script, tag table, faceplate. A faceplate is a compound object stored in the project library and instantiated on screens. A placeholder entry is a library item whose editor never wrote content into it; it renders with a question-mark icon and accepts only Delete.

Mechanism: Editor Hosting and the 20-Editor Ceiling

The shell handles Create faceplate in two phases. Phase one builds the object from the selected screen items — the text field and the IO field — and registers it in the project library. Phase two loads the faceplate editor component and hands it the new object. The counter that enforces the 20-editor limit increments at the start of phase two, before the document window is rendered, and decrements only when the editor closes cleanly. An editor that never comes up never closes, so every attempt consumes one slot permanently until the process exits.

Editor components are registered COM servers. They fail to load for a small set of reasons: an installer from another product overwrote a shared runtime DLL with an older or incompatible build; a hotfix was applied over a mismatched service-pack baseline and left mixed binaries; or a registration entry was lost during an interrupted install. The 5–10 second CPU burn is the load attempt walking dependencies and failing, not computation. Because the faceplate editor and the script editor fail the same way, the broken dependency sits below both of them, in the shell's document-hosting layer — which is why no amount of project surgery helps and why a repair of the installation does.

Isolation Sequence

1. Record the exact level from Help > About. Expect Version: 2005 SP1 HF4 and build: K1.1.1.4_1.2.0.1. The build string, not the version string, tells you whether the hotfix binaries actually landed.
2. Close the application completely, reopen the project, attempt one faceplate. Expect the same silent failure but no limit message — confirming the counter is per-session and the leak is the mechanism.
3. Stop after the second attempt. Every further retry costs another slot and another placeholder entry written into the project file.
4. Open Task Manager, enable the Handles and Threads columns, and watch the engineering process across two attempts. Expect a monotonic rise with no release after each failure.
5. Build an empty project with one text field and one IO field on a single screen and repeat. Expect identical behaviour; that result puts the fault in the installation and ends any project-level investigation.
6. Exclude the project folder and the Windows temp directory from on-access virus scanning, then retry. If the editor opens, the scanner was locking the editor's temp files. If nothing changes, the fault is registration.
7. Log on with local administrator rights and place the project on a short local path such as C:\hmi\test. Network shares and long paths break the editor's temp-file writes independently of the registration fault; clearing both removes them from the list.

Repair Procedure

1. Delete every question-mark faceplate from the project library, save, and close the project. They cannot be edited or repaired, and they travel with the project file.
2. Run the HF4 setup again over the existing SP1 installation and reboot. Reapplying a hotfix re-registers the components it owns and is the cheapest action that fixes this class of fault.
3. If the behaviour persists, run the WinCC flexible setup's repair/modify path, then reapply HF4 — repair restores base service-pack binaries and drops the hotfix.
4. If it still persists, uninstall and reinstall WinCC flexible. On any engineering station, install SIMATIC software last, after every other vendor's tools; third-party installers routinely replace shared DLLs that SIMATIC editors depend on, and the damage surfaces weeks later in whichever editor you use least.
5. Where reinstalling the workstation is not acceptable, build the isolation case instead: a virtual machine with a clean Windows XP install and WinCC flexible as the only application. A faceplate that creates normally there proves the media and the hotfix are sound and the host installation is contaminated. Keep other vendors' legacy packages inside their own virtual machines from then on.

Verification Checks

1. Check 1 — version. Help > About: expect the version and build strings to match the level you just installed, with the build string carrying the hotfix.
2. Check 2 — faceplate creation. In the empty test project, select the text field and the IO field and create a faceplate: expect the faceplate editor to open as a document window within a couple of seconds and the library entry to show a rendered preview, not a question mark.
3. Check 3 — faceplate round trip. Add an object inside the faceplate, close the editor, reopen it: expect the object to persist and the library icon to stay intact.
4. Check 4 — script editor. Create a new VB script: expect a code window containing the generated procedure skeleton and the script listed in the project tree.
5. Check 5 — counter release. Open eight to ten editors deliberately, close them all, then create one more faceplate: expect no limit message, proving slots are being released on close.
6. Check 6 — runtime. Drag the faceplate onto a screen, generate the runtime for the PC Runtime device, and start it: expect zero compiler messages referencing the faceplate and the instance's IO field reading and writing its tag.

Recurring Pitfalls

• Retrying the failed command. The instinct to click again is what turns one dead editor into twenty and one placeholder entry into a library full of them. One retry to confirm, then stop.
• Treating Reset Layout as a remedy. It restores docking positions. It does not enumerate, close, or release editor instances, and a hidden editor is not a mis-docked one.
• Shipping placeholder entries. Copying or archiving a project that still contains question-mark faceplates propagates them to every engineer who opens it. Delete them before the project leaves the station.
• Chasing hardware. A 1.4 GHz Pentium M with 1.5 GB RAM sits near the practical lower limit for this toolchain and will feel slow, but a registration fault is deterministic; adding RAM changes nothing.
• Ignoring install order. The failure signature — multiple unrelated editors dying the same way — is the classic fingerprint of a shared DLL swapped out by a later installer.
• Losing the hotfix during repair. After any repair or modify run, reopen Help > About and confirm the build string still reads K1.1.1.4_1.2.0.1; if it has reverted, reapply HF4 before testing anything else.

FAQ