WinCC TIA Portal V13/V15 VBScript Debugger: Fixing Install Errors

Resolving the TIA Portal WinCC V13/V15 VBScript Debugger "Not Properly Installed" Error on Windows 7 32-bit

This technical reference covers the complete toolchain required to attach the Microsoft VBScript debugger to SIMATIC WinCC Runtime Advanced and Runtime Professional in TIA Portal V13, V14, V14 SP1, V15, and V15.1. It targets the specific symptom reported when a breakpoint attach fails with "Unable to open script document. The debugger is not properly installed", and covers the Windows 7 32-bit stack where the legacy external Visual Studio Express path is still the only feasible route. Modern alternatives (TIA V17 integrated debugger, WinCC Unified runtime debugger) are documented in the closing sections for engineers planning a migration.

1. Problem Statement and Symptom Description

When a developer follows the official Siemens procedure for attaching the VBScript debugger to a running WinCC Runtime (see the Siemens KB entry 59885894 workflow for breakpoint debugging), the IDE reports the following error at step 5 of the attach sequence:

"Unable to open script document. The debugger is not properly installed."

This message originates from the script engine COM layer (IActiveScriptDebug::GetScriptTextAttributes / IDebugDocumentHost binding) when one of the following conditions is true:

1. The Windows Script Debugger proxy library (scdwb.dll) is not registered on the target machine.
2. Visual Studio Express 2013 for Windows Desktop (or the version expected by the TIA Portal revision) is installed but its Just-In-Time (JIT) registration is missing or pointing to the wrong bitness.
3. The TIA Portal component Siemens.Script.DebuggerHost cannot locate a compatible vbscript.dll because the VBScript engine is the 32-bit build and the host IDE is 64-bit (or vice-versa).
4. The script project is open in the correct TIA Portal (e.g. V15) but the Runtime running on the target is from a different TIA Portal version (e.g. V14) and the debugger COM contract has changed.
5. User Account Control (UAC) prevented registration of the script debugger when the installer ran, leaving stale registry entries under HKCR\CLSID\{EE2B851B-1907-4D1E-BE4B-3F36E36A4282}.

The error is non-fatal at runtime — the script itself continues to execute — but it blocks all interactive debugging, which is the only practical way to inspect SmartTags, HMIRuntime, and ScreenItems at execution time.

2. WinCC Version Matrix, OS Support, and Debugger Strategy

The correct debugger strategy is dictated by the TIA Portal version, the Windows version, and the target bitness. The matrix below summarizes the supported combinations; cells outside the supported matrix are the root cause of most "debugger not properly installed" reports.

3. VBScript Debugger Architecture in WinCC Runtime

WinCC Runtime hosts a script engine that processes VBScript (and on Comfort Panels, VBScript subset). The script engine is the Microsoft vbscript.dll COM in-process server, exposing IActiveScript and IActiveScriptParse. Debugger support is provided through the additional IActiveScriptDebug interface, which routes execution control to an external debugger through the Windows Script Debugger proxy (scdwb.dll).

The attach sequence is:

1. Debugger launch: TIA Portal (or the standalone VS Express IDE) starts and registers itself as the JIT debugger via the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger.
2. Runtime handshake: WinCC Runtime calls IActiveScript::SetScriptSite on a debug document host implementation. The host queries the registry for the registered debugger CLSID and instantiates it through CoCreateInstance.
3. Source document binding: The debugger receives IDebugDocumentContext objects for each script in the project. If the document cannot be opened (the symptom in question), the host returns E_FAIL and the IDE displays the localized message.
4. Breakpoint exchange: The IDE calls IDebugDocument::EnumCodeContexts to enumerate IDebugCodeContext instances; the runtime inserts breakpoints via IActiveScriptDebug::CreateDebugDocumentHelper.
5. Execution halt: When a breakpoint is hit, the runtime raises SCRIPTSTATE_CONNECTED and pumps the debug events to the IDE. The IDE then displays the current call stack and local variables.

Any failure in steps 1, 2, or 3 produces the "debugger is not properly installed" message. Failures in step 4 produce a different error ("Breakpoint cannot be set"), and step 5 failures produce "Script engine stopped responding".

4. Prerequisites

Before touching the registry or installing components, verify the following prerequisites on the development workstation (not the runtime target, unless you are debugging on the same machine).

4.1 Operating System Requirements

• Windows 7 SP1 32-bit: TIA Portal V13, V14, V14 SP1 only. Must have the Windows 7 SP1 update installed before any TIA Portal DVD setup is run.
• Windows 7 SP1 64-bit: TIA Portal V13, V14, V14 SP1, V15, V15.1 supported.
• Microsoft .NET Framework 4.7.2 (or the version bundled with the TIA Portal DVD). WinCC V13 originally shipped with .NET 4.5; later revisions require 4.7.2.
• Windows Script Host 5.8 (default on Win 7). Verify with cscript //H:WScript from an elevated command prompt.
• Internet Information Services (IIS) enabled with the CGI and ISAPI Extensions role services, required by the TIA Portal online help and OPC UA gateway.

4.2 Visual Studio Express 2013 for Windows Desktop

For TIA Portal V13 / V14, the supported external debugger is Microsoft Visual Studio Express 2013 for Windows Desktop with Update 5. The "for Windows Desktop" SKU must be selected — not "for Web" or "for Windows", which lack the managed and native COM hosting required to host the scdwb.dll bridge.

Verify the install with the following command:

For TIA Portal V15, the supported version is VS Community 2015 Update 3 or VS Community 2017 (15.9.x). Express 2013 is no longer compatible at the COM contract level. The download is available from the Visual Studio Older Downloads page on the Microsoft site.

4.3 Local Administrator Rights

Both the TIA Portal installer and the VS Express installer must run with elevated privileges. If the workstation is part of a domain with restricted group policy, confirm that the user has local administrator rights and that UAC is set to the default level (second notch from bottom). Running the installers in silent mode (e.g. setup.exe /quiet) often skips the UAC prompt and leaves the JIT debugger unregistered.

5. Step-by-Step: Enabling the External Debugger in WinCC V13 / V15

The procedure below repairs an install where the script debugger was not registered correctly. Run each step from an elevated Command Prompt (right-click → Run as administrator).

Step 1 — Verify the VBScript Engine

Confirm the bitness of vbscript.dll matches the host OS:

A successful registration produces a dialog "DllRegisterServer in vbscript.dll succeeded". If the dialog is silent and the command returns immediately, the DLL is already registered.

Step 2 — Register the JScript Engine and Windows Script Components

On 32-bit hosts, repeat with the SysWOW64\regsvr32.exe path. On Windows 7, the wshom.ocx and wshext.dll files are part of the optional Windows Script Host Windows feature; if the files are missing, install the Windows Script 5.8 package from the Microsoft Download Center.

Step 3 — Install and Register the Microsoft Script Debugger Proxy

Windows 7 does not ship with the scdwb.dll proxy that brokers between the VBScript engine and the Visual Studio IDE. The proxy must be installed explicitly:

1. Download the Microsoft Script Debugger package (the standalone scd10en.exe self-extractor is no longer hosted by Microsoft; obtain from the TIA Portal DVD under Redist\ScriptDebugger\ if present, or from a verified corporate mirror).
2. Extract to C:\ScriptDbg\.
3. Register the proxy: regsvr32 C:\ScriptDbg\scdwb.dll
4. Verify the registry key HKCR\CLSID\{EE2B851B-1907-4D1E-BE4B-3F36E36A4282}\InprocServer32 points to the registered path. The CLSID is the script debugger's IDebugDocumentHost implementation.

Step 4 — Configure the JIT Debugger in the Registry

The JIT debugger key tells Windows which IDE to launch when a script halts unexpectedly and when WinCC Runtime calls DebugBreak on the script host. Set the value to the path of VS Express:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"="\"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\WDExpress.exe\" -d"
"Auto"="1"

For TIA Portal V15 on 64-bit Windows, use VS 2015 / 2017 Community instead:

Step 5 — Configure WinCC Runtime Debugger Settings

In the TIA Portal project tree, right-click the HMI device and select Properties → Runtime Settings → Scripts. Enable:

• Use external debugger (checkbox)
• Path to debugger: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\WDExpress.exe
• Wait for debugger connection on startup: optional; useful when you want to debug scheduler events that fire before the operator can click a button.

Compile the project and download to the Runtime. The Runtime will register a script-host process with the COM moniker WinCC.Script.Host.{PID}; the IDE enumerates running hosts and presents them in the Attach to Process dialog under the Script code type.

Step 6 — Attach the Debugger

1. Start the WinCC Runtime in Runtime with debugging enabled mode.
2. In WDExpress, press Ctrl+Alt+P to open Attach to Process.
3. Select the Show processes from all users checkbox.
4. Locate CCRtScsHost.exe (WinCC RT Professional) or HMIRTM.exe (WinCC RT Advanced).
5. Set Attach to: to Script.
6. Click Attach. After 2–3 seconds the IDE should display the project scripts in the Solution Explorer under a Running Documents node.

If the attach succeeds but the breakpoint gutter displays a hollow red circle with the tooltip "The breakpoint will not currently be hit. No symbols have been loaded for this document", the script compiled but the debug document helper was not enabled. Re-check step 5 and ensure the Runtime is not running in Demo mode (which strips debug symbols).

6. Registering Windows Script Components: Detailed Reference

The Windows Script stack is fragile on Windows 7 32-bit because the OS does not enforce strong registration. After every major Windows update (KB3033929, KB3125574, and the monthly rollup cycle), it is worth re-running the following batch script. Save as fix_script_debugger.bat and execute elevated:

@echo off
setlocal
set SYS32=%windir%\System32
set WOW64=%windir%\SysWOW64

echo --- Re-registering 32-bit script components ---
%WOW64%\regsvr32.exe /s %WOW64%\vbscript.dll
%WOW64%\regsvr32.exe /s %WOW64%\jscript.dll
%WOW64%\regsvr32.exe /s %WOW64%\scrobj.dll
%WOW64%\regsvr32.exe /s %WOW64%\wshom.ocx
%WOW64%\regsvr32.exe /s %WOW64%\wshext.dll

echo --- Re-registering 64-bit script components ---
%SYS32%\regsvr32.exe /s %SYS32%\vbscript.dll
%SYS32%\regsvr32.exe /s %SYS32%\jscript.dll
%SYS32%\regsvr32.exe /s %SYS32%\scrobj.dll

echo --- Re-registering script debugger proxy ---
%WOW64%\regsvr32.exe /s "C:\ScriptDbg\scdwb.dll"

echo --- Setting JIT debugger ---
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Debugger /t REG_SZ /d "\"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\WDExpress.exe\" -d" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d 1 /f

echo Done.
endlocal

The /s switch suppresses the success dialogs; check the errlevel in the script with if errorlevel 1 if you want explicit error trapping.

7. Configuring Visual Studio Express 2013 for WinCC

A fresh VS Express 2013 install defaults to VB.NET and C# project types and does not recognize the .bms or embedded VBScript files in a WinCC project. The IDE must be configured to:

1. Show "Script" in the Attach to Process dialog: Tools → Options → Debugging → General → Show All Settings. The Script code type is hidden by default in the Express SKU.
2. Enable the Just-In-Time Script option: Tools → Options → Debugging → Just-In-Time. Tick Script.
3. Disable the "Enable Edit and Continue" for Script: this is not supported by the WinCC host and can produce the same attach error in reverse.
4. Set the default solution location to a writable folder, e.g. D:\WinCC_Debug\. WinCC generates a temporary solution file at runtime; if the default is Program Files UAC will block the write and the IDE will fail silently.

8. Resolving the 32-bit vs 64-bit Mismatch

The most common cause of the error on a 64-bit Windows 7 host is the 32-bit / 64-bit script engine mismatch. WinCC Runtime is a 32-bit process under WoW64, and the vbscript.dll it loads is from C:\Windows\SysWOW64. If the JIT debugger key points to the 64-bit devenv.exe, the debugger will fail to attach with the symptom in question.

Quick diagnostic — list the loaded DLLs in the WinCC process:

Expected output:

The path of the loaded DLL can be confirmed with Process Explorer from the Sysinternals Process Explorer page. The column Company / Description must read Microsoft Corporation / Microsoft ® VBScript and the path must include SysWOW64 on a 64-bit host.

9. Modern Alternative: TIA Portal V16+ Integrated Debugger

From TIA Portal V16 onward, the script debugger is integrated into the TIA Portal itself; no external Visual Studio is required. The workflow is:

1. Open the HMI project in TIA Portal V16 / V17 / V18.
2. Right-click the HMI device → Start Runtime with the Debug flag set.
3. Open the VBScript editor, click in the gutter to set a breakpoint.
4. Trigger the script event. TIA Portal halts at the breakpoint and shows locals, call stack, and watch windows inline with the engineering tree.

This is the recommended path for any new project. The error described in this article does not occur in V16+ because the script host and the debugger are the same bitness and are co-located in the same process.

10. Modern Alternative: WinCC Unified Script Debugger

WinCC Unified (TIA Portal V17+) ships with a dedicated runtime script debugger. To enable it, follow the procedure in the official Enabling the Debugger (RT Unified) documentation. The relevant steps are:

1. Start the SIMATIC Runtime Manager application on the Unified PC.
2. Click the settings button in the toolbar.
3. Switch to the Scripts Debugger tab.
4. Enable Use external debugger and provide the path to the IDE (Visual Studio Code 1.78+ or TIA Portal integrated).
5. Restart the Unified Runtime and re-attach.

Note that WinCC Unified scripts use JavaScript rather than VBScript, so the error message and the underlying COM plumbing are different. The classic "debugger is not properly installed" error does not apply to Unified unless the JS engine ChakraCore is missing.

11. Debugging VBScripts Without an External IDE

When the debugger cannot be installed (locked-down production machine, GPO restrictions on the script debugger proxy), the following in-script techniques provide acceptable visibility.

11.1 MsgBox and ShowSystemAlarm

Insert temporary diagnostic statements that surface variable state to the operator:

Sub OnClick(ByVal Item)
    Dim sMsg
    sMsg = "Tag1=" & SmartTags("Tag1") & vbCrLf & _
           "Tag2=" & SmartTags("Tag2") & vbCrLf & _
           "Now=" & Now
    MsgBox sMsg, vbInformation, "OnClick trace"
    ShowSystemAlarm "OnClick trace: " & sMsg
End Sub

ShowSystemAlarm writes to the WinCC message system and is observable from a remote client without interrupting the Runtime. Remove all diagnostic calls before going into production.

11.2 HMIRuntime.Trace to a Log File

WinCC exposes a tracing API that writes to C:\ProgramData\Siemens\Automation\Trace.log when enabled in the Diagnostics view of the Runtime:

Tracing is non-intrusive and survives Remote Desktop disconnection. Enable it in the TIA Portal project properties under Runtime → Diagnostics → Trace, with verbosity level Verbose for full script I/O.

11.3 Smart Tag Logging

Bind a hidden internal tag @DebugLog to a text-based tag and append trace lines to it. The tag can be archived with a 1-second logging cycle for post-mortem analysis:

SmartTags("@DebugLog") = SmartTags("@DebugLog") & _
    Format(Now, "hh:nn:ss") & " OnClick Tag1=" & SmartTags("Tag1") & vbCrLf

12. Troubleshooting Matrix

13. Verification Checklist

Run through the following checks before declaring the debugger operational. All must pass for a production-grade attach:

1. Registry check: reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" returns the expected IDE path.
2. Component check: reg query "HKCR\CLSID\{EE2B851B-1907-4D1E-BE4B-3F36E36A4282}" /s returns InprocServer32 pointing to scdwb.dll.
3. Engine check: from the elevated prompt, run cscript //X "%windir%\system32\notepad.exe" — the script debugger must launch and stop at the notepad startup. If it does, the engine is wired correctly.
4. Project check: compile a minimal VBScript that calls Stop. Attach the debugger. The IDE must halt at the Stop line.
5. Production check: on the production Runtime, confirm the same Stop test halts; if it does not, the Runtime is running in Service mode and the JIT handler is suppressed by the SCM.
6. Log check: in TIA Portal Online → Diagnostics, set trace level to Verbose and confirm trace lines are being written to the configured file or DB.

14. Migration Path: From V13/V15 to V17+

For sites that have standardized on Windows 7 32-bit, the cleanest long-term fix is to upgrade the engineering toolchain rather than fight the legacy debugger. The migration steps are:

1. Verify the project compiles under TIA Portal V17 on a Windows 10 64-bit engineering station.
2. Re-license WinCC Runtime (the license is tied to the V13/V15 ticket and must be re-issued for V17).
3. Replace the panel or PC Runtime — WinCC RT Advanced V17+ no longer supports Windows 7 32-bit. Comfort Panels running V14 firmware can be re-flashed to V16/V17 if the panel is a 4th-generation KP/TP/Comfort.
4. Adopt the integrated debugger (no Visual Studio install required).

The VBScripts themselves are 95% source-compatible between V13 and V17. Differences are limited to the new ScreenItems accessors introduced in V15.1 and the deprecated HMIRuntime.BaseScreenName property removed in V16.

15. Safety and Operational Notes

16. Frequently Asked Questions