Troubleshooting B.Data Kernel Server: WinCC 163910 Error

Problem Summary

The B.Data Kernel Server (the data acquisition service that transfers time-stamped process values from WinCC Tag Logging archives into the B.Data relational database) loses its connection to the WinCC runtime while WinCC Tag Logging itself continues to archive values into native WinCC archive files without error. The defect manifests in three correlated symptoms observed in the field:

1. Repeated entries in the B.Data kernel trace:
   WinCC: Can't update 'SERVERPREFIX::io_Buffer_TAGNAME' (163910) - Connection to WinCC is down.
2. Read-side failure when B.Data Explorer or any OPC HDA client requests archive values:
   GetArchiveData from WinCC not successful - SERVERPREFIX::io_Buffer_WinCC_TAGNAME Error Codes - 268435483 0 447 0 0 - TLG-API: an error occurred, line 447
3. Kernel process instability:
   The Windows Error Reporting dialog "B.data Kernel server has stopped working" appears, and the B.Data Kernel service returns to the "Stopped" state within seconds of every manual start.

A fourth, related symptom appears in single-station (no dedicated WinCC Server) deployments: every referenced datapoint fails with "TLG-API: an error occurred, line 809", indicating the datapoint does not exist in the local Tag Logging configuration.

Restarting the WinCC Client and the B.Data Kernel Server does not clear the condition. Regenerating the WinCC Client package from the WinCC Server (Resolution Path B below) recovers the historical backlog, but exposes the underlying kernel-side fault, which then crashes the service.

System Architecture and Process Topology

A B.Data installation with WinCC runtime is partitioned across five logical tiers. The first diagnostic step is to determine which tier is failing.

In the symptom set above, Tier 1 and Tier 2 are healthy: tag logging writes values to native archives and the WinCC client/server connection test passes. Tier 3 partially recovers after re-packaging. Tier 4 is the locus of the fault on both the write path (kernel crash) and the read path (TLG-API line 447). Tier 5 may be involved if the kernel crash root cause is database-side. The diagnostic focus is therefore on Tier 3 <-> Tier 4 communication and on Tier 4 process stability.

Communication Paths Used by the Kernel

The B.Data Kernel reaches the WinCC archive data through three channels, in order of preference:

The kernel writes buffered values through Channel B (or its RDBMS write path that bypasses WinCC) and reads historical archives through Channels A or C. A failure on Channel B is the typical root cause of the 163910 "Connection to WinCC is down" error on the write path, while failures on Channels A or C manifest as line 447 or line 809 errors on the read path.

Error Code Reference

Error 163910 - "Connection to WinCC is down"

The numeric code 163910 is a B.Data native error raised by the kernel when the WinCC connectivity channel reports that the server-side archive subsystem is unreachable. It is not a WinCC internal Win32 error code; it is the B.Data abstraction layer translating an underlying WinCC or DCOM failure into a human-readable text "Connection to WinCC is down". When paired with the io_Buffer_ tag prefix, it means the kernel attempted to push a buffered value into the WinCC-side acquisition buffer (Channel B above) and the call was rejected because the server process, the archive manager, or the OLE DB provider was not responsive. Typical underlying causes are:

• WinCC Server process stopped or restarted while the kernel still held open connections.
• DCOM permissions revoked for the B.Data service user after a Windows update or GPO change.
• WinCC project recompiled mid-flight, dropping all OLE DB sessions.
• Network path between B.Data Server and WinCC Server interrupted (firewall, route, switch).
• B.Data Kernel and WinCC Client running under mismatched OS users (see Resolution Path A).

Error 268435483 with TLG-API Line 447

The composite error 268435483 0 447 0 0 returned by the kernel trace is a structured WinCC Tag Logging API (TLG-API) error. The leading value 268435483 (hex 0x1000001B) encodes the failure category and TLG subsystem; the trailing value 447 identifies the source line within the TLG-API implementation that raised the exception. Operationally, line 447 is observed when:

• The datapoint referenced in B.Data does not exactly match the WinCC Tag Logging tag name (case, server prefix, or suffix mismatch).
• The archive configuration on the WinCC side has been modified after the B.Data package was generated (tag removed, archive renamed, archive cycle changed, archive segment switched).
• The WinCC project is in a state where the requested archive segment is not loaded (archive server switched off, archive manager pending reconfig, or the segment has been manually disabled).
• The WinCC Server has been restarted with a different project or a different server prefix than the one in the B.Data package.

TLG-API Line 809 - Datapoint Not Available

The follow-on error "...line 809..." reported in single-station WinCC projects is a distinct TLG-API failure. Whereas line 447 means the datapoint exists but the read failed, line 809 means the datapoint does not exist in the WinCC Tag Logging configuration at all. B.Data is querying for a tag that was never registered, or that has been removed from the WinCC project without removing the corresponding B.Data datapoint. In the source case the user noted "I have the same problem but I deal with WinCC without server only" - the single-station topology where WinCC Runtime and B.Data run on the same machine is the most common environment for line 809 errors because tag additions are made directly on the runtime machine and the B.Data datapoint list is not always refreshed in the same change window.

"B.data Kernel server has stopped working" Dialog

This is the Windows Error Reporting (WER) dialog displayed when BDataKernel.exe terminates unexpectedly - that is, exits with a code other than a clean stop request, or with an unhandled exception that crashes the process before it can shut down cleanly. It is not a B.Data native fault code; it is the OS reporting that the process exited within the default application hang/crash detection window (typically 5 seconds for crash, 60 seconds for hang). Field-proven correlates are:

• An unhandled exception inside the kernel triggered by the WinCC side repeatedly returning the 163910 error.
• Database write failures (Oracle OCI error, deadlocked session, full tablespace, lost ODBC connection) that the kernel does not recover from.
• Corrupt local buffer files in the configured B.Data buffer directory.
• OS-level session change (lock, sleep, UAC prompt, credential expiry) under a mismatched or expiring service account.
• Antivirus or backup software holding an exclusive lock on the buffer files or the database DLLs.

Root Cause Taxonomy

The source conversation identifies four independent root cause families, each with a distinct fingerprint in the trace and a distinct resolution path.

In a real plant, multiple families often co-exist. A typical cascade is Family B (stale package) -> Family C (datapoint mismatch surfaces once the new package is loaded) -> Family D (kernel crashes when read path repeatedly fails). Family A may be present from the start or may be introduced by a recent change of service account.

Pre-Repair Diagnostic Checklist

Execute the following checks in order before modifying any configuration. Record the result of each step for the change record.

1. Tag Logging state on the WinCC server. Open WinCC Explorer on the WinCC Server. Confirm Tag Logging shows green. Verify archive files in the project's \ArchiveManager directory are growing in real time by checking file modification time stamps over a 60-second window.
2. WinCC client/server connection. On the WinCC Client, open WinCC Explorer. Confirm the server prefix resolves without red entries. Test ping and net use \\\<server\>\<project\> from the WinCC Client to confirm share access for the package directory.
3. Identical OS user. Open Task Manager > Details, add the "User Name" column. Confirm CCEServer.exe (WinCC Client) and BDataKernel.exe show the same domain\user. If they differ, both must be reconfigured before any other fix.
4. Datapoint resolution in B.Data. In the B.Data datapoint configuration, copy the archive tag name from a known-failing datapoint and paste it into the "Address" field. Confirm the dropdown resolves a valid WinCC archive entry. If the dropdown is empty, the datapoint does not exist in WinCC (line 809 class).
5. Kernel trace review. Open the kernel trace file (default %BDataRoot%\Kernel\Trace\*.trc). Grep for 163910, 268435483, line 447, line 809, and Connection to WinCC is down. Tally the count per tag to determine whether the problem is a subset or global.
6. Database connectivity. From the B.Data Server, test the ODBC data source configured for the B.Data database using the same user as the B.Data service. Confirm SELECT SYSDATE FROM DUAL (Oracle) or SELECT GETDATE() (MS SQL) succeeds. Check the ODBC trace log if it is enabled.
7. Disk space and quotas. Confirm the disks hosting %BDataRoot%, the WinCC archive directory, and the database data files have at least 15% free. Confirm any per-user disk quotas (for terminal server or Citrix deployments) are not exhausted for the B.Data service user.
8. Recent project and environment changes. Interview operations and the controls team. Was the WinCC project edited? Was a new tag added? Was an archive cycle reconfigured? Was a Windows update applied recently (DCOM, Kerberos, firewall rules)? Was the B.Data service account password rotated? Was antivirus updated?
9. Antivirus and backup exclusions. Confirm the B.Data directories, WinCC project directories, and database data directories are excluded from real-time antivirus scans and from open-file backup agents. Confirm no backup job is currently holding a lock on buffer or archive files.

Resolution Path A - Align the OS User Accounts

The single highest-yield fix when the kernel trace shows 163910 and TLG-API line 447 errors and Tag Logging on the WinCC side is healthy. This corresponds to Family A in the taxonomy above.

1. Identify the user account under which the WinCC Client starts. This is the account that launched CCEServer.exe (interactively) or the account configured for the WinCC Client service.
2. On the B.Data Server, open services.msc. Locate the B.Data Kernel service. Stop it.
3. Open the service properties > Log On tab. Change the service logon to match the WinCC Client user. Enter and confirm the password. Apply.
4. If the B.Data Kernel is started as an interactive application rather than as a service, log off, log on as the WinCC Client user, and start the kernel from that session.
5. If the WinCC Client is also a service, reconfigure its logon account to match the B.Data Kernel account exactly.
6. Restart the WinCC Client runtime if it was running under a different account.
7. Re-package the WinCC Client from the WinCC Server (see Resolution Path B).
8. Start the B.Data Kernel. Monitor the trace for 10 minutes; confirm no new 163910 entries and no TLG-API line 447 / line 809 entries.

Resolution Path B - Regenerate the WinCC Client Package

The source case was resolved on the read path by this action: "I created a new package for WinCC Client from WinCC Server. The loss of data was retrieved." This is the correct first action whenever tags have been added, renamed, or archive cycles changed on the server since the last package was generated. It corresponds to Family B in the taxonomy above.

1. On the WinCC Server, open WinCC Explorer.
2. Confirm the server project compiles cleanly (no red entries in the project tree, no compiler errors in the output window).
3. Right-click the server project node and select "Generate Server Package". Save to the project-defined package directory (typically \\\<server\>\<project\>\Packages).
4. On the WinCC Client, stop the WinCC Client runtime if running.
5. From the WinCC Client, connect to the server package directory and load the regenerated package: WinCC Explorer > Server data > Load package, or CCPackageImport.exe in unattended deployments.
6. Verify all server tags now show green in the WinCC Client Explorer. Pay particular attention to the tags referenced in the B.Data datapoint configuration.
7. Restart the WinCC Client runtime. Confirm native WinCC archives and trends display recent values.
8. Restart the B.Data Kernel (if it had been stopped). Monitor the trace for new 163910 / line 447 entries.

Resolution Path C - Rebuild Tag Logging and Refresh Datapoints

Required when the kernel trace shows TLG-API line 447 for almost all tags and the datapoint address field cannot resolve the archive. In the source case the suggested path was "Need to re-build the tag logging again in the wincc server first?" This corresponds to Family C in the taxonomy above.

1. On the WinCC Server, open Tag Logging editor.
2. For each archive that B.Data references, confirm the archive exists, has a valid cycle (e.g., 1 s, 1 min, 1 h), and contains the expected tags.
3. If an archive is missing or corrupted, re-create it with the same name and the same cycle parameters. Tag Logging does not allow rename of an archive in place; create a new archive with the original name and migrate tags from the old archive.
4. If individual tags are missing, re-add them to the archive with the same name, same datatype, and same acquisition cycle as before. Do not introduce silent name changes; B.Data datapoints are bound by exact string match.
5. Recompile the WinCC Server project.
6. Re-package the WinCC Client (Resolution Path B).
7. In B.Data, re-import or refresh the datapoints so the address bindings point at the new archive structure. The B.Data datapoint "Address" field must contain the same archive and tag name as the WinCC side; verify each one.
8. Restart the B.Data Kernel. Verify in B.Data Explorer that archive values appear in the long-term tables.

Resolution Path D - Recover the Crashed B.Data Kernel

The "B.data Kernel server has stopped working" symptom, where the service stops immediately after a manual start, requires deeper isolation because it indicates a kernel-side fault, not a WinCC-side fault. This corresponds to Family D in the taxonomy above.

1. Open Windows Event Viewer > Windows Logs > Application on the B.Data Server. Locate the most recent "BDataKernel.exe" entries, and any associated ".NET Runtime", "Application Error", or "Application Hang" entries. Record the faulting module, exception code, and offset.
2. Open the B.Data kernel trace file (most recent file in %BDataRoot%\Kernel\Trace). Look for a stack trace, terminating exception, or repeated OCI / ODBC error message in the seconds preceding the crash.
3. Check the database write path. Connect to the B.Data RDBMS as the service user (the same account that runs the B.Data Kernel service) and confirm the following:
   • The B.Data schema exists (typical tables: BDataArchive, BDataValue, BDataTag, BDataEvent per the project schema).
   • The user has INSERT, UPDATE, DELETE, SELECT on those tables and on any sequences.
   • The tablespace hosting the B.Data tables is not full. Oracle: SELECT * FROM dba_tablespace_usage_metrics. MS SQL: SELECT * FROM sys.dm_db_file_space_usage.
   • There are no deadlocked or blocking sessions holding locks the kernel needs.
   • The transaction log is not full and is not waiting on a log backup.
4. Inspect the local buffer directory (typically %BDataRoot%\Kernel\Buffer). If buffer files are corrupt (zero-byte, truncated, or with modification times older than the configured retention), stop the kernel, move the corrupt files aside (do not delete them - they are evidence), and let the kernel regenerate.
5. Confirm the Oracle client / OLE DB provider / ODBC driver installed on the B.Data Server is the version certified for the B.Data version. Mismatched or recently patched drivers frequently cause silent write failures that crash the kernel on commit.
6. Temporarily redirect the kernel to write to a staging database (a test Oracle or MS SQL instance with the same schema). If the crash disappears, the production RDBMS is the fault and the DBA team must investigate.
7. If the crash persists with the staging database, capture the MCL directory, the kernel trace, the Event Viewer entries, and a process dump (using procdump -ma BDataKernel.exe from Sysinternals ProcDump if available), and escalate to Siemens support with the faulting module and exception code from Event Viewer.

Edge Cases and Field Scenarios

Single-station (no dedicated WinCC Server)

When WinCC Runtime and B.Data are on the same machine, the WinCC Client package step is not required because there is no remote client/server boundary. The kernel connects directly to the local WinCC archive manager. However, this topology is the most common environment for line 809 errors because Tag Logging edits are made directly on the runtime machine and B.Data datapoint refresh is sometimes overlooked. The diagnostic flow collapses to:

1. Confirm Tag Logging on the local WinCC Runtime shows the datapoint.
2. In B.Data, open the datapoint and confirm the Address field resolves to a local archive.
3. Re-import the datapoints from the local WinCC project if resolution fails.

Redundant WinCC Server Pair

When WinCC is deployed as a redundant server pair (WinCC Server A and WinCC Server B with archive replication), the B.Data Kernel may connect to the preferred server and fail over to the secondary on a fault. After a failover, the kernel may retain stale handles and report 163910 for one cycle until the next reconnect. If the 163910 errors coincide with a failover event in the WinCC Server event log, configure the kernel to reconnect on failover and verify the archive server switch time on the WinCC side is within the kernel's reconnect timeout (default 30 s).

Archive Server Switch (Tag Logging Rotation)

WinCC rotates archive segments at configured intervals (typically daily or weekly). During the rotation window (default 30 seconds), the active archive segment is closed and a new one is opened. The kernel may report line 447 errors during this window. If the line 447 errors cluster around a specific time and the system otherwise runs cleanly, this is expected behavior and no action is required other than suppressing the alarm in B.Data.

OS Update or Patched DCOM

A Windows cumulative update frequently resets DCOM launch and access ACLs on the WinCC Server. After any Windows update applied to the WinCC Server, validate the B.Data Kernel user's DCOM permissions on the WinCC application in dcomcnfg.exe. This is the most common hidden cause of a regression where everything was working before the update and now reports 163910.

B.Data Kernel Crash Without WinCC Fault

If the kernel crashes (Family D) without any preceding WinCC-side error (no 163910, no line 447), suspect the database layer. Generate an Oracle AWR report or MS SQL Extended Events trace covering the crash window and look for ORA-03113, ORA-03114, ORA-25408, deadlock graphs, or log waits. The kernel will retry once and then terminate the process if the database rejects writes for the configured retry window.

Preventive Configuration

Verification Procedure

After applying any resolution path, execute the following verification steps and attach the results to the change record.

1. Restart the B.Data Kernel and observe the trace for at least one full archive cycle (default 1 minute) with no 163910 entries, no TLG-API line 447, and no TLG-API line 809.
2. In B.Data Explorer, navigate to a tag that was previously failing and confirm the buffered values populate within one cycle.
3. Force a read of the archive from B.Data Explorer for the failure window and confirm no TLG-API line 447 / line 809 error is returned.
4. Confirm the B.Data Kernel service remains in the "Running" state for at least 24 hours under normal load. Monitor with a scheduled task that polls the service state every 5 minutes.
5. Confirm the database write target has new rows in the B.Data value tables: count the rows before and after one archive cycle and confirm a delta.
6. Capture a screenshot of the B.Data Kernel log file with timestamps and a screenshot of the B.Data Explorer view showing live data; attach both to the change record.
7. Confirm Task Manager shows the same domain\user for CCEServer.exe and BDataKernel.exe and that this matches the documented service account.

Troubleshooting Matrix

Use this matrix to map observed error signatures to the most likely root cause family and the first action to take.

Frequently Asked Questions