Critical Issue: Photoshop 2025 Crashes When Using Web Assembly-Based Plugins

[terence21981657g3ek]

System Details:

• Operating System: Windows 10 Home, Version 22H2 (Build 19045.5131)
• Photoshop Version: 26.0.0
• UXP Developer Tools Version: 2.0.2.3
•  

I am writing to report a significant issue with Photoshop 2025 that renders it non-operative for WebAssembly-based plugin development. As a developer with newly acquired experience in Adobe UXP and significant investment in plugin creation, I must express my deep frustration regarding this problem.

Description of the Issue

I have developed a complex plugin where the core functional code is written in C++ and compiled to WebAssembly using Emscripten to run within the UXP environment. To verify the issue, I have also created a simplified plugin that reproduces the crash consistently.

While the (simple) plugin loads successfully in UXP Developer Tools, and the application panel appears as expected, clicking the "Process" button in Photoshop 2025 causes the application to crash. This issue is specific to Photoshop 2025, as the same plugin functions without any problems in Photoshop 2024.  If the plugin is developed and packaged under Photoshop 2024 then it still crashes when loaded and initiated under 2025.  

The details of the crash are included below for reference.

Impact

This issue has severe implications for WebAssembly-based plugin developers:

• After months of dedicated effort, I find myself unable to deliver a functional plugin for the latest version of Photoshop.
• The inability to support Photoshop 2025 undermines my ability to market the plugin effectively once development has been completed.
• This situation discourages innovation and development within the Adobe plugin ecosystem.

Supporting Evidence

This issue is corroborated by reports from another developer:

• Related discussion: UXP Plugin Crashes with WASM in Photoshop 2025
• Related technical problem I raised: Dependency Wasm.Instantiate Error

Crash Report Summary

The crash is identified as EXCEPTION_ACCESS_VIOLATION with exception code 0xc0000005. Key details from the crash report are listed, highlighting repeated instances of napi_unwrap in the stack trace, which appears to be a critical point of failure.

Request for Resolution

I urge Adobe to prioritize resolving this issue promptly. Developers like myself rely on Photoshop’s stability and forward compatibility to bring innovative solutions to the market.

Despite my frustration, I appreciate Adobe's commitment to supporting its developer community and hope this issue can be addressed swiftly to restore confidence in the platform.

Thank you for your attention to this matter.

Details of crash:

Adobe Photoshop has encountered a problem and needs to close.

Report;

<?xml version="1.0"?>

<!DOCTYPE AdobeCrashReport SYSTEM "AdobeCrashReporter.dtd">

<crashreport serviceVersion="16.7.0.202408221003_c7c60a5" clientVersion="16.7.0.202408221003_c7c60a5" applicationName="Adobe Photoshop" applicationVersion="26.0.0" build="20240927.r.26" source="Windows-Client" crashType="n/a">

<time year="2024" month="11" day="17" hour="15" minute="13" second="1" timeoffset="0" timezone="GMT Standard Time" crsessionduration="51"/>

<user guid="44e8e37a-d758-45f5-a0fe-adccb0fdad38"/>

<system platform="Windows 10 Home" osversion="10.0" osbuild="19045" applicationlanguage="en-us" userlanguage="en-GB" oslanguage="en-GB" ram="16249" machine="Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz" model="Intel64 Family 6 Model 165 Stepping 5" cpuCount="16" cpuType="8664" cpuFreq="2904 MHz" processorArchitecture="9"/>

<gpu>

<gpuinfo availability="Running/Full Power" adapterCompatibility="Intel Corporation" adapterRAM="1024 MB" caption="Intel(R) UHD Graphics 630" description="Intel(R) UHD Graphics 630" driverDate="20220114000000.000000-000" driverVersion="30.0.101.1273" videoModeDescription="1440 x 900 x 4294967296 colors" pnpDeviceID="PCI&#92;VEN_8086&#38;DEV_9BC5&#38;SUBSYS_D0001458&#38;REV_05&#92;3&#38;11583659&#38;0&#38;10" installedDisplayDrivers="igd10iumd64.dll,igd12umd64.dll,igdumdim64.dll"/>

</gpu>

<crash exception="EXCEPTION_ACCESS_VIOLATION" exceptionCode="0xc0000005" instruction="0x00007FFBE1D9D1E4">

<backtrace crashedThread="0">

<thread index="0">

<stackStatement index="0" address="0x00007FFBE1D9D1E4" symbolname="napi_unwrap"/>

<stackStatement index="1" address="0x00007FFBE179C644" symbolname="napi_unwrap"/>

<stackStatement index="2" address="0x00007FFBE188E8A3" symbolname="napi_unwrap"/>

<stackStatement index="3" address="0x00007FFBE188E6FA" symbolname="napi_unwrap"/>

<stackStatement index="4" address="0x00007FFBE1A8A46F" symbolname="napi_unwrap"/>

<stackStatement index="5" address="0x00007FFBE1A8DA3E" symbolname="napi_unwrap"/>

<stackStatement index="6" address="0x00007FFBE20C65E5" symbolname="napi_unwrap"/>

<stackStatement index="7" address="0x00007FFBE20CCAC8" symbolname="napi_unwrap"/>

<stackStatement index="8" address="0x00007FFBE17D58D0" symbolname="napi_unwrap"/>

<stackStatement index="9" address="0x00007FFBE16E7FED" symbolname="napi_unwrap"/>

<stackStatement index="10" address="0x00007FFBD81B553E" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="11" address="0x00007FFBD813C891" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="12" address="0x00007FFBD8141BEA" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="13" address="0x00007FFBD7F6B31F" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="14" address="0x00007FFBD7F71583" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="15" address="0x00007FFBD7F719D0" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="16" address="0x00007FFBD7F75BEA" symbolname="torq::seal_napi::Context::protect"/>

<stackStatement index="17" address="0x00007FFC2AA11BB2" symbolname="configthreadlocale"/>

<stackStatement index="18" address="0x00007FFC2B267374" symbolname="BaseThreadInitThunk"/>

<stackStatement index="19" address="0x00007FFC2D09CC91" symbolname="RtlUserThreadStart"/>

</thread>

</backtrace>

<registerSet>

<register name="RAX" value="0x000001C05B2A3550"/>

<register name="RBX" value="0x000002D13BE803E1"/>

<register name="RCX" value="0x0000000000000000"/>

<register name="RDX" value="0x000000469A18B2C9"/>

<register name="RSI" value="0x000000469A180000"/>

<register name="RDI" value="0x000000469A18B2D0"/>

<register name="RSP" value="0x00000003334FEFD0"/>

<register name="RBP" value="0x0000000000000001"/>

<register name="RIP" value="0x00007FFBE1D9D1E4"/>

<register name="EFL" value="0x0000000000010206"/>

<register name="LastExceptionToRip" value="0x0000000000000000"/>

<register name="LastExceptionFromRip" value="0x0000000000000000"/>

</registerSet>

<binaryImageSet>

[sttk3]

I wanted to test it, so compiled it in Emscripten and loaded it in UDT. It certainly does not crash on 2024 and does crash on 2025, but I am not sure if that is due to my inadequacies or Photoshop.

Because I am restoring the index.html myself by imagining the structure based on the contents of index.js, and generating the TestPlugin.wasm with Apple Silicon's mac.

1. Can you please attach index.html?
2. Do you have an image of what the plugin looks like when it loads correctly?
3. Is the TestPlugin.js expected to be available in Apple Silicon with what you have attached? Or should I use the one that Emscripten generates when it is compiled?

As far as I have tried, this is how it works.

2024:

The panel is displayed. When I press the button, it tries to load the wasm, but eventually fails with 'Aborted(Assertion failed: exported native function `malloc` not found)'

2025:

The panel is displayed. Photoshop crashes when I press the button.

[terence21981657g3ek]

Thank you for your response. 

Can I attach the index.html?  Well, the literal answer is no!  The message board will not me let attach an html file.  If I paste it into a .txt file it ‘says contents do not correspond to a text file’.

Fortunately, I can post its contents here….

*****Index.html Contents*****

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>WASM Photoshop Plugin</title>   

    <script src="index.js"></script>        //Valid alternative: <script type="module" src="index.js"></script>

</head>

<body>

    <h1>Adjust Brightness</h1>   

    <input type="number" id="brightnessInput" value="20" min="-255" max="255">

    <sp-button id="adjustBrightnessBtn" variant="cta">Apply</sp-button>

</body>

</html>

****End of Index.html Contents*****

This is an image of the plugin when it correctly loads and after clicking the ‘Apply’ button a number of times to the active image causing it to become brighter.

I have no experience of Apple Silicon but I assume that you should use the TestPlugin.js that Emscripten generates on your system.

In my case 2024 runs fully.  It gives no error messages nor does it abort.

For 2025: the panel is displayed, I can click the button and a crash occurs after an elapsed time.

I am interested that you twice get the ‘still waiting on dependencies’ messages.  I have this issue on Photoshop 2024 with the plugin that I am developing.  Despite the messages, it now runs to the end. If you or anyone else have any insights to this, please post them here.

 https://forums.creativeclouddeveloper.com/t/dependency-wasm-instantiate-error/8536/11

[sttk3]

Thanks for the additional information. I have successfully displayed the panel you provided.

However, the result is the same regarding the loading of the wasm. Whether I used your TestPlugin.js or the one generated in my environment, the end result was as reported above. The messages that appear in the console are different, to be exact.

In any case, it seems to be true that Photoshop 2025 crashes on wasm loading.

[terence21981657g3ek]

Photoshop 2025 has now been updated to version 26.1.  On occasions my simple plugin and my complex development plugin have run to compltion on this new version without any problems. However on most occcassions, they crash in the same way that they did on version 26.0.

[terence21981657g3ek]

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.

[Erin F.]

Hi @terence21981657g3ek, 

I got your various messages across this forum and the UXP forum. Thank you @sttk3 for testing this!

I've passed this along to the right people on the Photoshop and UXP teams. The Photoshop team typically takes crashers quite seriously.

I don't know how common Web Assembly is in UXP plugins for Photoshop.

[terence21981657g3ek]

Thank you.

Hopefully this issue will be fixed for version 26 by the time that I complete my development using version 25.

I don’t think Web Assembly is that common for UXP plugins. I suspect there may be a chicken and egg situation here. Once the path is clearly established more people will take it.  As one of the pioneers I will provide feedback and advice to others, if Adobe can support me along the way.  The Web Assembly path is important because it can provide cross platform functionality whereas hybrid plugins are platform specific.