Windows Captive Runtime Packaging Fails

[MMPGreg]

I’ve been frustrated for weeks as to why I can no longer successfully build a Flex/AIR captive runtime bundle package for Windows using IntelliJ, or the adt command line. I build Windows packages on my Mac using Parallels, and I was last successfully able to do so in August this year. Though I can’t point to any particularly significant change, other than regular software/OS updates, nothing has changed in my workflow.

Even attempting to package the most bare-bones Flex/AIR app, the process fails. The SDK version appears to not be a factor either, as the issue is replicated from the current SDK, and backwards to 33.1.

Full error message:
unexpected failure: Platform conversion failed. Process exited with error 5. Output was "[ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Unhandled exception Error: Error #3012" errorID=3012] " java.io.IOException: Platform conversion failed. Process exited with error 5. Output was "[ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Unhandled exception Error: Error #3012" errorID=3012] " at com.adobe.air.nai.NativePackager.conversionFail(NativePackager.java) at com.adobe.air.nai.NativePackager.invokePlatformConversion(NativePackager.java) at com.adobe.air.nai.NativePackager.createPackage(NativePackager.java) at com.adobe.air.ADT.parseArgsAndGo(ADT.java) at com.adobe.air.ADT.run(ADT.java) at com.adobe.air.ADT.main(ADT.java)

ADT command line:
C:\Program Files\JetBrains\IntelliJ IDEA 2024.2.3\jbr\bin\java.exe -Dapplication.home=C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2 -Dfile.encoding=UTF-8 -Djava.awt.headless=true -Duser.language=en -Duser.region=en -Xmx512m -jar C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2\lib\adt.jar -package -storetype PKCS12 -keystore C:\Users\tormund\AppData\Roaming\JetBrains\IntelliJIdea2024.2\plugins\flex\lib\temp_keystore.p12 -storepass keystore_password -tsa none -target bundle C:\TestApp\out\production\TestApp\Main C:\TestApp\out\production\TestApp\Main-app.xml -C C:\TestApp\out\production\TestApp Main.swf

When I attempt with verbose logging, I additionally get:
C:\TestApp\MyApp: error 301: Application descriptor missing/cannot be opened

The application descriptor (Main-app.xml) is most definitely in the project, and has been granted every read/write permission I could see to grant it. After build, it resides at:
C:\TestApp\out\production\TestApp\Main-app.xml, alongside Main.swf.

I suppose my main question is, what in that series of NativePackager functions are possible failure points?

Here are all the specs of my setup:
• Mac Studio - macOS Sonoma 14.7
• Parallels Desktop 20.1.1
• Windows 11 Pro 10.0.22621 Build 22621
• IntelliJ IDEA 2024.2.3 (Ultimate Edition)
• Flex 4.16.1 / AIR 33.1.1.821 through 51.1.2.2

Thank you for any help or guidance!

[ajwfrost]

The error thrown seems to be from the 'native packager' part:

Platform conversion failed. Process exited with error 5.
Output was "[ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Unhandled exception Error: 3012" errorID=3012] "
at com.adobe.air.nai.NativePackager.conversionFail(NativePackager.java)
at  com.adobe.air.nai.NativePackager.invokePlatformConversion(NativePackager.java)

The Java call in NativePackager is to invoke this 'platform conversion' part which is itself an AIR process, and is encountering an error which makes it throw error 3012 = Cannot delete file or directory.

Although .. looking at the code, and thinking what it has to do, it's a bit strange to find a 'delete' error, it's not actually deleting anything! It does stuff like creating the application icon file, updating the executable template, etc.

This perhaps is another area where we need a 'verbose' option. I don't suppose you get anything out of Scout? Really we could do with a call stack of the error 3012 so we knew where that was being thrown from.

The likely reason for not being able to delete something might just be permissions; are you able to check your "temp" variable is set up to a read/write folder structure, or maybe try running the whole thing as an administrator, etc? Failing that, let us know and we can put together a version with additional logging to try to get at the root cause..

thanks

[MMPGreg]

Scout reports nothing during the packaging process, so I think I've gotten all I can out of any logging/tracing.

I ran IntelliJ as an administrator and the packaging behavior was no different.

I've tested my TEMP variable location "C:\Users<username>\AppData\Local|Temp" by wiring to and removing a text file with PowerShell, and had no problem.

I monitored the TEMP folder during the build, and grabbed the state of the directory at the point of failure. I'm attaching it as a .zip, for whatever additional information may be gleaned from it. My only observation is that it does contain an app descriptor file, but it is named different ("application.xml") than my project's ("Main-app.xml").
flaBA9B.tmp.zip

Any additional help would be appreciated. Thanks!

[ajwfrost]

Weirdly - that temporary application is a Flex app that just seems to display a "hello world" alert on a button click...

I'll try to get a build that has additional debugging in here to see where it might all be going wrong. My only other suggestion in the meantime is to see if you've got the adt.log stuff enabled (or run the AIR SDK Manager with the 'troubleshooting' screen) so that you can see the command-line options that IntelliJ is passing to ADT. And then try running ADT from a command prompt in case it then outputs any more information..

thanks

[MMPGreg]

Thanks @ajwfrost , yes the application is just the default template when I started a new Desktop Flex/AIR app in IntelliJ. I don't know which entity is responsible for creating it, but I left it as is.

I'll look into your additional suggestions.

[ajwfrost]

Hi

For extra debugging info, we've put together some updated runtimes and a quick tool to check this:
https://transfer.harman.com/message/9XOXY9VovhFs9omStmMclT
If you're able to try with that, we can hopefully see whereabouts it's failing..

thanks

[MMPGreg]

Thank you,
I replaced the win runtimes with the versions you provided. Running with AIRInstallerLogger TempAIRSDKManager running, my build/package process from IntelliJ returns this text:

Debug: ApplicationSignature, constants are VALID = 0, invalid = 1, selfsign = 2, nottrusted = 3, unknown = 4, no signature = 5
Unpackaging begin: file:///C:/TestApp/out/production/TestApp/air2267733285132988569.tmp, C:\Users\tormund\AppData\Local\Temp\fla5D42.tmp
Debug: Checking package signature status

Building with production version of AIR SDK Manager, I get this output:

ADT 51.1.2.2 called with: -package -storetype PKCS12 -keystore C:\Users\tormund\AppData\Roaming\JetBrains\IntelliJIdea2024.2\plugins\flex\lib\temp_keystore.p12 -storepass xxxxxx -tsa none -target bundle C:\TestApp\out\production\TestApp\Main C:\TestApp\out\production\TestApp\Main-app.xml -C C:\TestApp\out\production\TestApp Main.swf

Creating temporary AIR package at C:\TestApp\out\production\TestApp\air16231984191356268960.tmp

Converting AIR file: C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2\lib\nai\bin\naip32.exe -convert C:\TestApp\out\production\TestApp\air16231984191356268960.tmp C:\TestApp\out\production\TestApp\adt11343823269549270129.tmp\temp -captive

Conversion process exited with error 6.
NAIP result: UCF Unpackager dispatching error: 0: SDK is missing certificate file: C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2\runtimes\air\win\Adobe AIR\Versions\1.0\Resources\Thawte Root Certificate.cer

Stack trace:
..java.base/java.lang.Thread.getStackTrace(Thread.java:2450)
..com.adobe.air.DebugFile.printStack(DebugFile.java)
..com.adobe.air.InvalidInputException.(InvalidInputException.java)
..com.adobe.air.nai.NativePackager.invokePlatformConversion(NativePackager.java)
..com.adobe.air.nai.NativePackager.createPackage(NativePackager.java)
..com.adobe.air.ADT.parseArgsAndGo(ADT.java)
..com.adobe.air.ADT.run(ADT.java)
..com.adobe.air.ADT.main(ADT.java)

Invalid input: Packaging failed. Packager internal error

With this, IntelliJ's error notification reports the error as:

Failed to package AIR application Main: Packaging failed. Packager internal error

ADT Command Line

C:\Program Files\JetBrains\IntelliJ IDEA 2024.2.3\jbr\bin\java.exe -Dapplication.home=C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2 -Dfile.encoding=UTF-8 -Djava.awt.headless=true -Duser.language=en -Duser.region=en -Xmx512m -jar C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2\lib\adt.jar -package -storetype PKCS12 -keystore C:\Users\tormund\AppData\Roaming\JetBrains\IntelliJIdea2024.2\plugins\flex\lib\temp_keystore.p12 -storepass keystore_password -tsa none -target bundle C:\TestApp\out\production\TestApp\Main C:\TestApp\out\production\TestApp\Main-app.xml -C C:\TestApp\out\production\TestApp Main.swf

These are certainly different errors than I experienced prior to changing out the runtimes. Are these outputs meaningful?

[ajwfrost]

Ah - thanks for that, although the problem there is probably just a separate one because I'd picked up the runtime folder from the build rather than from our SDK deployment, so it would be missing that Thawte certificate.. are you able to put that back, from the original SDK runtime folder? (TBH it might be simpler to use the original AIR SDK, and just copy over the "Adobe AIR.dll" files from the new package....)

thanks

[MMPGreg]

I restored my backed up captive runtimes, and this time copied over just the DLLs. Now, I get the expected 3012 error from packaging in IntelliJ.

TempAIRSDKManager reports:

Debug: ApplicationSignature, constants are VALID = 0, invalid = 1, selfsign = 2, nottrusted = 3, unknown = 4, no signature = 5
Unpackaging begin: file:///C:/TestApp/out/production/TestApp/air15571161368498765143.tmp, C:\Users\tormund\AppData\Local\Temp\flaA616.tmp
Debug: Checking package signature status

Production AIR SDK Manager reports:

ADT 51.1.2.2 called with: -package -storetype PKCS12 -keystore C:\Users\tormund\AppData\Roaming\JetBrains\IntelliJIdea2024.2\plugins\flex\lib\temp_keystore.p12 -storepass xxxxxx -tsa none -target bundle C:\TestApp\out\production\TestApp\Main C:\TestApp\out\production\TestApp\Main-app.xml -C C:\TestApp\out\production\TestApp Main.swf

Creating temporary AIR package at C:\TestApp\out\production\TestApp\air2169533418949245053.tmp

Converting AIR file: C:\AIRSDKs\Flex_4.16.1_AIR_51.1.2.2\lib\nai\bin\naip32.exe -convert C:\TestApp\out\production\TestApp\air2169533418949245053.tmp C:\TestApp\out\production\TestApp\adt10098085625076617970.tmp\temp -captive

Unexpected failure: Platform conversion failed. Process exited with error 5. Output was "[ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Unhandled exception Error: Error #3012" errorID=3012]
"

So I'm not sure that there's anything new here.

[ajwfrost]

Thanks - actually, that does tell us a bit more, because we can see what's happening between the final line there, and the next line that we would expect. Which is still related to the application signatures .. so it seems that the temporary AIR package is created but that we cannot validate its signature! Which is a little odd... particularly if the error is 3012..

We'll likely need to add even more debug output into the relevant code to dive into this particular area.

[MMPGreg]

I'm glad you got something from it! Let me know what else could help.

[MMPGreg]

@ajwfrost , do you have an ETA when I might expect a new logging tool to further troubleshoot this 3012 error?

[ajwfrost]

Hi - sorry for the delays; we had added some of this diagnostic output into our next build so I had hoped we could just provide you with that .. but there are a couple more investigations/bugs that are holding that up! So I will try to get an instrumented version of the 51.1.2.3 release over to you tomorrow.

Just checking, given it seems to be a signature thing, is your keystore file (temp_keystore.p12) a 'normal' keystore, 2048-bit or more for the key, etc? I'm actually not sure why we would fail on verification of the signature when this is part of the single build process, and untrusted/self-signed signatures should actually be acceptable here..

thanks

[ajwfrost]

Just a quick update: we've just found that even with our successful packaging, there seems to be a gap in the log .. i.e. we had seen the last line in your log was "Checking package signature status", and the code wasn't reaching our next log output, so assumed the issue was within that signature check.

However, after we've added more output here, we've just found that we also don't get the subsequent output that we had expected! So, potentially the code has always been throwing an error at this point, and yet on our system it then works vs on yours .. it may be something else!

So we will have to add a bit more logging in here I think, to capture whatever is happening after that signature validation, and to see what may be causing the "error 5" output..

Will try to get a version out today still, though it may slip until tomorrow (as changing the internal code at this level results in a full rebuild of everything..)

thanks

[MMPGreg]

Thank you for your attention to this! I'm about to go on holiday, but will be back and ready to continue work on Monday, so no rush needed before then.

[ajwfrost]

Below is a link to the updated runtime file, plus instructions - whenever you get a chance to try it out next week! Happy Thanksgiving :-)

https://transfer.harman.com/message/8zHPbcUqVvlNq80RGLaOVY

[MMPGreg]

Thanks! I replied to that link with the contents of the log. Additionally, the notification from IntelliJ has changed, with a new error code:

unexpected failure: Platform conversion failed. Process exited with error -1073741819. Output was "" java.io.IOException: Platform conversion failed. Process exited with error -1073741819. Output was "" at com.adobe.air.nai.NativePackager.conversionFail(NativePackager.java) at com.adobe.air.nai.NativePackager.invokePlatformConversion(NativePackager.java) at com.adobe.air.nai.NativePackager.createPackage(NativePackager.java) at com.adobe.air.ADT.parseArgsAndGo(ADT.java) at com.adobe.air.ADT.run(ADT.java) at com.adobe.air.ADT.main(ADT.java)

[ajwfrost]

Hi

This is curious but may mean it's linked to the other problem we were looking at with the same logging code, which was a problem when trying to install the AIR shared runtime itself. But that was freezing/failing at a similar place: the last thing in your log there is:

[2024-12-02:11:37:05] Starting conversion: copying C:\Users\username\AppData\Local\Temp\fla7CCF.tmp to C:\Users\username\AppData\Local\Temp\fla7D7C.tmp

And if the copy succeeded, we should have seen the next log line appear:

Converting: getting directory listing for C:\Users\username\AppData\Local\Temp\fla7CCF.tmp

The call it seems to be failing on is: File.copyTo()
We just added a fallback/workaround for this operation so it might be worth checking with 51.1.3.1 (available within a couple of hours) but as I recollect, the other issue was still failing, with an error code saying "invalid path".

This was also running on a Windows VM on macOS, so I'm wondering if there's some weird problem related to that.. but at the end of the day, we're just calling the Win32 file APIs so I'm not sure why they may have issues. Potentially there's some file lock or similar, I guess we can double-check for that; we couldn't reproduce the issue ourselves when installing on a Windows 11 VM running on macOS..

thanks

[MMPGreg]

I downloaded 51.1.3.1 and attempted to rebuild. Error output from IntelliJ remains the same. I believe the log output is generally the same, too:

[2024-12-05:14:10:22] ApplicationSignature, constants are VALID = 0, invalid = 1, selfsign = 2, nottrusted = 3, unknown = 4, no signature = 5
[2024-12-05:14:10:22] Unpackaging file:///C:/TestApp/out/production/TestApp/air10234714583979603072.tmp to C:\Users\tormund\AppData\Local\Temp\fla33D1.tmp
[2024-12-05:14:10:22] Checking package signature status
[2024-12-05:14:10:22] Result of getSignatureStatus is invalid
[2024-12-05:14:10:22] ApplicationSignature.getAppSigStatus, validityStaus = invalid
[2024-12-05:14:10:22] ApplicationSignature.getAppSigStatus, identityStatus = unknown
[2024-12-05:14:10:22] ApplicationSignature.packageSignatureStatus = 1
[2024-12-05:14:10:22] Package (ignoring) signature validation failed
[2024-12-05:14:10:22] Application signature verified
[2024-12-05:14:10:22] Platform conversion: input folder C:\Users\tormund\AppData\Local\Temp\fla33D1.tmp, captive true, command-line false
[2024-12-05:14:10:22] Platform Conversion (win32) - templates folder C:\AIRSDKs\Flex_4.16.1_AIR_51.1.3.1\runtimes\air\win\Adobe AIR\Versions\1.0\Resources
[2024-12-05:14:10:22] Starting conversion: copying C:\Users\tormund\AppData\Local\Temp\fla33D1.tmp to C:\Users\tormund\AppData\Local\Temp\fla345F.tmp

Additionally, "fla33D1.tmp" appears to be a complete directory, "fla345F.tmp" is empty. Looking at the "Properties" of that directory, the "Read-only" Attribute has a dashed checkbox. Despite that, the users/groups Permissions for Administrators all have "Allow" checked for each listed property (including "Write"), except for "Special permissions".

Could there nevertheless be a permissions issue writing to that temp directory?

[MMPGreg]

@ajwfrost I'm happy to continue our debugging here. Please let me know what we can do next.

[balaedit]

Hi,

I have been encountering an issue with the AIR SDK and Adobe Animate CC for an extended period. Below are the details of the problem:

1. Error Images:

• AIR SDK Manager:
  

• Image from Animate CC :
  

2. ADT log file :
Please find the attached ADT log file for further analysis: adt.log

3. Issue Description:
I am using a 64-bit operating system, and it seems that the error occurs only in this environment. However, when I use a virtual machine running 32-bit Windows (via VMware), I am able to publish (With Animate CC and command-line adt both) the project without any errors.

It appears that the issue might be related to the compatibility of the AIR SDK or Animate CC with the 64-bit operating system. I would appreciate any guidance or troubleshooting steps to resolve this issue.

Thank you for your assistance.

[ajwfrost]

The error is happening when we're updating the template .exe file to set up the file details, icon etc - the error code of 110 is a Windows error: The system cannot open the device or file specified.
Which is quite odd! We are seeing an increasing number of issues related to the bundling process, earlier ones seem more related to the copying of files, but if that had failed then it should have bailed earlier...

You're creating a bundle target of a 32-bit binary .. so I'm wondering what might happen if you are able to try the same for a 64-bit target binary? If you look in the log file you should be able to pick out the ADT command line and then run this from a command prompt, then just add "-arch x64" after the "-target bundle" part?

@MMPGreg would you be able to try this too? We're a bit behind in getting you an updated debug build for the issue you're facing but it would be a big clue if the failures happen on 64-bit Windows when packaging a 32-bit bundle, but if they worked when packaging a 64-bit bundle..

thanks

[MMPGreg]

@ajwfrost With the latest DLLs you provided still in my SDK, and adding the architecture flag set to 64 in my app descriptor XML, I experience the same 3012 error on captive runtime build.