Diagnosing VM Runtime Errors
Run the original code first, then run the obfuscated testing build through the same checks. Record the input, effective options, obfuscator version, and build warnings so failures can be reproduced.
1. Testing and CI
These defenses also act against your own agents, automation, and debuggers. They may stop execution, throw unrelated errors, or produce incorrect results. Use a separate Testing build for functional tests.
Derive the testing configuration from your shared settings and apply these overrides after selecting a preset. They disable the VM and basic versions of self-defending, debug protection, and domain lock. Pass explicit values; omitting an option can let a preset enable it.
2. Runtime compatibility
Choose the target for the actual runtime. Browser and Node builds can contain different defenses; a browser target is not a substitute for Node. Environment declarations, domain restrictions, and runtime tools must also match the configuration.
Compile TypeScript or JSX and bundle your application before the final obfuscation step. Preserve VM selection comments until obfuscation. Do not minify, format, or otherwise rewrite self-defending output afterward. Source maps are unavailable for VM and HTML obfuscation.
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.
Runtime compatibility · Bytecode Array Encoding Key
3. support@obfuscator.io
- 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.
- Obfuscator version - shown in the bottom-right corner of the editor.
- Environment - browser + version, Node.js version, OS, anything unusual about the runtime (extensions, polyfills, custom builtins).
- Minimal reproduction - ideally the single function from Step 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.