Skip to content

Troubleshooting

If something is not working as expected, start here. This page groups the most common VBA Padlock issues by area, with practical fixes you can apply immediately.

  1. Run a Syntax Check and fix every error in the Messages panel; the summary tells you what moves to the DLL and what stays in VBA.
  2. Review the verdicts in the Protection Review if fewer procedures move than expected.
  3. Test Run (Ctrl+F5) to produce and open the protected copy in Office.
  4. Check bin/ deployment (all expected DLLs present, not blocked).
  5. If licensing is involved, verify activation settings and key/project match.

Compilation success in VBA Padlock

A procedure stays in VBA (“kept in VBA”)

Section titled “A procedure stays in VBA (“kept in VBA”)”

Cause: Not an error: the compile gate decided the procedure must stay in the host document, and the review row tells you why.

Solution: Match the reason to its remedy:

Reason shownRemedy
event handler - must stay in host moduleExpected. Move the logic into a standard-module Sub and call it from the handler.
UserForm modules cannot run in a DLLExpected. Keep form code thin; delegate to standard modules.
shared module-level state '<name>'Restructure the module-level variable, or accept that the group stays together.
depends on <proc>Fix the root procedure first; the closure follows automatically.
References host object <X> ... - kept in VBA.Add Option Explicit to the module or qualify the name with Application..
already protected - kept in VBAYou opened a produced file. Open the original source instead.

Then click Re-analyze and check the verdicts again.

Cause: The module contains syntax errors, unsupported constructs, or references to undefined variables.

Solution:

  • Check the Messages panel for specific error messages and line numbers (double-click to jump to the code).
  • Review VBA Compatibility for the supported construct list and remaining limitations.
  • If the compiler reports an unresolved Office constant (xlUp, wdFormatPDF, …), tick the matching library in References.
  • Ensure all functions used are either user-defined or from the built-in script libraries.

Compilation succeeds but functions return errors at runtime

Section titled “Compilation succeeds but functions return errors at runtime”

Cause: The compiled function exists but encounters a runtime issue (wrong parameter count, type mismatch, etc.).

Solution:

  • Test your function with Run DLL Function before producing.
  • Verify you are passing the correct number and types of parameters to match the compiled function’s signature.
  • Check the return value: VBAPL_Execute returns a Variant that may contain an error code.

Cause: A validation failure before anything is written: the source file is open in Office, the destination is locked by another process, or the source file is missing.

Solution: Close the file in Office (and any viewer holding the output), then run Produce again. Your source is never touched by a failed Produce.

Cause: The message names the failing phase: Validate, Import, Build DLL, Inject, or Verify.

Solution:

  • Build DLL failures: open the Protection Review and fix the modules with a Fail verdict.
  • Inject/Verify failures: make sure Office is installed and functional, the file isn’t open elsewhere, and “Trust access to the VBA project object model” is enabled (see below). Then retry; injection works on a copy, so nothing is ever half-written into your source.

Produce or bridge injection fails to modify the Office file

Section titled “Produce or bridge injection fails to modify the Office file”

Cause: VBA Padlock requires programmatic access to the Office VBA project to inject the wrappers and bridge module. This access is disabled by default in Office for security reasons.

Solution: You must enable “Trust access to the VBA project object model” in your Office application settings:

  1. Open the Office application (Excel, Word, etc.).
  2. Go to File > Options.
  3. Select Trust Center in the left menu.
  4. Click the Trust Center Settings… button.
  5. Select Macro Settings in the left menu.
  6. Under Developer Macro Settings, check the Trust access to the VBA project object model box.
  7. Click OK and restart the Office application.

Trust access to the VBA project object model setting in Office Trust Center

VBA Bridge module generated in Studio

“DLL not found” or “File not found” error

Section titled ““DLL not found” or “File not found” error”

Cause: The Office file cannot find the DLL files.

Solution:

  • All three DLLs must be in a bin/ subdirectory relative to the Office file:
    MyWorkbook.xlsm
    bin\
    ├── MyWorkbookrun32.dll
    ├── MyWorkbookrun64.dll
    └── MyWorkbook.dll
  • Verify the bin/ directory exists and contains all three DLLs.
  • If the files were downloaded from the internet, right-click each DLL → Properties → check Unblock.

Distribution tab in VBA Padlock

“Verification failed” or Security Code mismatch

Section titled ““Verification failed” or Security Code mismatch”

Cause: The Security Code in the VBA Bridge does not match the one in the satellite DLL, typically because the protected copy was produced before the code was changed.

Solution: Run Produce Protected Office File again. The pipeline regenerates the bridge with the current Security Code and rebuilds the DLLs in one pass. (Manual alternative: Create VBA BridgeInject Into Office, then recompile.)

Cause: A DLL file was modified after compilation, or a file is corrupted.

Solution:

  • Recompile the project from VBA Padlock.
  • Do not modify or patch the DLL files after compilation; they are integrity-verified.
  • If the issue persists, try deleting the bin/ directory and rebuilding.

Key Generator in Licensing workspace

Cause: License storage permissions or conflicting installations.

Solution:

  • Ensure the user has write access to HKEY_CURRENT_USER (registry storage) or to the application folder (.LIC file storage).
  • Check the storage mode in Activation Settings.
  • If using portable mode, verify the .LIC file can be created next to the Office file.

Cause: The key format does not match, the key was generated for a different project, or the Hardware ID does not match.

Solution:

  • Verify the key was generated with the same project (matching Security Code and ECC keys).
  • Check for typos; common confusions: 0 vs O, 1 vs l, I vs l.
  • If using hardware-locked keys, verify the user’s System ID matches the one used to generate the key.
  • Use the Key Generator to regenerate the key if needed.

Cause: A hardware component used for the Hardware ID was replaced or updated (new hard drive, network adapter, etc.).

Solution:

  • Check which components are selected in Hardware ID Options.
  • Remove volatile components (e.g., MAC address) if users frequently change hardware.
  • Generate a new key for the user’s updated Hardware ID. See Key Generation guide.

Cause: Network issues, incorrect server URL, or server configuration problems.

Solution:

  • Verify the activation URL in Online Activation Settings.
  • Test the server connection from VBA Padlock using the Test Connection button.
  • Ensure the server uses HTTPS and the PHP activation kit is correctly deployed. See Activation Server guide.
  • Check the server error logs for details.

Online activation settings

Functions work in Run DLL Function but fail in Office

Section titled “Functions work in Run DLL Function but fail in Office”

Cause: The protected copy may be outdated (produced before your latest changes), or macros may be disabled. Note also that Run DLL Function executes outside Office; code touching the host object model behaves differently there.

Solution:

  • Run Produce Protected Office File again and test the fresh copy (Test Run, Ctrl+F5, does both).
  • Verify macros are enabled in Office Trust Center settings.

Cause: Some antivirus software flags DLLs with certain protection patterns as suspicious.

Solution:

  • This is a false positive. VBA Padlock runtime DLLs are digitally signed by G.D.G. Software.
  • Submit the DLL to your antivirus vendor for whitelisting.
  • Add the bin/ directory to your antivirus exclusion list.

VBA Padlock generates both 32-bit and 64-bit runtime DLLs. The VBA Bridge automatically detects the Office architecture and loads the correct DLL. No configuration is needed.

Compiled DLLs are compatible with Office 2016 and later, including Microsoft 365 desktop apps. The VBA Bridge uses Declare PtrSafe syntax for 64-bit compatibility.

Multiple Office files sharing the same DLL

Section titled “Multiple Office files sharing the same DLL”

Each Office file needs its own satellite DLL (compiled with its own Security Code). The runtime DLLs ({DLLName}run32.dll and {DLLName}run64.dll) are also project-specific, named after the project’s DLL name.

Issue: Office ARM is installed, and VBA Padlock DLLs fail to load.

Cause: Native ARM versions of Office cannot load standard x86 or x64 DLLs.

Solution:

  • On Windows ARM (like Surface Pro 11, Surface Laptop 7, or Snapdragon X Elite devices), uninstall the ARM-native version of Office and install Office 64-bit instead.
  • Office 64-bit on Windows ARM uses Microsoft’s Prism emulation. This allows the standard x64 versions of VBA Padlock DLLs to load and execute seamlessly without any modifications.

If your issue is not covered here: