ERROR Application was not signed, an error occurred: The EXE file was not found: please first compile the workbook.

hi,
got an error when using Security - EXE Code Signing and click on "Sign EXE File Now"


and yes, the Excel VBA was compiled correctly before. The log file says:

[2026-07-09 16:24:35] ERROR Application was not signed, an error occurred: The EXE file was not found: please first compile the workbook.

Click to expand...

Click to expand...

Maybe its because some Microsoft .NET Files were updated?
And yes the output path is NOT opened in Explorer as other postings say that's no good idea...
thx

"Sign EXE File Now" only signs an .exe that already exists in your project's output folder. It does not build it. The message "The EXE file was not found: please first compile the workbook" means XLS Padlock did not find a compiled .exe there when you clicked Sign.

Two checks, in order:

1. Build the secure application first, then sign.
   The .exe is created only by the "Build Secure Application" button on the XLS Padlock ribbon. Compiling the VBA project inside Excel (Debug > Compile VBAProject) is a separate step and does not produce the .exe, so signing right after a VBA compile will report the EXE as missing. Click "Build Secure Application", let it finish, confirm the .exe is present in your output folder, then click "Sign EXE File Now".
2. If you did build and the .exe is still reported missing, a security tool is most likely removing it.
   A freshly built, not-yet-signed .exe is a frequent false positive. Microsoft Defender (or another antivirus) can quarantine or delete the output .exe the moment the build writes it, so when the signing step looks for it a second later it is already gone. Your hunch about a recent .NET/Windows update fits: updated Defender definitions can start flagging a build that was fine the day before.

• Open Windows Security, then Virus and threat protection, then Protection history, and look for a removed or quarantined item pointing at your .exe or its folder. Restore it if you find it.
• Add exclusions for your project's output folder and for XLSPadlockDesigner.exe.
• Rebuild, confirm the .exe stays in the folder, then sign.

To help pin it down, could you tell us:

• Does "Build Secure Application" finish without error, and does the .exe actually appear in the output folder (even briefly) before you sign?
• Which antivirus or security software is running, and is the output folder excluded from it?
• Your exact XLS Padlock version and build (Help, then About).

XLS Padlock Version 2026.0

So the steps I did in XLS Padlock were:

• click button "Build Secure Application"
• the exe appears in the output path
• I logged in Microsoft azure (az login), my certificate is active
• next I click button "Sign EXE File Now"
• the black cmd window appears two times but nothing more happens

But I got the MyApp.xlsm.xplcompil.log file
and there is i.e. one line saying

Microsoft.Identity.Client.Extensions.Msal.MsalCachePersistenceException: Persistence check failed. Inspect inner exception for details

Click to expand...

Whats wrong?
thx

Good news first: the earlier "EXE not found" is gone, your build now produces the .exe, so we are past that. What is failing now is the Azure signing step itself, and the line in your log is the key:

Microsoft.Identity.Client.Extensions.Msal.MsalCachePersistenceException: Persistence check failed

That exception does not come from XLS Padlock. It comes from Microsoft's Azure signing components: the Trusted Signing (Azure Artifact Signing) tooling uses Azure.Identity and MSAL, and on startup MSAL runs a self-test to confirm it can store its token cache on the machine. On Windows it encrypts that cache with DPAPI under your user profile. When the self-test fails it throws "Persistence check failed" and the signing call stops, which is exactly why the two cmd windows open and then nothing more happens, even though az login succeeded and your certificate is active.

We have not seen this one reported before, which points to something specific to this machine's Azure and MSAL environment rather than a general XLS Padlock problem. These are the things that cause it, most effective first:

• Run the signing in the exact same Windows user session where az login succeeded. Do not start XLS Padlock elevated (Run as administrator) or as a different user, and avoid doing it over a remote-desktop or service context. DPAPI ties the cache to the user profile, so a context mismatch fails the check.
• Make sure %LOCALAPPDATA% is a normal local, writable path, not redirected to a network share or into OneDrive. MSAL keeps its cache under %LOCALAPPDATA%.IdentityService.
• Clear the stale credential cache and re-authenticate: run az logout, then az login again. If it persists, close XLS Padlock, delete the folder %LOCALAPPDATA%.IdentityService, and sign once more so it is recreated cleanly.
• Confirm the machine has the current Microsoft Visual C++ Redistributable (x64) and the .NET runtime the Azure tooling needs. A missing runtime can make the Azure signing step fail quietly.

Separately, it is worth being on XLS Padlock 2026.1 (released today), which improves Azure Artifact Signing support in general. It does not target this specific MSAL cache error, so treat it as good housekeeping rather than the fix here.

To help us narrow it down:

• How did you set up signing in XLS Padlock: the built-in Azure Artifact Signing option, or a custom SignTool command line pointing at the Azure dlib and a metadata.json?
• Are you signing from an ordinary desktop session on your own account, or over remote desktop, from an elevated prompt, or a service account?
• Your Windows version, and whether this machine is managed by a company IT policy.