If you ship a product built on the AutoCAD OEM platform, you eventually have to produce a distributable installer, get it digitally signed, and make sure it installs cleanly on a customer machine. Simple in theory. In practice, one mis-ordered step can silently break the signature and customers may hit Error 15 during installation with no obvious reason why.
This post walks through a practical signing pipeline for an AutoCAD OEM based product and explains why Error 15 happens and how to prevent it.
The Four-Stage Pipeline
┌─────────────────────┐
│ 1. OEM MakeWizard │ Build branding, resources, ARX modules
└────────┬────────────┘
│
┌────────▼────────────┐
│ 2. Installer Wizard│ Generate setup.exe + MSI package
└────────┬────────────┘
│
┌────────▼────────────┐
│ 3. Code Signing │ Sign final installer output
└────────┬────────────┘
│
┌────────▼────────────┐
│ 4. Clean VM Test │ Validate on a fresh machine
└─────────────────────┘
The rule: signing is always the last step. Nothing should modify the installer files after signing.
Stage 1 — OEM MakeWizard
MakeWizard builds the product-specific parts of your AutoCAD OEM application: branding resources, splash screen, about-box bitmap, application menu images, product configuration, and modules that should be included in the OEM build.
Before running this stage, make sure:
- All image resources use the required pixel dimensions.
- All required commands and modules are included in the product configuration.
- The build environment is using the correct Microsoft Visual C++ tools.
Example command:
oemmakewizard.exe FalconCAD <serial> /BALL /BT /BR /PA:"D:\BUILDS\FalconCAD" /STOPCommon MakeWizard trap — wrong linker
If you run the build from an environment such as MSYS or another shell that modifies the
PATH, the wrong link.exe may be picked up. This can cause resource DLL
builds to fail with confusing linker errors.
Use a clean Visual Studio Developer Command Prompt and confirm that the Microsoft linker is the one being used.
Stage 2 — Generate the Installer
Installer Wizard takes the MakeWizard output and packages it into the final distributable installer,
usually a setup.exe bootstrapper with one or more MSI packages.
An important detail is that installer generation is not simply a file copy operation. During this stage, the installer is finalized and additional packaging steps may update the generated files. As a result, file contents and hashes can change before the installer is ready for distribution.
Because of this, you should treat the completed Installer Wizard output as the first candidate for code signing, not any intermediate files created earlier in the process.
Do not sign anything until Installer Wizard has completely finished.
Any signature applied before installer generation is finalized may become invalid if the files are modified during packaging.
Stage 3 — Code Signing
Once Installer Wizard has completed and no further packaging steps remain, sign all installer components that will be distributed to customers:
setup.exe- All MSI packages
- Any executable payloads launched during installation
The signing tool itself is not the important part. Whether you use your organization’s signing service, a cloud signing provider, a hardware-backed certificate, or Microsoft’s signing tools, the pipeline rule is the same:
- Generate the installer.
- Sign the final output.
- Do not modify the files afterward.
Verify the signatures immediately after signing:
sigcheck.exe -a setup.exe
sigcheck.exe -a FalconCAD.msiBoth files should report a valid signature and certificate chain. If any file reports as unsigned, revoked, or untrusted, stop and fix the signing issue before shipping.
Treat signed files as immutable
After signing, consider the installer output immutable.
Avoid:
- Re-running Installer Wizard on the same output
- Repackaging the installer
- Uploading to a system that modifies or re-wraps the installer
- Any workflow that changes installer files after signing
If a file changes after signing, even by a single byte, the signature may no longer match the file contents and installation validation can fail.
The safe pipeline is:
Build ↓ Generate Installer ↓ Sign ↓ Ship
Do not use this pipeline:
Build ↓ Sign ↓ Modify Installer ↓ Ship
Stage 4 — Clean Machine Test
Always test on a clean machine or virtual machine that has not previously had AutoCAD or your OEM product installed. Leftover registry entries, shared components, or licensing artifacts from earlier installs can hide problems that a real customer may hit immediately.
Verify the following:
- The installer runs to completion with no rollback.
- No Error 15 or trust validation prompt appears.
- The product launches successfully.
- Branding appears correctly, including splash screen, about box, and title bar.
- Core commands work as expected.
- License activation completes normally.
What Is Error 15?
Error 15 generally indicates that the installer could not validate the digital signature of one or more packages being installed.
There are three common causes:
| Cause | What happened | How to diagnose |
|---|---|---|
| File was never signed | setup.exe or an MSI was shipped without a digital signature |
sigcheck.exe reports the file as unsigned |
| File was modified after signing | The file was signed correctly, but something changed it afterward | The file may appear signed, but installation validation still fails |
| Certificate problem | The certificate is expired, revoked, or not trusted on the target machine | Signature verification reports a certificate chain or trust error |
The most confusing case is the second one. A file can appear to have a signature, but still fail validation if it was modified after signing. Authenticode signatures are tied to the file contents. Any post-signing modification can make the signature invalid for installation purposes.
Answering the Classic Support Query
“I signed setup.exe and it installed fine. I rebuilt the next day, signed again, and now it fails with Error 15. What is going on?”
This is usually a pipeline order problem, not a signing tool problem.
A common failure sequence looks like this:
- Installer Wizard generates the installer.
- The developer signs
setup.exeand the MSI files. - A later process modifies, repackages, or regenerates part of the installer.
- The signature no longer matches the final file contents.
- The installer fails validation with Error 15.
The fix is not to sign differently. The fix is to ensure that nothing runs after signing.
Treat the signed output as final. If you need to rebuild, rebuild from the original source output and sign the new final installer. Do not continue modifying files after they have been signed.
Checklist Before Shipping
- MakeWizard completed successfully.
- Installer Wizard completed fully with no interruptions or re-runs.
- Code signing was performed only after installer generation completed.
setup.exeis signed.- All MSI packages are signed.
- Any executable payloads launched during install are signed.
- No automated step modifies, repackages, or re-wraps the files after signing.
- The exact signed output is what will be delivered to the customer.
- A clean machine installation test has passed.
Summary
Building a correctly signed AutoCAD OEM installer is straightforward once the pipeline order is locked in. First build the product, then generate the installer, then sign the final installer output. After signing, do not modify the files.
Error 15 is usually a process problem rather than a certificate problem. If the signature appears valid but installation still fails, look carefully for anything that modified the installer after signing.
The rule is simple:
Generate → Sign → Ship. Never modify after signing.
The examples in this article use Sigcheck, a Microsoft Sysinternals utility for inspecting Authenticode signatures. Download it from: Microsoft Sysinternals Sigcheck .
Alternatively, PowerShell provides built-in signature validation:
(Get-AuthenticodeSignature .\setup.exe).Status
A correctly signed installer should report Valid.
Leave a Reply