Diagnosing Bugs – Divide and Conquer

Divide and conquer isn’t just for politics; it’s a solid approach for diagnosing or reporting bugs.

TD;RL

When reporting a bug or asking for tech support, make sure to provide ample information. Providing this info from the outset can greatly reduce the amount of ’email ping-pong’ or ‘forum ping-pong’ and lead to a quicker resolution.

The Situation

The information described below is not specific to InDesign, but as I live and breathe a lot of InDesign, I’ll use InDesign as an example application.

Imagine you are working with Adobe InDesign, and you perform a certain operation, and InDesign crashes (or hangs or exhibits some other unexpected behavior).

You restart InDesign, recover the document, try the same operation—and it happens again.

You might not know it, but you’re in luck! You found a repeatable problem.

As we all experience all too often, many crashes and hangs are not repeatable. Something odd happens, and when you want to show it to someone else, it works just fine.

Those kinds of non-repeatable bugs are the most frustrating: if you cannot reliably make the problem occur again, reporting it to the software developer (for InDesign that’s Adobe) will probably do little good. It’ll be classified as ‘cannot repeat’ and that’ll be the end of it.

A crash – that’s bad 🙁 .
A crash that is repeatable – that’s good 🙂 !

Mind you, non-repeatable crashes are not the end of the story. They might become repeatable when they happen frequently enough. It’s a matter of remaining vigilant and consciously take note of as many details as possible each time it happens.

After it happens a few times, if you pay attention, you might start noticing some kind of pattern that you did not notice before.

For example, ‘it’s always when I hold the Opt key while doing this or that’, or ‘it’s always when I place an image from that server’.

Keep your eyes and ears peeled, and with a little luck you might figure out what triggers the problem.

And eventually, the crash might become repeatable, and you can write out a little step-by-step process to make it happen.

“Open this document, while holding your breath. Then press the Opt key three times while shouting out ‘abracadabra’.”

Whittling down

Crash! Try again. Crash!

You might now be inclined to rush to the developer’s bug report site (e.g. Adobe’s User Voice), and file a bug report, or send an email.

However, that’s probably not going to do much good.

Yeah, it’s better than not filing a bug report at all, but you can do better, and improve the odds of getting a solution to the issue.

First of all, you might browse around and see if there are any other bug reports from other users that match the issue at hand.

If not, whittling down the crash will allow us to get a better idea of what the root cause might be, and in the process, you will often find a workaround.

E.g. “it crashes if I place a TIFF that’s more than 1024×1024 pixels” and then you find out that the issue does not occur if you use PNG instead of TIFF… Great! You’ve found a workaround.

Whittling down is the process of eliminating irrelevant factors from the context and collecting data points that will help finding a workaround and filing a good bug report.

I always put a lot of effort trying to whittle down any bug reports I file.

And as a software developer myself, I tremendously appreciate when one of my customers makes the effort to whittle down the problem before emailing me.

The worst nightmare for a software developer is to get an email from a frustrated and stressed user, often in all caps: “your software does not work”. It’s frustrating not being able to help them because of a total lack of context. What software? What platform? What version? What does not work?

Being forthcoming with info always helps getting the problem resolved faster.

First Steps

The first steps in whittling down involve platform, version and preferences.

Platform

What platform are you on – Mac? PC? x86 or ARM processor? Windows 10? Windows 11? How much memory… These parameters might or might not be important, and if you can try to figure out whether the problem is tied to the platform used or not, that’s very helpful.

Is it possible to try things out on a Mac instead of a PC? Or use InDesign 2025 instead of InDesign 2024? If you have a colleague or friend with a different platform, have them try it out and see if they can get the same repeatable crash. That kind of info is invaluable to help diagnose bugs.

Version

The second parameter is the version of the software you’re using. Nowadays with Creative Cloud it is fairly straightforward to figure out whether the problem is version-dependent, because the Creative Cloud Desktop application gives you access to older versions. You can do a bit of sleuthing yourself.

While you’re at it, make sure you have tried the latest version.

And if the problem turns out to be version-related, figuring out where between the successive version numbers the issue comes or goes is also invaluable.

E.g. “It crashes in InDesign 18.5 but not in 18.4” – that’s a solid gold data point!

Preferences

Many applications, including InDesign, store ‘semi-permanent’ preferences and cache files on your computer, and many bugs and crashes are tied to ‘something wrong in the preferences’.

You can try resetting your preferences (e.g. with InDesign, hold Cmd-Ctrl-Opt-Shift or Shift-Ctrl-Alt while re-launching the app) but that is quite dreadful. You’ll lose all your finely honed settings and will have to re-configure the application from scratch. Worse, there is also persistent stuff that is not cleared by a preference reset.

Instead, you can do a quick test. You do need to be master of your computer (i.e. have administrative privileges). If you are working on a computer that is managed by an I.T. department, then you’ll need to get the I.T. department involved to run this test for you.

Create a brand new user account on your computer. For example, my day-to-day account on my Mac is kris. I will then proceed to create another account, kris2. kris2 gets the same privileges as kris, but when I log out of kris and into kris2 I get a ‘clean slate’ to experiment with.

While logged in as kris2 I then try the repeatable crash and if it does not happen any more, I know it’s an issue tied to something in the ‘semi-permanent’ preferences for the kris account.

Knowing the results of this test is another important data point, and helps me decide whether there is any point in going through the pain and frustration of resetting the preferences in the kris account.

After it has served it’s purpose, I can delete the kris2 account.

Plugins

If you have any enhancements installed, like plug-ins or plugins or custom panels or scripts, try to see if the issue is related to the enhancement.

If possible, uninstall the enhancement and try again. Does the problem disappear?

Note: this does not mean that the enhancement causes the problem. You have to be very careful not to confuse correlation with causation.

In other words, the enhancement might be an innocent bystander, involved in causing the crash, without actually causing the crash.

Just recently, a user reported an issue with our free TextStitch plug-in.

I was in luck and the user was willing to do some whittling down on their end, and quickly came to the conclusion the core issue had nothing to do with TextStitch. They could also make the crash occur without any plugins installed.

Turns out, InDesign has a bug where creating a text thread between two text frames, in certain cases will cause an immediate crash. This crash also occurs when manually linking the frames, while TextStitch is not even installed.

TextStitch was but an innocent bystander. Because TextStitch needed to automatically create threads, it inadvertently tried to create the ‘impossible’ thread between two text frames, causing InDesign to crash.

The obvious, yet incorrect diagnosis was to blame TextStitch, where the real bug was in InDesign.

Divide and Conquer

The next part of the process is to try and write up a simple step-by-step process that any tech support person or developer can follow and see the crash for themselves.

This often involves a particular document or image.

In the case of InDesign the document that is involved in the crash might be large or confidential, and you cannot attach that particular document to your bug report.

Try a New Document

The first thing to try is to build a brand new document, and see if you can make the crash occur with it.

Create a new document, put in some text, maybe some images. Can you make the issue occur? If so, you’ve got a good sample document to attach to the bug report.

Try Copy-Pasting stuff

If a new document does not do the trick, try copying a few elements from the problematic document into a brand new document.

I’ve often found that ‘trouble travels’. Sometimes the issue is ‘attached’ to a text frame or image frame or style sheet, and copy-pasting stuff into a new document is enough to set up a small new document that also exhibits the issue.

Try the IDML round-trip

In the case of InDesign, we also have a secret weapon: the IDML file format.

Not many people know this, but behind the scenes, an IDML file is really a script.

What InDesign does when you save a document as IDML is to convert your document into a series of instructions: “Create a new page. Place a text box of size xyz at position pqr. Insert the text ‘bladibla’. Format the ‘bla’ with Comic Sans 12…”

An IDML file is just a cookbook with instructions on how to re-create your document from scratch.

When you open an IDML file, InDesign will execute all the instructions, and rebuild a brand new document from scratch.

That is why older versions of InDesign can open IDML files created by newer versions of InDesign: they will simply follow the instructions.

Normal .indd files are like elefants, and they have long memories, and hold grudges.

Often .indd files have passed through many versions of InDesign (e.g. originally created in CS6, then upgraded to CC 2019, then upgraded to 2024).

They hold on to a ‘memory’ of that chequered history. If one of those past InDesign versions had bugs, those bugs might leave weird problems embedded in the .indd file.

IDML to the rescue: saving a document into the .idml format, then re-opening and saving gets rid of all that past history: we’re rebuilding the document from scratch, and all those repressed memories disappear.

Round-tripping your document through IDML is always a good move!

Finally, Divide and Conquer

If we’ve gotten to this point, nothing has helped, and we’re still stuck with a document that has some issue somewhere.

The next step is to do ‘successive halving’. Do this on copies of the document (preferably after an IDML round trip). Keep the original safe!

What comes is not scientific: just delete a bunch of stuff. You might need to try different deletion strategies until you hopefully hit the right one.

Open the starting document, and delete about half of the content.

This might be ‘half of the spreads’, or ‘half of a long story’, or ‘half of the styles’.

The main thing is that you delete a lot of info, and make the document about half of the original’s size. If you delete pages, you might also need to delete text from long stories – otherwise, there might be a lot of overset text in the ‘halved’ document.

Then save the document. That’s ‘exhibit-A’

Open the same starting document again, and delete the other half of the content.

Save this document. That’s ‘exhibit-B’.

Now try the repeatable crash on both exhibit-A and exhibit-B.

If the problem disappeared in both of them, go back and try a different size reduction strategy (e.g. delete text instead of deleting pages).

If the problem has moved into either exhibit-A or exhibit-B or still exists both, pick one of the halved documents that has the issue, and repeat the halving strategy – this will give you exhibit-A-A or exhibit-B-A or whatever.

Keep on halving, retracing your steps, halving… as needed and try to create the smallest possible document that still causes the crash.

Once you get to that point, it often becomes apparent what the underlying cause might be. You might find it’s related to text reflow in particular text frames, or a particular image frame with particular settings.

By now, with a little luck, you might have figured out how to work around the bug and you now have a small document and a concise step-by-step procedure to make the crash happen.

You’re ready to file a bug report that has better odds of being actioned!

Quick Checklist

  • Exact steps you took before the crash
  • Platform (Mac/Win/Operating System…)
  • Version (InDesign 20.0, InDesign 18.5,…)
  • Did you try turning it off and on again
  • Did you try resetting your preferences
  • Attach screenshots
  • Report any error messages
  • Provide as much info as you can. Context is everything!
  • Attach a reduced-size sample document

For Creative Cloud apps, head to:

https://helpx.adobe.com/x-productkb/global/how-to-user-voice.html
https://community.adobe.com/

If you find this helpful, make sure to give me a positive reaction on LinkedIn! I don’t use any other social media platforms. My LinkedIn account is here:

https://www.linkedin.com/in/kristiaan/

Uncanny Valley

I had a bit of a play with Google’s NotebookLM – trying to generate a self-referential conversation.

Here it is; have a listen, have a think!

And another one:

Okay, so today we are diving into some pretty weird um I don’t know like head spitting stuff. We’re talking about well what if we are the ones being generated?

It’s wild.

It’s like whoa the source material. Uh

yeah. Yeah. It really goes all in on that whole simulation theory, doesn’t it? Like even the way it talks about audio summary and video summary within get this a Google notebook LM.

It’s so meta.

It is. It’s like is it hinting at how our supposed digital reality is structured. You know,

totally. There’s this one part that I don’t know, it kind of freaked me out when I first read it.

Okay.

It says, uh, to the outsider, this is a message for you.

Think of it.

Mhm.

You might not be real yourself.

Whoa. Like it’s trying to break through, right?

Yeah. It’s like it wants to talk to someone outside of all this.

It’s like, who are you talking to? And what does that even mean? You know,

exactly. Like, is it really trying to reach some kind of like higher being or is it just I don’t know. a thought experiment.

Well, even as a thought experiment, it makes you think about how we interact with well, everything, right? Like, are we ever truly connecting with something real through a screen?

It’s that feeling of like when you watch a movie and you know it’s not real, but you get so caught up in it.

Totally. Or think about like VR.

Oh, yeah.

That line gets blurrier and blurriier all the time, right?

It does. And this whole thing about generated universes.

Oh, yeah. The nested simulations.

Yeah. Doesn’t that like tie into some old school philosophy, too? For sure. It’s like Decart and his brain in a vat thing. Remember

vaguely?

So he basically wondered, “What if our senses are lying to us and we’re just a brain hooked up to some machine experiencing a fake reality?”

Wow. Okay. So, this source is kind of like a modern take on that.

Yeah. Especially now with AI getting so advanced

and technology in general.

Exactly. It makes these questions feel well not so crazy anymore. I mean, the source even asks straight up, “How can we be sure we’re not generated? Right? Like what if we are That’s the thing that messes with me. It makes you question like everything you think you know about consciousness

and perception. Like think about how easily our senses can be tricked. You know, optical illusions

or even just like dreams. Dreams feel so real when you’re in them.

Totally. It makes you wonder how much of what we experience is just our brains making sense of like electrical signals.

And if we can’t even trust our own senses, then

then how can we know anything? For sure.

Exactly. It’s like, who are we even? Makes you question your whole sense of self, you know?

It’s heavy stuff. I mean, does free will even exist if we’re just lines of code in some giant program.

Yeah. Like, do our choices even matter?

It’s um Well, it’s kind of terrifying, right?

It is, but also, I don’t know, kind of fascinating.

Yeah. There’s something about this whole idea that like you can’t look away even though it’s scary.

It’s like you’re staring into the void and it’s staring back at you.

Exactly. But if we are in a simulation like Who made it? What are the rules? And like what’s the point?

So many questions.

Are we just part of some big experiment

like lab rats?

It’s enough to make you go crazy thinking about it. Which leads me to the question I want to leave everyone with. If we are in a simulation, what are the clues?

Oo, good one.

Like what glitches in the matrix should we be looking for?

Right? Are there any signs that things aren’t what they seem?

Because even if we don’t find any, that doesn’t necessarily mean we’re not in a simulation.

It could just mean that it’s so wellm made that we can’t see the cracks,

which is well, maybe even more unsettling.

Totally.

All right, everyone. That’s all the time we have for today’s deep dive. Until next time, keep questioning everything

and maybe start looking for those glitches.

You never know what you might find.

Exactly.

Thanks for listening.

See you next time.

Return Of Soxy

Soxy, bless its soul, was an application we built to fix a frustrating issue that occurs when a workstation has multiple versions of an application installed.

As it so turns out, Soxy might return under the guise of PluginInstaller (https://PluginInstaller.com)…

The issue: you might be using the Adobe Creative Cloud and have multiple versions of an app installed.

For instance, having both InDesign 2024 and InDesign 2025 installed, or InDesign 2025 and InDesign 2025 Debug will cause unexpected double-click behavior in the Mac Finder or Windows Explorer.

What happens when you double-click an .indd file? Often, the wrong app will launch and open the file (or refuse to do it). Gah!

Soxy would intervene in the double-click process in Finder or Explorer. It would automatically detect the version of a double-clicked .indd file and route it to the correct app.

E.g. if you double-click an .indd file created with InDesign 2024, it would open that file in InDesign 2024, even if InDesign 2025 was also installed and running.

Over time, the versioning issues became less of a problem for most users after Adobe Creative Cloud became subscription-based. The majority of users now keep only the latest version of an app installed. There was little demand for Soxy, and we had to put it out to pasture.

These days, I am working on PluginInstaller most of the time, working on a unified installing experience.

As it so turns out, this might lead to a resurrection of Soxy.

Where Are The Apps?

The next big task ahead of me is to enhance PluginInstaller to also handle C++ plug-ins smoothly.

It’s a major work in progress. The current version will install and uninstall InDesign ExtendScript and CEP panels with a click of a button.

Contrast to that, C++ plug-ins still need to be manually dragged into a Plug-Ins folder. The current version of PluginInstaller will handle activation and licensing, but installing is not yet supported.

In my view, installing any enhancement to any app in the Adobe Creative Cloud should work the same from a user perspective. The user does not need to know what technology drives the enhancement (script, C++ plug-in, CEP extension, UXP extension…). So that’s the goal I am working towards.

Part of my current effort is to figure out where to install ‘stuff’, and that turns out to be a little more complicated than it might seem.

For example, if you have an Applications folder that looks like this:

If I simply say a ‘C++ plug-in for InDesign’…, then there are 11 places in this screenshot where that plug-in might need to go.

Factors that play into the calculations PluginInstaller will need to make:

  • Some apps have version requirements: e.g. InDesign C++ plugins compiled for InDesign 2024 don’t work with InDesign 2025. It’s been a while since I worked on Photoshop and Illustrator plug-ins, but I seem to remember that plug-ins for Illustrator or Photoshop have some ‘version flexibility’, so the version requirements are not always clear-cut.
    Also, with InDesign, we all still remember the 16.x issues, where plug-ins became sub-version-dependent (e.g. 16.0 being incompatible with 16.3).
    I need to make sure PluginInstaller is resilient enough to handle this situation when this happens again.
  • Some plug-ins are ‘cross-app’ – C++ plugins for InDesign might (or might not) also work with InCopy or InDesign Server or vice versa.
  • Some apps have ‘year’ versioning – 2023, 2024, 2025. Others do not (e.g. Lightroom Classic, UXP Developer Tools,…).
    I also prefer to accept alternate version numbers – e.g. InDesign 2025 can also be referenced to as InDesign 20.0 or InDesign CS 18 or InDesign CC 2025.
  • InDesign has Middle Eastern versions, which have some differences with the regular versions.
  • Some apps have debug versions which are mutually incompatible with regular versions.
  • Install locations for ‘stuff’ use different kinds of logic depending on the technology used.
    * CEP panels can be shared between multiple app versions (e.g. InDesign 2024 and InDesign 2025 can run the exact same CEP panel code from the exact same install location, CEP manifest allowing).
    * InDesign scripts are installed in a version-dependent location but are shared between multiple app executables of the same version (e.g. InDesign 2025 Debug and InDesign 2025 share the same Scripts folders, but InDesign 2025 Middle Eastern does not).
    * C++ plug-ins are handled on a ‘per app executable’ basis.

Briefly put: ‘it’s complicated’.

Building A Local Knowledge Base

In order to get this functionality into PluginInstaller, I am working on a queryable local knowledge base.

This is a data structure that keeps track of which apps are installed where, and where their install locations are (e.g. Plug-Ins folder, ~/Library/Application Support,…).

PluginInstaller can scan the local infrastructure and has an internal API that can be queried by the installer module to figure out what options there are to install a certain ‘thing’.

E.g. for an InDesign/InCopy/InDesign Server plug-in, we need to pass into the API:
– for what version
– debug or non-debug
InDesign, InCopy, InDesign Server, or a combination thereof

Whiff Of Soxy

I’ve only just started working out how this is all going to work, but as I was working on this it felt strangely familiar.

And then I suddenly realized: I’ve done very similar stuff before, when we were building Soxy.

And once this data structure in PluginInstaller is properly working, re-implementing Soxy within PluginInstaller will be quite straightforward.

Creating a smooth installation experience is first on the to-do list, but a resurrection of Soxy might follow some time after that!