Diagnosing VM Runtime Errors

Work through these steps in order. Each one rules out a common cause before you spend time narrowing down the failing code.

1. Testing and CI

First rule out runtime defenses (VM Self Defending, VM Debug Protection, VM Domain Lock): reproduce the failure with a testing build that uses the overrides from Testing and CI. If the testing build works, the defenses are reacting to your tools or environment rather than breaking your code.

2. Runtime compatibility

Check that the target, the build pipeline, and any environment declarations match where the code actually runs.

VM protection applies to eligible functions. In root mode, vmWrapTopLevelInitializers can also wrap eligible initializers for virtualization; current VM presets enable it. Review coverage warnings such as VMNoFunctionsToVirtualize, and use comment mode to select sensitive functions explicitly.

Reduce the failing case to the smallest function and call site that still reproduces it. Use comment mode to narrow which functions are virtualized.

If you use vmBytecodeArrayEncoding with vmBytecodeArrayEncodingKeyGetter, the getter must return exactly the key used at build time, and that key must already be set when the obfuscated code runs; otherwise the bytecode cannot be decoded.

Runtime Compatibility · Bytecode Array Encoding Key

3. Send a bug report

Email support@obfuscator.io. The more of the following you include, the faster we can fix it:

• Full error stack trace, exactly as it appears in the console - not a paraphrase.
• Obfuscator options as JSON. Copy the entire options object you used (or the preset name plus any overrides). Subtle interactions between options are common, so we need the exact set.
• Build warnings, if any: the type, message and functionName of each.
• Obfuscator version - shown in the dashboard's version selector below the editor. For API and npm package builds, it is the version field of the API's result or chunk_end message.
• Environment - browser + version, Node.js version, OS, anything unusual about the runtime (extensions, polyfills, custom builtins).
• Minimal reproduction - ideally the single function from section 2, plus whatever call site is needed to trigger the error.
• The original (pre-obfuscation) source, where possible. The obfuscated output is opaque on our side too; without the input we're reverse-engineering our own bytecode.

If the source is proprietary, say so in the email - we can sign an NDA before you share. We can't reliably diagnose VM bugs without seeing the input pattern that produced the broken bytecode, so it's worth the round-trip.