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.

[erinferinferinf]

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.

[terence21981657g3ek]

Issue not resolved on new update (version 26.2).

[erinferinferinf]

Issue not resolved on new update (version 26.2).

By @terence21981657g3ek

Hi Terrence, 

I appreciate the time and effort you've put into developing your hybrid UXP plugin using WebAssembly (WASM).

I'd like to clarify that while there was a WASM sample in our official repository, but it was created by (effectively) a summer intern (technically an MLH Fellow) and was never officially supported or communicated as a stable feature. This sample was intended to showcase UXP's potential, but it has always been somewhat buggy, especially on ARM devices. (For example, I cancelled a blog post about it because I couldn't get the sample to run.)

Currently, our UXP team does not test or officially support WASM. It's possible that recent updates, such as the V8 upgrade, have further impacted the functionality of WASM plugins.

There is a roadmap item to investigate WASM support in the latter half of next year (H2 2025). However, until then, we cannot guarantee any fixes or improvements for WASM-based plugins.

We have heard of a developer in the community who has a WASM plugin running with Photoshop 2025, who said, in a loose quote here "new emscripten versions load differently". He hasn't gotten back to us.

We appreciate your understanding and patience.

[Michele1835]

Hi Erin,

I confirm that the issue mentioned by Terry is solved, and probably related to what the other developer mentioned but not because of emscripten (older version of emscripten doesn't make the difference, rather the new V8 engine or UXP  new security level implemented by Adobe in PS 2025), the issue appear to be the wasm async instantiation made by the js code of emscripten, disabling this feature, and providing manually the binary solve the problem. so flag

-sWASM_ASYNC_COMPILATION=0

and in the index.js

let wasmModule;
async function loadWasm() {
    return new Promise((resolve, reject) => {
        const script = document.createElement("script");
        script.src="TestPlugin.js";
        script.onload = async () => {
            try {
                const response = await fetch("TestPlugin.wasm");
                const wasmBinary = await response.arrayBuffer();

                // Initialize the Module with the wasmBinary
                const Module = {
                    wasmBinary: wasmBinary, // here the magic
                    onRuntimeInitialized: () => resolve(Module),
                };

                MyTestPlugin(Module);
            } catch (error) {
                reject(error);
            }
        };

        script.onerror = reject;
        document.head.appendChild(script);
    });
}

[terence21981657g3ek]

Thank you very much, Michele.  I have implemented the solution and I agree that, with the proposed amendments, the Web Assembly plugin now runs on Photoshop 2024 (V 25.12.1), on Photoshop 2025 (V 26.20) and on Photoshop Beta (V 26.30).

Just to clarify, the required amendments are as follows.

The command prompt input previously suggested, in the comments in the TestPlugin_cpp.txt (above), should now be augmented to include the sequence ….  -s WASM=1 -s WASM_ASYNC_COMPILATION=0 -s MODULARIZE=1 ……  In the index.js file (as derived from the file index_js.txt that I attached above), the function loadWasm should be amended to read as given by Michele.  (The line ‘name(Module)’  might require amendment to align with the command element  -s EXPORT_NAME="name".)

Thank you again Michele.

COMMENT: This solution may also be relevant to the issue 'UXP Plugin Crashes' with WASM in Photoshop 2025 referenced above. However, I am not able to post there.  The rules seem to be that one cannot post three entries in a row, instead one is expected to edit an existing post.  However, my existing posts have extended beyond the deadline where they are editable.  .... Stalemate!!

FURTHER COMMENT: On the Creative Cloud Developer Forum, under 'Wasm Instantiate Error', I mentioned that I have co-ordinated with another GitHub user to develop a web app which offers an improved implementation of Match Color and that he and I are working to now make this available as a Photoshop plugin together with other original processing methods.  That other GitHub user is Michele Renzullo who has posted above under the user name Michele1835.  His GitHub account offers additional insights into his understanding of this issue.