Why your AutoCAD OEM installer silently crashes on customer machines (and how to fix it)

We just closed a support ticket that took a month of back-and-forth, and it ended up being a really interesting lesson in how antivirus software works under the hood.

If you build products on AutoCAD OEM, you might have run into this scenario: a customer runs your installer, the UI flashes for a split second, and then it just quits. Sometimes you might get a generic error dialog, but often, it’s just a completely silent crash. You test it locally and it works perfectly. It’s incredibly frustrating to debug.

The log that made no sense

Since AutoCAD OEM uses the Autodesk ODIS installation framework, we had the customer send over their DDA.log. When we looked through it, we found a contradiction that made us scratch our heads.

The log showed the installer successfully verifying the digital signature of DownloadManager.exe. This means the file was successfully extracted and was physically sitting on the customer’s hard drive. But literally the next line in the log showed the Windows CreateProcess call failing to launch it, throwing an Error Code 2 (File Not Found).

How does Windows fail to find a file it just verified a millisecond ago?

The Antivirus Hijack

It turns out, this is how antivirus programs (like Windows Defender, Norton, or Avast) quietly hijack processes. They use a Windows Registry feature called Image File Execution Options (IFEO).

Microsoft originally built IFEO so developers could attach debuggers to their applications. But AV vendors realized they could use it to block malware. Because the ODIS installer downloads payloads and silently extracts executables in the background, aggressive AV heuristics sometimes freak out and flag it as a dropper.

To block the “threat”, the AV creates an IFEO registry key for the installer’s executables and adds a Debugger string value pointing to “Blocked” or a dummy file. From that moment on, whenever Windows tries to launch DownloadManager.exe, it intercepts the call and tries to run the non-existent debugger instead. When that fails, Windows throws the “File Not Found” error back to our installer, causing it to crash.

The most annoying part is that even if the customer completely uninstalls their antivirus to troubleshoot, these registry keys are often left behind. The OS remains permanently rigged to block your installer.

A quick way to check

If you want to quickly scan a customer’s machine to see if any executables are being hijacked by IFEO, you can run this PowerShell script. It searches the registry and spits out any keys that have a Debugger attached:

Get-ChildItem "Registry::HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" -Recurse -ErrorAction SilentlyContinue |
    ForEach-Object {
        $p = Get-ItemProperty -Path $_.PSPath -ErrorAction SilentlyContinue
        if ($p.Debugger -or $p.GlobalFlag -or $p.VerifierDlls) {
            [PSCustomObject]@{
                Key          = $_.PSChildName
                Debugger     = $p.Debugger
                GlobalFlag   = $p.GlobalFlag
                VerifierDlls = $p.VerifierDlls
                Path         = $_.PSPath
            }
        }
    }

How to fix it

Once we figured out what was happening, the fix was actually really simple. You just need to clear out the leftover debugger blocks in the registry.

1. Open the Windows Registry Editor (regedit).
2. Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
3. Look for any sub-keys matching Autodesk or ODIS executables (like DownloadManager.exe, ProcessManager.exe, AdskAccessUIHost.exe, or Setup.exe).
4. If you see a Debugger value inside any of those folders, delete it.

Our partner had the customer clear those blocked registry keys, and the installations immediately went through without a hitch. Hopefully, this saves someone else a month of troubleshooting!