When InDesign stops responding during a long run

A problem every long-running InDesign script meets sooner or later: the script doesn’t report an error, it just stops. InDesign shows “Not responding”, nothing happens for hours, and the only way out is to kill it in the Task Manager and start again. This season, it happened with the Christmas card project: my client would start a batch at 3 a.m., and at 7 a.m. only one class was done. Here’s how I think about this kind of problem.

Is it really stuck?

First, “Not responding” doesn’t always mean stuck. While a script is running, InDesign doesn’t answer Windows’ messages, so Windows may show “Not responding” even though the script is working fine. Before killing InDesign, check that nothing new is appearing in the output folder. If PDFs are still being written, wait.

Is it the RAM?

The natural guess is that InDesign runs out of memory, and the natural answer is to buy a more powerful computer. My client did exactly that, and it didn’t help. The pattern he described is the clue: it either stops within the first few minutes or gets through the whole batch. Running out of memory (or memory slowly building up) looks the opposite: the run fails late, after many documents, and the bigger the batch, the more likely it is. A freeze with no error, early in the run, usually means InDesign is waiting for something outside itself.

What InDesign may be waiting for

A network drive

InDesign reads and writes files on its main thread. If the templates, the pictures or the output folder are on a network drive and that drive is slow, disconnected or on a computer that has gone to sleep, the first file access just waits. No error, no timeout you can catch — InDesign freezes. This is especially likely at night, when other computers sleep, and on the first access after a long idle period.

A hidden Excel

The script reads each school’s spreadsheet through Excel: it generates a VBScript that opens the workbook with Excel COM and runs it with app.doScript. InDesign waits until that VBScript finishes. The VBScript sets DisplayAlerts = False and keeps Excel invisible, but that doesn’t stop every possible message:

“Excel didn’t close properly last time — start in safe mode?” This one is likely after InDesign was killed in the Task Manager, because the hidden Excel is left running;
activation or sign-in prompts;
macros: when a program opens a workbook through COM, Excel enables its macros by default. If an .xlsm workbook has a macro that shows a message box, the box is invisible and nobody can close it.

Both cheap fixes go into the VBScript and the runner: turn off macros before opening the workbook, and kill any leftover Excel before a run.

objExcel.DisplayAlerts = False
objExcel.AutomationSecurity = 3   ' msoAutomationSecurityForceDisable: no macros
Set objBook = objExcel.Workbooks.Open(filePath, 0, True)   ' don't update links, read-only

How to find out

Next time it hangs, before killing InDesign:

In the Task Manager, on the Details tab, look at InDesign.exe. CPU near zero means it’s waiting for something; high CPU means it’s busy. Memory growing all the time would point to a memory problem after all.
Look for EXCEL.EXE in the list. If it’s there while InDesign is frozen, Excel is the suspect.
Look at the end of the log. Every function in the project logs when it starts and ends, so with full logging (not “errors only”) the last lines show exactly where it froze.
Does it freeze during the day too, or only at night? Only at night points strongly at the network.
Copy one school and the templates to the local disk and run it from there. If that never freezes, it’s the network.

For the network, the most robust fix is to keep InDesign off it altogether: copy the night’s work to a local disk, process it there and copy the results back. And whatever the cause, a watchdog limits the damage: a hang costs minutes instead of the whole night.

Would InDesign Server help?

It’s tempting to think so: InDesign Server is made for batch work, and people often say it’s multithreaded, unlike the desktop version. But a single InDesign Server instance runs a script on one thread, just like InDesign on the desktop. The document model isn’t thread-safe, so opening, placing and exporting always happen one after another. Server gets its parallelism by running several instances at once, each on its own port with its own job. That makes a batch faster; it doesn’t stop one instance from freezing.

What Server would fix: it has no user interface, so there’s no “Not responding” and no modal dialog that can quietly block a run, and it’s meant to be restarted when needed.

What it wouldn’t fix, or would make harder:

Network drives. Server waits on a stalled file just as the desktop version does. Worse, it runs as a service, and a service doesn’t see the user’s mapped drives at all, so every path would have to become a network path (\\server\share\...).
Excel. Microsoft doesn’t support automating Office from a service, and it’s known to hang in exactly this way. The spreadsheet would have to be converted to CSV or JSON by a separate step first.
The script. Server has no ScriptUI, so the progress window, alerts and the settings dialog have to go.
Versions and cost. The Server version has to match the designers’ desktop InDesign, because templates saved in a newer version don’t open in an older one. And it’s an enterprise product licensed through resellers, which is hard to justify for one seasonal job in a small company.

So for a hang, InDesign Server isn’t the answer: find the cause and add a watchdog. Server makes sense later if the goal is speed — several schools processed in parallel — and even then it needs the same watchdog.