I have been building AutoCAD OEM based applications for years now. Just recently, I stumbled upon some freak error I have not been able to resolve.
With the AutoCAD OEM platform, the Installer Wizard creates the installer for the (gargantuan) application. The application installer is started (of course) with calling the setup.exe.
With the last AutoCAD OEM versions up until AutoCAD OEM 2022, the signing of the setup.exe has been no problem at all.
Now, with the current AutoCAD OEM 2023 version, I experience that the signing of the setup.exe does not work anymore. When trying to sign the setup.exe, the error 0x800700C1 returns. This is a very generic error message, and googling after this does not bring any helpfull results.
Jens,
I once had a similar issue with that error that even “delcert” did not work on and I ended up using a tool called “CFF Explorer” that is available on Github to find a bad security directory and remove it. I also had to use it on OEM 2022 to isolate an issue with the Security Directory and remove it to sign files. Here is a screenshot of the tool and the area that was bad in OEM 2022:
I just looked at the OEM2023 setup.exe with the CFF Explorer, but there is no obvious error displayed or visible. Even if there would have been, it would just have been an interesting data point. We have a fully automated build pipeline, and having to manually edit the setup.exe with a tool is just breaking the pipeline.
I am hoping for the guys at Autodesk to come up with an solution for this.
Jens,
Completely understand.
We will be moving to and updating our automated build process for OEM 2023 in the next month. We will be sure to keep this in mind in case we run into it. If we discover anything helpful we will be sure to pass it on. If you discover anything before that that may help let us know.
Thanks,
Shawn
Jens,
We were able to automate our workflow around this issue in OEM 2023 until they come up with a solution.
We did the following:
After the OEM Install Wizard was complete we removed the “Security Directory RVA” from the Setup.exe using CFF Explorer. You can refer to our previous comment and picture above to show the area.
We then were able to sign the Setup.exe
Rather than doing a manual process each time we chose to use the above corrected and signed Setup.exe as a base that we copy and overwrite the setup.exe each time we build an installer.
This works for us because our setup does not require that the setup.exe be changed very often, if at all. Setup.exe mainly points everything to the installer. All the essential heavy lifting occurs after setup.exe is ran.
As you already noted, delcert.exe does not work with OEM 2023 Setup.exe and we ran into additional issues when we tried it. It stripped out the ICO information and removed the Run As Admin that Autodesk requires on its setup.exe’s. This did not happen in previous OEM’s and delcert.exe is still a safe option to use to sign OEM 2022 and older.
Hope this may help anyone running into this.
Shawn Golden
Microvellum
Hi,
Thanks to all for this topic, it helps me very much.
As we needed to remove manual actions, I used the LUA scripting capability of CFF Explorer.
If you also need to have a fully automated process, I share you below a part of my script file:
...
REM Initialization
set CurFolder=%~dp0
set CFFExplorer="..\..\..\CFF_Explorer\CFF Explorer.exe"
set CFFScript=%CurFolder%clean-setup.cff
set TargetFold=%CurFolder%_master\
set TargetFile=%TargetFold%setup.exe
REM Remove Security Directory from file
:RemoveSD
echo -- LUA Script to remove Security Directory from EXE file > %CFFScript%
echo filename = @"%TargetFile%" >> %CFFScript%
echo if filename == null then >> %CFFScript%
echo return >> %CFFScript%
echo end >> %CFFScript%
echo pehandle = OpenFile(filename) >> %CFFScript%
echo if pehandle == null then >> %CFFScript%
echo return >> %CFFScript%
echo end >> %CFFScript%
echo result = RemoveDataDirectory(pehandle, IMAGE_DIRECTORY_ENTRY_SECURITY) >> %CFFScript%
echo if result != true then >> %CFFScript%
echo MsgBox("Security Directory not removed!") >> %CFFScript%
echo else >> %CFFScript%
echo if SaveFile(pehandle) != true then >> %CFFScript%
echo MsgBox("Error saving file!") >> %CFFScript%
echo end >> %CFFScript%
echo end >> %CFFScript%
echo CloseHandle(pehandle) >> %CFFScript%
echo -- End >> %CFFScript%
%CFFExplorer% clean-setup.cff
REM Apply signature to file
:SignFile
%SIGNTOOL% sign /v /n "MyCertificate" /a /tr "%TIMESTAMP_URL%" /td SHA256 /fd SHA256 "%TargetFile%"
if %ERRORLEVEL% NEQ 0 goto :SignFailed
...
I am also experiencing this problem with AutoCAD OEM 2025. So far I can not get SETUP.EXE to run (it simply terminates). I’ve been advised that the problem is that I have not signed the SETUP.EXE and now that I am trying I get this error.
I’ve build AutoCAD OEM applications for years but have now updated to 2025 from a much older version so this is all new and very confusing. i’ve not used CFF and don’t understand the implications of doing so.
It seems to me that creating an installation kit should not be this hard. I shouldn’t have to modify each SETUP.EXE to sign it as I’m having to update installation kits a lot during this development process.
Is there any better way that what is outlined above?
While many of us sign the setup.exe it is not required. In fact, I believe the Setup.exe comes digitally signed by autodesk or at least it used to. If you have any bound exe’s for your program itself, it is still optional as to whether you want them signed (Highly recommended though). What is required is the signing of your program MSI file which, after the build process is done, is located in your …x64[ProgramName] folder. Here is the quote from the Developer’s Guide:
“While digital signatures are optional for the executable files bound to the OEM product, it is highly recommended to digitally sign your executable files if and whenever possible. Even though it is optional to digitally sign your executable files, starting with AutoCAD OEM 2023, the MSI file created from the OEM Installer Wizard must be digitally signed. If the MSI file isn’t digitally signed, the installer will fail to run.”
For testing purposes you could exclude signing the setup.exe and just do the MSI to see if it still fails.
In the past, it used to pop up a message saying that the file is not signed if that was the issue.
Upon building my product I was able to sign the MSI and the MSI works.
The SETUP.EXE would never work. Just says something is wrong trying to start setup then gives you an EXIT button to click. Nothing more than that.
Upon advising TechSmith of this they told me - as you did - to sign the SETUP.EXE but I can’t sign it because it keeps returning this SIGNTOOL error 0x800700C1 error.
Can’t find any kind of logging file or anything that suggests what the issue is. Didn’t want to do all this digging to try and debug what Autodesk has done wrong. Pay big money for product - product doesn’t work correctly - becomes my problem to fix it.
It sounds like you still have an error even if you don’t try to sign the setup.exe, correct?
If that is then there is more than likely something else going on that is preventing the installer from running. Are you making modifications to the XML’s? If so, you may want to try to run the installer prior to making any mods to the XML to see how behaves out of the box.
Shawn Golden
Microvellum
Also, if there are any you will want to check the ODIS logfiles very carefully.
.\APPDATA\Local\Autodesk\ODIS
You could also try the log collection tool noted here but you may need to be farther along in the install to get anything useful: Troubleshooting installation issues OEM
It blows up immediately so there is no info to be found via logging.
I’m not doing anything that isn’t vanilla. I just build the install and attempt to run the SETUP.EXE with no signature and it blows up. If I try to sign the SETUP.EXE all is does is throw the 0x800700C1 error code.
The MSI works perfectly.
Really scratching my head. It just doesn’t want to work. I’m running everything full ADMIN off my local C drive to rule out permissions. I just don’t get it and neither does TechSoft at this point.
I really appreciate you trying to help me Shawn. You are a good dude.
Is there anyone here who could possibly help me with this? I’m willing to pay you to do so.
I can’t get anywhere with this and everything I read seems to be conflicting with what TechSoft is telling me which is to sign the SETUP.EXE - which I can’t do because of errors as outlined above. I’m not experienced enough to hack the SETUP.EXE file but I SHOULD NOT HAVE TO as this is clearly a DEFECTIVE product.
Feel free to contact me directly at RGreen@GreenConsulting.com if you can assist. Again, I’m willing to pay for the assistance.
Thanks for sharing your „desperation”. I sympathise strongly, hitting some wall trying to implement something is always very frustrating.
The signing of the exe file is just a signal to the operating system, and/or some other application and the user that the application is trustworthy in itself.
That said, unsigned files still should run without any problems. The Windows UAC (User Account Control) may apply some limitations when it encounters an unsigned file, like showing some warning message.
In any case, the setup.exe should (after UAC handling) execute and do its thing.
I am wrestling with some other issue with OEM 2025 and I share your sentiment that this product may not be as ready for publication as it should be.
If I find something that goes into your direction, I will update this post.
It is good to know that I am not crazy as other people are having problems as well.
I can create the MSI package and digitally sign it and it does work. But nothing in the registry is updated as it should be because SETUP.EXE does not run.
I have tried everything I can think of and have done everything suggested by tech support with no results.
If I find any new information I will post here or if you want to email me I will reply to you that way. RGreen@GreenConsulting.com
Ok, thanks Shawn and Jens for chiming in.
I fully understand your frustration, believe me I also get frustrated over these things and the lack of feedback on error messages with the new ODIS installation concept.
Also, Robert Green’s issue is now (partially?) solved by studying the ODIS logs. The key and quickest way to solve these issues is without doubt to use the log file collection tool announced here: Troubleshooting installation issues OEM
It’s simple and straightforward to use and most likely the fastest way to deal with installer issues.
It turns out the TOU (Terms Of Use) refer to Autodesk terms, which is not correct as an OEM product is a partner product and not an Autodesk product.
I have exactly the same problem with OEM 2024 - MSI signs fine every time and setup.exe refuses with that BADFORMAT error being the returned value.
I followed the post by @shawn.g above and downloaded the CFF Explorer tool. Loading setup.exe in that, go to the Data Directories and right click on the Security Directory entries and select Remove Data Directories, just as shawn’s post shows.
Save the exe and, hey presto, the signing tool works this time. It’s a pain but it’s a definite fix.
All I can say is a big thank you to @shawn.g for publishing a way to fix it! Seems a nicer fix than having to install NodeJS…
The problem for me is that the SETUP.EXE won’t run - it just crashes on startup.
Following the instructions from the TERMS OF USE post above provided no joy. The file folders outlined are not correct for the 2025 version, the files called out exist in two different locations with different file contents and the URL called out for replacement doesn’t exist in either of the BUNDLE.JS files.
I’m not going to just randomly hack my way thru this in hopes that I accidentally figure out how to make the product install.
I think this is a case where they had a fix for 2023 and they haven’t looked at the fix to make revisions for 2025. It simply doesn’t work as documented.
