Troubleshooting Siemens 840D OEMProgPack VB6.0 Make EXE Hang

The Siemens SINUMERIK 840D HMI Programming Package (commonly shipped as OEMProgPack 7.6) ships with VB6.0 OEM sample projects in .\HMI-Programming-Package\HMI-Environment\OEMSamples. When engineers attempt to compile a modified OEM sample into a standalone *.exe using the VB6.0 IDE, the build process can freeze at 10%-20% of the resource-compile phase with no error dialog, no event-log entry, and no progress for many minutes. This article documents the root cause, the diagnostic path, and three field-validated remediation paths that preserve the original VB6.0 OEM API surface.

1. Problem Statement

Field symptoms consistently reported on the OEMProgPack 7.6 toolchain:

• VB6.0 IDE launches the Make XX.exe sequence without an error popup.
• Resource compilation indicator (status-bar progress) reaches 10%-20% and freezes.
• Wait time of 10 minutes or more produces no *.exe file, no *.log, and no event in the Windows Application log.
• Building a stock "Hello World" VB6.0 project on the same workstation completes normally, proving the VB6.0 runtime itself is not corrupt.
• The unmodified OEM sample (no user code added) reproduces the hang with identical symptoms.

Because the hang appears even on a fresh, untouched sample copied from the OEMSamples directory, the problem is environmental (IDE, host OS, or OEM sample dependencies) and not caused by user-modified BASIC source.

2. Affected Versions and Components

3. Root Cause Analysis

The OEM sample *.vbp registers dependencies that the stock VB6.0 compiler cannot resolve on the workstation. The most common dependency conflicts and their signatures:

3.1 Dependency on VC++-compiled OEM DLLs

The Siemens OEM model splits the HMI program into two halves:

1. A VB6.0 front-end that owns the Forms, *.frm, *.frx resources, and operator-screen logic.
2. A VC++ DLL (*.dll built under MSVS 2003 or MSVS 2005) that owns the HMI-PRO / WinCC flexible runtime interface and the OPC, MPI, or Profibus link to the NCK/PLC.

The DLL exposes the OEM interface (e.g. OEM.HmiInit, OEM.HmiRead, OEM.HmiWrite) which the VB6.0 *.exe imports at startup. If the DLL is missing, the VB6.0 linker cannot finish the import-table stage of the Make EXE operation. The IDE does not raise File not found because it walks the reference list silently during the resource compile; it simply blocks on the unresolved Declare statement.

3.2 Compiled-Helper-File (CHM) registration failure

Siemens ships compiled HTML Help workshop artifacts (*.chm, *.hhc, *.hhk) that the OEM sample references through the VB6.0 HelpFile property. On hosts where the HTML Help viewer is not registered, the resource compiler enters a retry loop while trying to bind HHCTRL.OCX. This matches the 10%-20% freeze signature exactly.

3.3 VB6.0 IDE is in an unsupported state

Microsoft has documented that VB6.0 IDE compatibility is best-effort on all post-Windows 7 operating systems. See the Support Statement for Visual Basic 6.0 on Windows for the official position. The hang behavior is consistent with the "It Just Works" runtime goal for already-compiled VB6 applications not always being met by the IDE's resource compile stage, particularly when COM/ActiveX controls registered by Siemens OEM runtime are present but point at missing OCX files.

4. Prerequisites for Diagnosis

• Administrative account on the development host (required to register OCX/DLL).
• OEMProgPack 7.6 installation media or a verified local install of HMI-Programming-Package.
• VB6.0 SP6 IDE with the latest cumulative update.
• Access to regsvr32.exe and the Windows event viewer.
• Optionally: Dependency Walker (depends.exe) for symbol-level inspection.

5. Diagnostic Procedure

1. Confirm the symptom baseline. Copy the OEM sample to a write-protected working folder, open XX.vbp in VB6.0, and select File → Make XX.exe. Time the freeze. If the freeze is reproducible on the unmodified sample, the problem is not user code.
2. Inspect the project references. Open Project → References... in VB6.0. Note every MISSING: entry. Siemens OEM samples reference HMI Pro OEM Interface 1.0 Type Library, Siemens HMI Embedded Helper 1.0, and the VC-built OEM DLL's TLB. A MISSING reference is the single most common cause of an unrecoverable build freeze.
3. List the OCX dependencies. Open Project → Components... and identify all *.ocx controls loaded by the OEM sample (e.g. MSCOMCTL.OCX, MSFLXGRD.OCX, Siemens-internal *.ocx). Verify each exists in Windows\System32 (or SysWOW64 on x64 hosts) and is registered with regsvr32 /u then regsvr32.
4. Trace the DLL import chain. Run depends.exe against the VB6.0-produced stub *.exe (if an older build exists) or against MSVBVM60.DLL + the OEM DLL. Look for entries flagged with Error: Can't find dependent libraries.
5. Enable VB6.0 verbose logging. Set the environment variable VB6_LOG=1 and re-launch the IDE. A vb6.log file is emitted in %TEMP% capturing the file I/O during Make EXE. The log pauses at the exact file that triggers the freeze.
6. Check for the HTML Help binding. If the OEM sample sets App.HelpFile = "...\OEM.chm", ensure the CHM file exists and that HHCTRL.OCX is registered. Re-register with:
   regsvr32 hhctrl.ocx /u
regsvr32 hhctrl.ocx
7. Check the OEM runtime service. Several OEM samples assume the Siemens HMI Embedded Helper service is running. The Make EXE stage waits on an inter-process mutex that is only released by the helper. Start the service (or the OEM runtime simulator) before running Make EXE.

6. Solution Path A: Repair the VB6.0 OEM Sample in Place

Use this path when the OEM DLL stack is correct and only IDE-level references are missing. It is the lowest-risk fix and preserves the original toolchain.

1. Re-install OEMProgPack 7.6 over the existing install with "Repair" selected.
2. Register the runtime COM objects from a CMD prompt with administrative rights:

   cd /d "C:\Program Files\Siemens\HMI-Programming-Package\HMI-Environment\Bin"
   for %f in (*.dll) do regsvr32 /s "%f"
   for %f in (*.ocx) do regsvr32 /s "%f"

3. Re-link the missing references inside VB6.0 (Project → References → Browse...) to the freshly registered TLBs in the Bin folder.
4. Disable the CHM help file reference in the Project → Properties → General tab as a temporary test; if the Make EXE completes, the CHM binding is the culprit.
5. Rebuild the *.exe. The Make EXE should pass 10%-20% within seconds.

7. Solution Path B: Rebuild the OEM DLL under MSVS 2003 / 2005

Recommended when the OEM runtime requires a modern C runtime. VB6.0 can only consume 32-bit DLLs; MSVS 2003 produces clean 32-bit binaries compatible with the VB6.0 caller, and MSVS 2005 introduces the manifest-bound side-by-side CRT that must be shipped with the OEM *.exe.

1. Open the OEM DLL project (typically *.dsw for MSVS 6.0/2003 or *.sln for 2005) shipped in the OEMProgPack.
2. Build the DLL in Release configuration with the Win32 platform toolset. Confirm the output *.dll and the accompanying *.lib import library.
3. Copy the freshly built *.dll into the OEMSamples folder next to XX.vbp so VB6.0 resolves the import at link time.
4. In VB6.0, File → Make XX.exe. The compile should now complete; VB6.0 will produce a *.exe that dynamically loads the OEM DLL at startup.
5. Deploy the runtime triplet — the VB6.0 *.exe, the OEM *.dll, and the MSVC CRT (for MSVS 2005: msvcr80.dll + the matching Microsoft.VC80.CRT.manifest) — into the SINUMERIK HMI environment or the operator-panel runtime directory.

8. Solution Path C: Migrate the Front-End Off VB6.0

For long-term maintainability, the OEM front-end can be moved to a .NET language while keeping the OEM DLL as the integration boundary. This sidesteps the IDE-level VB6.0 problem entirely.

1. Create a C# or VB.NET Windows Forms project targeted to .NET Framework 4.x with x86 platform. The 32-bit target is required to consume the OEM DLL.
2. P/Invoke the OEM DLL functions that were previously called with VB6.0 Declare statements:

   [DllImport("oem_dll.dll", CallingConvention = CallingConvention.Cdecl)]
   public static extern int HmiInit(IntPtr hWnd);
   
   [DllImport("oem_dll.dll", CallingConvention = CallingConvention.Cdecl)]
   public static extern int HmiRead(int channel, byte[] buffer, int len);
   
   [DllImport("oem_dll.dll", CallingConvention = CallingConvention.Cdecl)]
   public static extern int HmiWrite(int channel, byte[] buffer, int len);

3. Replace the VB6.0 *.frm files with equivalent Windows Forms designer output. The 840D HMI tag model is rebuilt using HmiRead / HmiWrite calls wrapped in a System.Windows.Forms.Timer at the operator-panel refresh interval (typically 100 ms to 500 ms).
4. Build and test the new front-end in a non-SINUMERIK host first, against a stub OEM DLL that simulates the HMI PRO interface.

The OEM DLL stays compiled under MSVS 2003/2005; only the front-end is replaced. This separation matches Siemens' own reference architecture and protects the long-lived, certification-sensitive DLL from front-end churn.

9. Verification

After applying any of the three solutions, verify the build with the following checks:

10. Long-Term Recommendations

• Pin a development image. Build a VM or a dedicated workstation with a known-good configuration: Windows 7 SP1 x86, VB6.0 SP6, OEMProgPack 7.6, MSVS 2005 SP1, and the registered Siemens OCX set. Snapshot the image; restore on any build host that drifts.
• Avoid VB6.0 on Windows 10/11 hosts. The IDE's resource compile and the COM reference resolver are not part of Microsoft's VB6.0 It Just Works support policy, which targets running pre-compiled applications, not the development IDE. Use Windows 7 or Windows XP x86 hosts for VB6.0 development.
• Treat the OEM DLL as the stable boundary. The DLL is the contract with the HMI PRO runtime. Refactor front-ends freely (VB6.0, C#, WPF, even web-based HMI) without re-certifying the DLL.
• Keep the OEM runtime service running. Many Make EXE freezes are caused by a missing inter-process mutex. Confirm the service is up before starting the IDE.
• Document the binary triplet. The deployed payload is three files minimum: the front-end *.exe, the OEM *.dll, and the CRT (or its manifest) for MSVS 2005+ toolchains. A missing third file is the most common runtime failure after a successful build.

11. Troubleshooting Matrix

12. Frequently Asked Questions