When my uxp plugin uses WASM, Photoshop 2025 crashes

Photoshop
, ,
1

System: Windows11 22631.4317
Photoshop: 26.0.0
UXP Developer Tools: 2.0.2.3

My code:
WebAssembly.instantiate(new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 4, 1, 96, 0, 0, 3, 2, 1, 0, 10, 30, 1, 28, 0, 65, 0, 253, 15, 253, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 253, 186, 1, 26, 11]))
// or WebAssembly.compile

Please note: ANY correct WASM will make Photoshop crashes directly.

I have tested and found that Photoshop 2024 does not have this problem at all.

And exception stack:
<crash exception=“EXCEPTION_ACCESS_VIOLATION” exceptionCode=“0xc0000005” instruction=“0x00007FFCE9A2D1E4”>
<backtrace crashedThread=“0”>
<thread index=“0”>
<stackStatement index=“0” address=“0x00007FFCE9A2D1E4” symbolname=“napi_unwrap”/>
<stackStatement index=“1” address=“0x00007FFCE942C644” symbolname=“napi_unwrap”/>
<stackStatement index=“2” address=“0x00007FFCE951E8A3” symbolname=“napi_unwrap”/>
<stackStatement index=“3” address=“0x00007FFCE951E6FA” symbolname=“napi_unwrap”/>
<stackStatement index=“4” address=“0x00007FFCE971A46F” symbolname=“napi_unwrap”/>
<stackStatement index=“5” address=“0x00007FFCE971DA3E” symbolname=“napi_unwrap”/>
<stackStatement index=“6” address=“0x00007FFCE9D565E5” symbolname=“napi_unwrap”/>
<stackStatement index=“7” address=“0x00007FFCE9D5CAC8” symbolname=“napi_unwrap”/>
<stackStatement index=“8” address=“0x00007FFCE94658D0” symbolname=“napi_unwrap”/>
<stackStatement index=“9” address=“0x00007FFCE9377FED” symbolname=“napi_unwrap”/>
<stackStatement index=“10” address=“0x00007FFCEB64553E” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“11” address=“0x00007FFCEB5CC891” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“12” address=“0x00007FFCEB5D1BEA” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“13” address=“0x00007FFCEB3FB31F” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“14” address=“0x00007FFCEB401583” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“15” address=“0x00007FFCEB4019D0” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“16” address=“0x00007FFCEB405BEA” symbolname=“torq::seal_napi::Context::protect”/>
<stackStatement index=“17” address=“0x00007FFDC5999333” symbolname=“recalloc”/>
<stackStatement index=“18” address=“0x00007FFDC7AE257D” symbolname=“BaseThreadInitThunk”/>
<stackStatement index=“19” address=“0x00007FFDC846AF08” symbolname=“RtlUserThreadStart”/>
</thread>

2

Could be related: Dependency: wasm instantiate error

3

As noted above, I have observed something similar to this, but at the risk of being pedantic, can I ask …is your title literal or not?

What I have observed to date is that when I attempt to compile web assembly then I get a crash on Photoshop 2025. But your post could be saying that even if I manage to compile a wasm module into a plugin on Photoshop 2024 then that plugin still wouldn’t run on Photoshop 2025, even though it has been successfully compiled on PS 2024.

4

I can now confirm that a (wasm) Plugin developed under Photoshop 2024 will not run under Photoshop 2025. Basically, 2025 is non-functional in regard to plugins utilising wasm. I have raised a bug report on this.

I doubt that any solution will come forward from this forum (I doubt there is a solution as such). So, it might be as well to close this thread and wait for the bug report to be resolved. If others experience this issue, it would be helpful if they could add their experience to the bug report in order to escalate its urgency.

1 Like
5

I now added the following to the bug report referenced above.

This bug report appears to be in limbo. I would appreciate it if an Adobe staff member could acknowledge the issue and confirm that this major regression is being prioritized for resolution.

Other bug reports have received responses along the lines of, “Thank you for the detailed description; I’ve shared it with the team for review,” or, “We’ve informed the team, and they’re looking into it.” This bug warrants a similar acknowledgment.

The existence of the bug is now well-documented. There is no available workaround, and it effectively halts the development path for WebAssembly plugins. This deserves attention sooner rather than later.

1 Like