Failed to localize one or more elements in the EXE bootstrapper

[AdamOI]

Hi everyone,

as quoted in the title, we're facing an issue trying to build an installer package. Building the project has not been an issue before, but we now have to migrate a build machine from one automated build system to another causing a wide range of build environment changes.

Some information about the build environment:

• The build is triggered from a build agent via command line.
• Previously, the agent ran under a local (non-admin) user, but now it is run as the Windows internal Network Service.
• Previously, the build was done in a different folder than it is now. Both are on the same drive, no special permissions were applied to either. (One may have an antivirus exemption that the other does not though, this is still being investigated.)
• We're not actively using the shared Repository, but have granted full access to all users involved to the ProgramData folder, just in case.

While the failure originally occurred via command line build, it reproduces when building using the UI as well.

Build log:

Code: Select all

Checking builds status
Build required.

[ Release ]
Building package: 
D:\AgentWork\Test\<...>.exe
Prepare build
Detecting MSI incompatible resources
Preparing files
Creating CAB file(s)
Signing CAB file(s)
Creating MSI database
Writing Summary Information
Signing MSI
This file was signed with the certificate: <...>
Creating EXE file
Failed to localize one or more elements in the EXE bootstrapper. Make sure that [D:\AgentWork\Test\<...>.exe] is not being used by another process and the elements used by the bootstrapper can be accessed.
GetLastError() returned: Access is denied.
Error details
 
Build finished because an error was encountered.

Error details:

Code: Select all

Failed to localize one or more elements in the EXE bootstrapper. Make sure that [D:\AgentWork\Test\<...>.exe] is not being used by another process and the elements used by the bootstrapper can be accessed.
GetLastError() returned: Access is denied.

Advanced Installer 20.3 build f51955ff
*** Stack Trace (x86) ***

[0x75c3b702]  RaiseException()
[0x025b50aa]  -----
[0x01302508]  -----
[0x013018a5]  -----
[0x0130151d]  -----
[0x01231c7b]  -----
[0x012374c7]  -----
[0x010e7353]  -----
[0x010e7221]  -----
[0x0122ddbb]  -----
[0x013d68ab]  -----
[0x00e91a84]  -----
[0x00cb78df]  -----
[0x00afda44]  -----
[0x01c06788]  -----
[0x76f960be]  RtlAllocateHeap()
[0x75c0eaab]  FlsGetValue()
[0x025b78ad]  -----
[0x025b4590]  -----
[0x00b15d1e]  -----
[0x7561fcc9]  BaseThreadInitThunk()
[0x76fb82ae]  RtlGetAppContainerNamedObjectPath()
[0x76fb827e]  RtlGetAppContainerNamedObjectPath()
[0x00640000]  MODULE_BASE_ADDRESS

Are there any steps we can take to narrow down the source of the error? Any particular pitfalls to look out for?

I'm aware we're using an old version of Advanced Installer, but unfortunately cannot upgrade at this time for stability reasons. We have a Professional subscription and are under active maintenance, in case that makes a difference in terms of official support.

[AdamOI]

(One may have an antivirus exemption that the other does not though, this is still being investigated.)

As it turns out, this seems to have been the cause of the issue. After adding the same security exemption for the new folder hierarchy, the build succeeds as expected.

As a follow-up question, is there any way to diagnose these kinds of issues a little more efficiently, like enabling more verbose logging for the build process?

[Liviu]

Hello,

Thank you for the follow-up.

I am glad to hear that you were able to identify the cause and that adding the security exemption for the new folder hierarchy fixed the build issue.

Regarding diagnostics, the build output is currently the main log generated by Advanced Installer during the build process. If the message reports Access is denied, I would recommend checking the following:

• antivirus / endpoint protection logs;
• Windows Event Viewer entries around the time of the build;
• whether the generated EXE is locked or scanned by another process;
• whether the build agent account has full access to the output folder and temporary folders.

To check if the EXE is locked by another process, you can use Resource Monitor:

• Run resmon
• Go to the CPU tab
• Expand Associated Handles
• Search for the file mentioned in the build error or output folder path

You can also use Microsoft Sysinternals Handle tool. This should help identify if another process, such as an antivirus or security tool, is holding a handle to the generated EXE during the build.

Best regards,
Liviu