FinalBuilder 8 on Windows 11 ARM

FinalBuilder Bugs
1

Version 8.0.0.3263 is the last version which will run without issues on Windows 11 ARM running on a MacBook M2 using Parallels.

Newer versions (3264 - 3310) won’t start. The following log is written in the Windows Event Log:

Faulting application name: FinalBuilder8.exe, version: 8.0.0.3310, time stamp: 0x654ab6fb
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0ed50138
Faulting process id: 0x0x1674
Faulting application start time: 0x0x1DA3A3B0D88EAD5
Faulting application path: C:\Program Files (x86)\FinalBuilder 8\FinalBuilder8.exe
Faulting module path: unknown
Report Id: b4a70852-cd4c-4533-be04-e59b59800416
Faulting package full name: 
Faulting package-relative application ID:
2

I am getting this exact same issue. I have built a new VM (parallels, latest on MacBook M1 Max) for Delphi 12 and can’t get FB to run at all. I assumed it was the registration request thing that is failing, but seeing this, I installed v .3067 which has been running fine on my D11 VM and that does work. Of course, I need the latest one to pick up the Delphi 12 compiler actions.

3

FinalBuilder is an x86 application, so on arm it’s running in an emulated environment. I have seen other applications crash on my m1 mbp on win11 arm/parallels with similar errors. We have had this issue before, but then it started working again on later builds and now it’s failing.

I suspect it’s the virtualization code we use to protect our licensing causing this, but at the end of the day it’s all valid x86 code and the fault imho lays with the mac’s x86 emulation.

We will try a few things and see if I can produce a build that works… but no guarantees as we’ll essentially be flying blind.

4

Can you do a diff between build 3263 and 3264?
Build 3263 works, build 3264 does not.

5

I’m happy to test anything out. Is there a way to make FB actually go to D12 even though the script says D11 ?

6

Build 3263 supports D12

7

It’s not as simple as doing a code diff, the problem is no in our code (which runs fine on intel/amd) - something in the compiled code is causing a problem with the x86 emulation on arm.

8

So it does, many thanks, I didn’t know that as it wasn’t an option on the version history page and it was 3310 that shows it as D12 (I guess as it’s the main release) but I found it. Looks like I may be stuck on that.

So what else may have changed between the two versions as 3263 works fine?

9

I am only guessing here, but my guess is the obfuscation tool we use to protect our licensing moves things around randomly and while it generates valid x86 code, the arm x86 emulation doesn’t like what it’s doing.

10

Oh, I see, so you could just re-build 3263 again and that one may not run either. At least I have something to play with now.

11

Now what is the solution? I just updated today and same problem. I have just extended my Software Assurance and would like to continue using FB in the current version!

12

We do not have a permanent solution for this. We build FinalBuilder as an x86 application, and it runs fine on x86 cpu’s. It may or may not run ok on arm cpu’s using the emulation provided. Emulation can change timing aspects of the cpu, and that can cause problems.

This build may or may not work (untested on arm) - it’s what is likely to be the next update to FinalBuilder.

https://downloads.finalbuilder.com/downloads/finalbuilder/800/FB800_3348.exe

13

Good news :grinning: - I found a way to get FinalBuilder working reliably on Windows 11 Pro arm (insiders on Dev channel) on an M1 Macbook pro with parallels desktop 19.1.1

The trick is to change the emulation settings to Strict execution

Screenshot 2024-05-09 105335
Screenshot 2024-05-09 1053351508×1270 188 KB

Whilst this does work well, I will say that this is still somewhat unsupported. Hopefully Embarcadero will come to the party one day with a Windows Arm compiler - then we will be able to produce native arm binaries.

1 Like
14

It works :smiley:

Thank you!!

1 Like