SAPI-S7 C# s7_get_multiple_read_cnf: Fix NullRef and Error 80

Problem Overview

Calling s7_get_multiple_read_cnf from the Siemens SAPI-S7 programming interface (s7std.dll / s732std.dll) inside a managed .NET application produces two distinct failure modes depending on how the caller provisions the length and value buffers:

• Single variable reads succeed. The S7_MULTIPLE_READ_CNF message returned by s7_receive decodes correctly and s7_get_multiple_read_cnf returns S7_OK.
• Reads of two or more variables throw System.NullReferenceException when val_length_ptr is provided.
• Reads of two or more variables return API error 80 ("user data buffer too small") when val_length_ptr is omitted.

The dual symptom pattern is a classic P/Invoke marshalling defect: the managed wrapper builds three pinned buffers of uniform size and pre-fills them with array metadata instead of the actual variable-length read payload. The SAPI-S7 C interface expects a heterogeneous payload buffer whose total byte count is the sum of the per-variable lengths returned in the read confirm event. The mismatch manifests as either an unmarshalled pointer dereference (CLR NullReferenceException on the unmanaged caller) or as native error 80 once the C function probes the destination buffer size.

Environment and Prerequisites

Root Cause Analysis

The native signature of s7_get_multiple_read_cnf per the S7 Programming Interface manual is:

/* Excerpt — see SAPI_S7.H for authoritative prototype */
INT32 s7_get_multiple_read_cnf(
    void        *od_ptr,            /* application descriptor, NULL allowed */
    INT16       *msg_array_pointer, /* result code per requested variable */
    UINT16      *val_length_ptr,    /* actual length of each variable (bytes/bits per type) */
    void        *val_value_ptr      /* contiguous buffer holding all variable values */
);

Three issues in the original C# wrapper are responsible for the observed failure modes:

1. Uniform sizing of the value buffer. The wrapper allocates UInt16[32] (64 bytes) for the value buffer regardless of how many variables were requested and what their combined payload size is. The native call walks the variable list and offsets into the destination buffer by the running length; when the sum of requested lengths exceeds the allocated 64 bytes, the native code returns error 80.
2. Length array pre-initialised to zero. Pre-writing zeros into val_length_ptr via Marshal.WriteInt16 corrupts the input/output contract. val_length_ptr is an output array: the API fills it with the actual length of each returned variable. Pre-seeding it forces the wrapper to over-allocate and produces an internal null-deref path when the caller later attempts to read variable n but the offset calculation collapses against the pre-zeroed metadata.
3. Missing length-to-type translation. Each S7 datatype has a fixed byte size (BIT=1, BYTE=1, WORD=2, DWORD=4, INT=2, DINT=4, REAL=4). The wrapper treats every variable as 2 bytes. val_value_ptr must therefore be sized as sum(sizeof(type_i) for i in 1..N), not N * 2.

Buffer and Length Calculation

Before invoking s7_get_multiple_read_cnf, the caller must compute three quantities from the original s7_multiple_read_req request:

The pinned buffers must be allocated as:

// Pseudocode for allocation
int bytesResult  = N * sizeof(UInt16);
int bytesLength  = N * sizeof(UInt16);
int bytesValue   = B;             // sum of per-variable byte widths

IntPtr pResult = Marshal.AllocHGlobal(bytesResult);
IntPtr pLength = Marshal.AllocHGlobal(bytesLength);
IntPtr pValue  = Marshal.AllocHGlobal(bytesValue);

// pResult and pLength are OUTPUT only - do NOT pre-fill.
// pValue is OUTPUT only - the API writes the variable values into it.

Corrected P/Invoke Marshalling

Use [Out] attributes on output-only pointer parameters and never seed them before the call. The corrected declaration set:

using System;
using System.Runtime.InteropServices;

internal static class SapiS7
{
    private const string SAPI_DLL = "s732std.dll"; // or "s7std.dll" depending on installation

    [DllImport(SAPI_DLL, CallingConvention = CallingConvention.StdCall,
               CharSet = CharSet.Ansi, ExactSpelling = true)]
    public static extern Int32 s7_init(
        byte[] cp_name, byte[] vfd_name, ref UInt32 cp_descr);

    [DllImport(SAPI_DLL, CallingConvention = CallingConvention.StdCall,
               CharSet = CharSet.Ansi, ExactSpelling = true)]
    public static extern Int32 s7_multiple_read_req(
        UInt32 cp_descr, UInt16 cref,
        UInt32 var_count,
        [MarshalAs(UnmanagedType.LPArray)] UInt16[] var_addr_array,
        IntPtr od_ptr);

    [DllImport(SAPI_DLL, CallingConvention = CallingConvention.StdCall,
               CharSet = CharSet.Ansi, ExactSpelling = true)]
    public static extern Int32 s7_receive(
        UInt32 cp_descr,
        [Out] [MarshalAs(UnmanagedType.LPArray, SizeConst = 256)] byte[] msg_buffer,
        UInt32 msg_len,
        ref UInt32 msg_read,
        ref UInt16 cref);

    [DllImport(SAPI_DLL, CallingConvention = CallingConvention.StdCall,
               CharSet = CharSet.Ansi, ExactSpelling = true)]
    public static extern Int32 s7_get_multiple_read_cnf(
        IntPtr od_ptr,
        IntPtr msg_array_pointer,
        IntPtr val_length_ptr,
        IntPtr val_value_ptr);

    public const Int32 S7_OK = 0;
    public const UInt16 S7_MULTIPLE_READ_CNF = 0x0002; // verify against SAPI_S7.H
}

The [Out] attribute on output arrays (or simply leaving unmanaged memory uninitialised) prevents the CLR from pre-filling pinned arrays and removes the NullReferenceException path triggered by stale zero values.

Working Reference Implementation

public static int MyMultiReadCnf(uint cpDescr, int varCount, int totalPayloadBytes)
{
    IntPtr pResult = Marshal.AllocHGlobal(varCount * sizeof(ushort));
    IntPtr pLength = Marshal.AllocHGlobal(varCount * sizeof(ushort));
    IntPtr pValue  = Marshal.AllocHGlobal(totalPayloadBytes);

    try
    {
        // Do NOT pre-fill pResult, pLength, or pValue. They are OUTPUT only.
        Int32 ret = s7_get_multiple_read_cnf(
            new IntPtr(0), pResult, pLength, pValue);

        if (ret != S7_OK)
        {
            string detMsg  = s7_last_detailed_err_msg();
            ushort detNo   = s7_last_detailed_err_no();
            ushort iecNo   = s7_last_iec_err_no();
            string iecMsg  = s7_last_iec_err_msg();
            LogError("s7_get_multiple_read_cnf", detNo, detMsg, iecNo, iecMsg);
            return -1;
        }

        // Iterate results
        for (int i = 0; i < varCount; i++)
        {
            ushort resultCode = (ushort)Marshal.ReadInt16(pResult, i * 2);
            ushort length     = (ushort)Marshal.ReadInt16(pLength, i * 2);
            int offset        = CumulativeOffset(i); // see table above
            byte[] slice      = new byte[length];
            Marshal.Copy(pValue, slice, offset, length);
            ProcessVariable(i, resultCode, length, slice);
        }
        return 0;
    }
    finally
    {
        Marshal.FreeHGlobal(pResult);
        Marshal.FreeHGlobal(pLength);
        Marshal.FreeHGlobal(pValue);
    }
}

The CumulativeOffset(i) helper must return the byte offset of variable i within the contiguous value buffer. It is not simply i * 2; it is the running sum of per-type widths determined at request-build time.

Error 80 Reference Table

Alternative: C++ Wrapper DLL

If P/Invoke proves brittle or performance-critical, build a thin C++ DLL that exposes a stable C-style ABI to .NET and forwards calls to s7std.dll. This pattern is documented as a workaround in the SAPI-S7 support thread and is endorsed by Siemens application engineers when managed-language interop is required.

// MySapiBridge.h
#pragma once
#define SAPI_DLL_IMPORT extern "C" __declspec(dllexport)

SAPI_DLL_IMPORT int BridgeMultiRead(
    unsigned long cp_descr,
    unsigned short cref,
    unsigned short var_count,
    unsigned short* var_addrs,
    unsigned char* result_code_out,
    unsigned short* length_out,
    unsigned char* value_out,
    unsigned int value_buf_size);

The C++ wrapper computes buffer offsets from var_addrs (which carry datatype and DB/M/I/Q/E/A/PE/PA origin) and translates them into per-type byte widths. The C# side then calls a single P/Invoke entry point with pre-sized byte[] arrays managed entirely on the .NET side.

Alternative: OPC DA / OPC UA from C#

Siemens explicitly recommends OPC for managed .NET integrations. Supported paths:

• OPC DA via SIMATIC NET OPC server and a .NET OPCDA wrapper such as Advosol OPCDA.NET.
• OPC UA via the .NET Standard OPC UA SDK from the OPC Foundation or commercial stacks (Siemens OPC UA Scout for configuration).
• S7Comm Plus via third-party libraries (Snap7 plus is an open-source C# wrapper around libsnap7).

The OPC path eliminates P/Invoke fragility but introduces event-driven semantics, client/server overhead, and indeterminate scheduling. For deterministic cyclic reads at sub-10 ms intervals, the SAPI-S7 path remains attractive if the wrapper interop is implemented correctly.

Verification Procedure

1. Configure STEP 7 with the matching CP type and PROFIBUS address (default 2 for MPI/DP master).
2. Build a test request of 3 variables spanning different datatypes: MW10 (WORD, 2 bytes), DB1.DBD20 (DWORD, 4 bytes), DB1.DBX30.0 (BIT packed, contributes 2 bytes per 16 bits requested).
3. Invoke the corrected wrapper and confirm ret == S7_OK with all three resultCode entries = 0.
4. Validate per-variable length: length[0] == 2, length[1] == 4, length[2] == 2 (bit container width).
5. Cross-check the slice bytes against PLC values via TIA Portal / STEP 7 watch table.
6. Stress test with 32 variables (matches the original 32-element array sizing) to confirm zero allocations beyond the request envelope.

Troubleshooting Matrix

FAQ