Symptom: Script Runs but Does Nothing

AcCoreConsole starts, the console flashes text, the process exits, and your drawings are untouched. Three causes, in order of likelihood:

  • Missing trailing newline. Each line break in a .scr is an Enter keypress. If the file doesn't end with a newline, the final command sits at the prompt unexecuted, and everything before it may be rolled back by the missing QSAVE that was on that last line. Open the script, put the cursor at the end, press Enter once, save.
  • Wrong text encoding. Scripts must be plain text. Files saved as UTF-16 ("Unicode" in old Notepad) or with unusual encodings feed garbage to the command interpreter. Save as ANSI or UTF-8.
  • Smart quotes and copied punctuation. Scripts assembled in Word or copied from web pages pick up curly quotes and non-breaking spaces that break paths and commands. Rebuild the line in a code editor.

Symptom: It Hangs Forever

The process sits at 0% CPU and never exits. AcCoreConsole is waiting for input at a prompt your script didn't answer. There is no dialog to see and no user to answer it, so it waits forever. Common triggers:

  • Prompt drift: a command asked one more question than your script answers, often because a default changed or a file already exists ("A drawing with this name already exists. Overwrite? [Yes/No]").
  • A dialog-opening command: anything not hyphen-prefixed (PLOT instead of -PLOT, PURGE instead of -PURGE) tries to open UI that doesn't exist headless.
  • A selection prompt with nothing to select or an insertion-point prompt from a block insert you didn't expect.

The debugging method that always works: open the same drawing in full AutoCAD, run your script with the SCRIPT command, and watch the command line. Wherever full AutoCAD stops and waits, that's the missing line in your script. Fix, retest, repeat. Our script recipes list the exact prompt sequences for the common batch operations.

Defense in production: wrap every invocation in a timeout so one hung drawing can't stall a thousand-drawing batch overnight:

$p = Start-Process $acc -ArgumentList "/i `"$dwg`" /s `"$scr`" /isolate" -PassThru
if (-not $p.WaitForExit(120000)) { $p.Kill(); Write-Warning "TIMEOUT: $dwg" }

Symptom: NETLOAD Won't Load Your DLL

Your plugin works in full AutoCAD but AcCoreConsole reports the assembly cannot be loaded. Work down this list:

  • .NET version mismatch (the 2025 gotcha). AutoCAD 2025 and later run on .NET 8. A DLL built for .NET Framework 4.8 (AutoCAD 2024 and earlier) will not load, and vice versa. Rebuild against the target release's ObjectARX/managed assemblies. If you support both generations, you need two builds.
  • Security settings. Since the 2016-era security hardening, SECURELOAD controls whether AutoCAD loads code only from trusted locations. Add your plugin folder to TRUSTEDPATHS, or set SECURELOAD appropriately for your environment as a scripted step before NETLOAD.
  • Windows blocked the file. DLLs downloaded or copied from another machine carry a zone marker. Right-click, Properties, Unblock, or run Unblock-File in PowerShell across the plugin folder.
  • Network path. Loading from a UNC path trips additional .NET security policy. The pragmatic fix: copy the DLL to a local folder in your wrapper before NETLOAD, and add that local folder to TRUSTEDPATHS.
  • Referencing the wrong API set. Plugins for AcCoreConsole must code against AcCoreMgd.dll (and AcDbMgd). A plugin that references AcMgd.dll UI types will load in full AutoCAD but fail headless. Details in the main guide's plugin section.

Symptom: "No Function Definition: VLA-GET-..."

Your LISP routine dies with error: no function definition naming a vla-, vlax-, or vlr- function. This isn't a bug in your script. AcCoreConsole implements core AutoLISP only; the Visual LISP COM/ActiveX layer does not exist in the headless engine, and no setting turns it on.

Your options, in increasing order of effort and robustness:

  • Refactor to core AutoLISP: entity access via entget/entmod/ssget covers most geometry and attribute work that vla- calls are used for.
  • Port to .NET: if the routine leans heavily on the object model, a C# plugin against AcCoreMgd is usually less work than a deep LISP refactor, and you gain error handling and testability.
  • Run those routines in full AutoCAD: legitimate when the LISP is rarely used or too large to port; batch it with the GUI version at 5x the runtime, as compared in our batch processing options guide.

Symptom: Wrong Fonts or Plot Styles in Output

PDFs come out with substituted fonts, missing line weights, or the wrong plot style table. The cause: AcCoreConsole resolves support files (SHX fonts, CTB/STB plot styles, plotter configurations) through its own environment, which may not match the support paths, printer configurations, and enterprise CUIx customizations your full AutoCAD profile carries.

  • Keep fonts, plot style tables, and pc3 files in the standard install-level support folders rather than user-profile or network-only locations, or copy them there on the batch machine.
  • Reference plot configuration through named page setups saved in the drawings or template, so the .scr never has to specify device details.
  • Check the console output for "substituting font" lines; they name exactly which SHX file the batch machine is missing.

Symptom: Unknown Command Errors

The console echoes your command back with Unknown command. Three distinct causes:

  • Vertical or add-on commands: AutoCAD Mechanical, Electrical, Plant 3D, and Express Tools commands are not present in the core engine. There is no fix inside AcCoreConsole; those operations need full AutoCAD or a reimplementation via the API.
  • The command loads from a CUIx or startup LISP that only your full AutoCAD profile loads. Load the defining file explicitly in your script before calling the command.
  • A typo only a script would make: a stray blank line earlier in the script consumed a prompt, so your command text arrived where a value was expected. Recount the Enters.

Symptom: Crashes on Specific Drawings

The batch runs fine until drawing 847, where the process dies. Chronic offenders are corrupt drawings, degree-of-freedom-heavy proxy objects from vertical products, and enormous unpurged object databases.

  • Pre-flight with AUDIT: run a first pass of AUDIT Y QSAVE only; quarantine drawings whose output shows unfixed errors, and RECOVER those manually.
  • Isolate per process: one AcCoreConsole invocation per drawing means a crash costs you that drawing, not the batch. Never feed a whole folder to one long-lived process.
  • Log and skip: your wrapper should record the failure and continue; the alternative is discovering at 8 AM that the overnight batch stopped at 3%.

Detecting Failure Reliably

AcCoreConsole's process exit code is not a dependable success signal: a script can fail mid-way and the process still exits normally. The reliable pattern is capturing each drawing's console output to a log file and scanning it:

& $acc /i "$dwg" /s "$scr" /isolate *>&1 | Out-File "$logDir\$name.log"
$failed = Select-String -Path "$logDir\$name.log" `
  -Pattern "Unknown command|error|Invalid|substituting|not found" -Quiet

Then verify the artifact itself: did the PDF appear, is it non-zero size, did the DWG's modified timestamp change? Artifact checks catch the failures that never printed an error at all. The PowerShell wrapper in our recipes article has both checks built in.

Task Scheduler and Server Quirks

Batches that work at your desk and fail at 2 AM under Task Scheduler almost always trip one of these:

  • Licensing under a different account: AcCoreConsole requires a licensed AutoCAD installation, and sign-in-based licensing is tied to the user session. Run the task as the account that holds the activated license, and test with "Run whether user is logged on or not" before trusting the schedule.
  • Mapped drives don't exist in non-interactive sessions. Use UNC paths everywhere: input, script, plugin, and output.
  • Different environment: the service session has different temp folders and permissions. Give the account explicit write access to output and log folders.

When to Stop Debugging

Scripts plus a wrapper will carry you a long way, and every fix above is within reach of a capable CAD manager. The point of diminishing returns arrives when you're generating scripts from templates, layering retry logic into the wrapper, and maintaining special cases per drawing type. That's a sign the workflow has outgrown scripting and wants a proper .NET application: structured error handling, real logging, and behavior that varies by drawing content instead of by folder.

That's the work we do. If your team is spending more time babysitting the batch than the batch saves, describe your workflow to us and we'll scope what a production-grade version looks like. And if you're weighing whether headless on-premises processing is even the right architecture versus cloud automation, start with the batch processing comparison.