What causes “Compilation failed, code = -3” in PowerBuilder 2025?

It means the PBCC compiler process was terminated. Appeon documents three causes: antivirus software killing PBCC.exe, no permission to access the PBL directory, and running on an ARM CPU. Whitelist PBCC.exe in your antivirus and run the IDE as administrator; if neither applies, open a support ticket — Appeon has hot fixes for the -3 and -1 compile return codes.

Does the new solution format still support machine code?

No. The ultra-fast compiler supports P-code only, so you cannot build DLLs with it, and a project set to generate machine code is automatically switched to P-code when it is converted to the solution format. If you need machine code, keep the classic workspace format and the standard compiler.

Do I have to change every Long to LongPtr when moving to 64-bit?

No. Change Long or ULong to LongPtr where the value is a handle, a pointer, or a 64-bit parameter or return value — including a ref argument whose target is pointer-sized. Passing by reference widens the address automatically, but it does not change the declared datatype where the API expects a pointer-sized value. Structure size members keep their integer type; it is the value that changes (for example ToolInfo.cbSize goes from 40 to 64).

PowerBuilder 2025 Migration: Problems and Fixes

Q: Why is “Convert Workspace to Solution” greyed out?

Because the workspace is under version control — any version control, including Git and SVN. Appeon's documented procedure is to copy the whole workspace, remove version control from the copy, convert that copy to a solution, then add it back as a new branch or repository. In PowerBuilder 2025 R2 the source-control history is carried over automatically.

Most of a PowerBuilder 2025 upgrade is uneventful. The parts that aren't tend to announce themselves with one specific error message — and the fix is usually two lines long, once you know it. Below are the failures teams actually hit, in problem-and-fix form. Every fix here is checked against Appeon's own documentation or a resolved thread; where a cause is not confirmed, this page says so instead of guessing.

First: what actually changed in 2025

Two changes explain most of the new failure modes. PowerBuilder 2025 introduced the solution format and an ultra-fast compiler. In a solution, a library is no longer one opaque binary .pbl — it becomes a folder of individual plain-text source files, with compiled output kept separately. That is excellent for source control, and it is also why conversion, imports and version control behave differently than they used to.

The solution format stores each object as text in a per-library folder. That single change is behind the conversion, import and version-control issues below.

“Compilation failed, code = -3”

The most-reported failure when converting a workspace to a solution. The build stops and the output window shows:

[ERROR] Compilation failed, code = -3.
[Fatal] PBCC compiler process aborted due to an unexpected exception.

In the Windows event log it appears as a crash of pbcc.exe with exception code 0xc0000005.

Cause. The error means the PBCC compiler process was terminated. Appeon documents exactly three reasons — and the fix is whichever one applies:

The three causes Appeon documents for compile code -3. Work through them in this order — antivirus is by far the most common.

Still failing? Open an Appeon support ticket. Appeon engineering has developed hot fixes for both the -3 and -1 compile return codes, and they are issued through support rather than in the public build.

“Convert Workspace to Solution” is greyed out

Cause. The workspace is under version control. This is not specific to any one system — Git and SVN both trigger it.

Fix (PowerBuilder 2025).Copy the entire workspace, remove version control from the copy, convert that copy to a solution, then add it back to version control as a new branch or repository. Note the trade-off Appeon states plainly: the change logs are not carried over unless you rewrite the repository content yourself. Appeon's knowledge base (article 4732) documents a git mv / svn rename recipe that preserves history if you need it.

On 2025 R2 this is easier. Appeon added automatic history preservation: source-control history is carried over to the new branch when a workspace is converted to a solution. If you have the choice, do the conversion on 2025 R2.

Your machine-code build quietly became P-code

What happens.The ultra-fast compiler supports P-code only. Appeon's documentation is explicit: machine code is unsupported — you cannot build DLLs — and if the application project is set to generate machine code, it is automatically switched to P-code when the application is converted to the solution format.

What to do. If you ship machine-code DLLs, or you have performance-critical code that was compiled to machine code on purpose, stay on the classic workspace format and the standard compiler. Check this before converting — the switch happens as part of conversion, and P-code output is a different performance profile than what you tested.

PowerBuilder keeps asking for a full build after a maintenance release

Every time you open the target, you get:

The version you used to full build the target "<target>"
(25.0.0.3683) is different from the current IDE version
(25.0.0.3711). Do you want to full build it using the new
IDE version?

Cause. The build version stamped on the target no longer matches the IDE. The usual reason is an incomplete maintenance-release install — the runtime updated but the IDE executable did not.

Fix. Open Help → About. If the IDE version is older than the runtime version, the MR install did not complete — reinstall it. Then open the Application object in Edit Source and confirm appruntimeversion matches the current build; if it differs, you are prompted every time the object is opened.

The IDE crashes while importing objects

Reported when importing PFC 2025 .sru files into a migrated library. The IDE dies without a dialog; the event log shows:

Faulting application name: PB250.exe, version: 25.0.0.3711
Faulting module name: PBLIB.dll, version: 25.0.0.3711
Exception code: 0xc0000005

Workaround (confirmed to work). Do not import the .sru files from the ws_objects folder. Export the same objects out of the .PBL instead, and import those files — they import cleanly.

Honest caveat. The suspected cause is a file-encoding difference — ws_objects source is UTF-8 with BOM, while exported source is UTF-16 LE with BOM. Appeon confirmed that difference but could not reproduce the crash, so treat the encoding as a hypothesis, not an established cause. The workaround is what is proven.

“Error C0031: Syntax error” in Forward Declarations

pfemain.pbl(m_master).m_.Forward Declarations.183: Error C0031: Syntax error

One specific cause worth checking first. If the objects that fail have dashes in their names, the IDE option Allow Dashes in Identifiers (Options → Script) is switched off. With it off, PowerBuilder reads the dash as a subtraction operator and the declaration will not parse. Re-enable it before migrating or rebuilding — command-line builds honour the same setting.

C0031 is a generic syntax error, so dashes are a cause, not the cause. This one is worth checking first because it is invisible: the source looks identical, and every failing object shares the same naming trait.

A .NET DLL works in the IDE but fails once deployed

Could not load file or assembly '<assembly>, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=...'. Could not find or load
a specific file. (0x80131621)

Appeon's recommended first step. Install the .NET Desktop Runtime 8 in both x86 and x64 — the Desktop runtime specifically, not the plain .NET Runtime. Also confirm the DLL path was not hard-coded when the assembly was imported, so it deploys alongside the executable.

Flagged honestly: this is Appeon's recommendation on an open thread, not a confirmed fix. Worth checking alongside it: whether the assembly was built for a different architecture than the PowerBuilder target.

32-bit to 64-bit: the LongPtr rule, correctly

This is the single most misquoted rule in PowerBuilder migration, and getting it wrong produces crashes that look random. Blanket-replacing Long with LongPtr is not the answer.

Change the datatype only where the value is pointer-sized. Structure size members are the classic trap: the type stays, the number changes.

Two clarifications that contradict widely-repeated forum advice. Passing by reference does not exempt you — the compiler passes a 64-bit address automatically, but if the API expects a pointer-sized value at that address, the declared datatype still has to become LongPtr. And structure size members keep their integer type; what changes is the value you pass — ToolInfo.cbSize goes from 40 to 64, TrackMouseEvent.cbSize from 16 to 24, ShellExecuteInfo.cbSize from 60 to 112.

What was removed or frozen in 2025 and 2025 R2

Appeon separates these precisely, and the distinction matters: discontinued means removed from the product; obsolete means still usable but no longer eligible for support or enhancement.

Feature	Version	Status
Windows 10 as a supported OS	2025 R2	Discontinued
SnapDevelop (use Visual Studio or VS Code)	2025 R2	Discontinued
3D Graphs (DirectX SDK rendering)	2025 R2	Obsolete
PowerScript Migrator	2025	Discontinued
MSSCCI API (migrate to Git or SVN)	2025	Obsolete
.NET 6.0	2025	Obsolete
PBNative and SCC API	2025	Not supported in the solution format — the workspace format still uses them

That last row is the one people get wrong. PBNative is not removed from PowerBuilder — it is unavailable in the solution format. If your team depends on it, the workspace format continues to work; you just don't get the new compiler with it.

A sane order of operations

Decide compiler and format first. If you need machine code or PBNative, stay on the workspace format — that decision determines everything else.
Migrate the version before converting the format. Get the application building on 2025 in its existing workspace, then convert to a solution as a separate, revertible step.
Convert on 2025 R2 if you can — you keep your source-control history automatically.
Do the 64-bit switch on its own. Never combine a version upgrade, a format conversion and a bitness change in one pass; when something breaks you will not know which change caused it.
Keep the old workspace until you have shipped. Solution conversion is one-way.

Bottom line. Almost every failure above is a configuration or sequencing problem, not a broken application — and each has a short, documented answer. Budget the time for the order of operations rather than for heroics, and a 2025 migration is a routine project.

Verified against Appeon's PowerBuilder 2025 documentation and resolved community threads, August 2026. Behaviour can change between builds — confirm against the docs for yours.