Packaged Windows v1.55.1 loads external Python 3.14 and crashes in python314.dll

[charlesmumford-alt]

What are you trying to do?

Attempting to install and run OpenCut on Windows 10 Pro. The server stops running when Premiere Pro is opened.

Details:

Packaged Windows v1.55.1 loads external Python 3.14 and crashes in python314.dll

I am troubleshooting OpenCut 1.55.1 on Windows 10 with the Premiere Pro CEP panel, and I believe I have isolated the backend crash to OpenCut loading my system Python 3.14 runtime rather than remaining isolated to its bundled Python 3.13 runtime.


Environment

OpenCut: 1.55.1

Windows 10

Premiere Pro 2026: 26.2.2 (build 3)

OpenCut installation: C:\Program Files\OpenCut

Backend: C:\Program Files\OpenCut\server\OpenCut-Server.exe

Backend port: 127.0.0.1:5679



The important observation

When the packaged server starts, it reports:

Bundled FFmpeg: C:\Program Files\OpenCut\ffmpeg

System site-packages: added 2 paths from C:\Users\charl\AppData\Local\Programs\Python\Python314\python.EXE

OpenCut Backend Server v1.55.1
Listening on http://127.0.0.1:5679
PID: xxxx
Log file: C:\Users\charl.opencut\server.log
Press Ctrl+C to stop

The OpenCut installation itself contains a bundled Python 3.13 runtime:

C:\Program Files\OpenCut\server\_internal\python3.dll

C:\Program Files\OpenCut\server_internal\python313.dll

However, the server explicitly discovers the following external Python installation:

C:\Users\charl\AppData\Local\Programs\Python\Python314\python.exe

That installation reports:

Python 3.14.0

I have not intentionally configured OpenCut to use this Python installation.



Reproducing the crash

The backend successfully starts and listens on port 5679.

A request to / works normally and produces a normal OpenCut 404 response in the server log.

The CEP frontend, however, performs:

GET /health

I confirmed this by examining the installed CEP JavaScript.

When I manually request the same endpoint:

curl.exe -i http://127.0.0.1:5679/health

I get:

curl: (56) Recv failure: Connection was reset

The OpenCut backend process then terminates.

Interestingly, there is no /health request recorded in server.log, suggesting that the process is dying before the request reaches normal application-level logging.



Windows crash information

Windows Event Viewer reports Application Error 1000 for OpenCut-Server.exe.

I have reproduced this multiple times. Four consecutive crashes were recorded.

The important details are:

Faulting application name: OpenCut-Server.exe

Faulting application version: 0.0.0.0
Faulting module name: python314.DLL
Faulting module version: 3.14.150.1013
Exception code: 0xc0000005
Fault offset: 0x0000000000065a79

Faulting application path:
C:\Program Files\OpenCut\server\OpenCut-Server.exe

Faulting module path:
C:\Users\charl\AppData\Local\Programs\Python\Python314\python314.DLL

The exception code 0xc0000005 is an access violation.

The same fault offset has been reported in each crash.



This does not appear to be a missing Python installation

The OpenCut server directory contains:

python3.dll

python313.dll

but no python.exe.

My normal system Python is:

C:\Users\charl\AppData\Local\Programs\Python\Python314\python.exe

and Windows’ Application Error report specifically identifies:

python314.DLL

as the faulting module.

Thus it appears that the packaged executable is somehow loading the external Python 3.14 runtime.



Python 3.14 installation history

I also checked when Python 3.14 itself was installed.

The Python 3.14 Windows components have an installation date of:

October 10, 2025

Therefore, I am not claiming that OpenCut installed Python 3.14.

There is, however, an interesting secondary observation.

A substantial collection of packages in my existing Python 3.14 environment was installed/updated on September 7, 2026 at approximately 1:59 PM.  This is the same time I used the OpenCut installer on my system.

For example:

auto-editor             29.3.1

edge-tts 6.1.19
mediapipe 0.10.35
opencv-contrib-python 5.0.0.93
numpy 2.5.3
matplotlib 3.11.1
sounddevice 0.5.6
aiohttp 3.14.3

The associated .dist-info directories form a very tight installation cluster at that time.

I also found substantial activity in the pip HTTP cache during approximately 1:50–2:10 PM on September 7.

This is suggestive of a coordinated pip installation/update, but I have not established that OpenCut initiated it, so I do not want to make that claim without evidence.



Another potentially relevant warning

During startup OpenCut also reports:

Cannot load route manifest for workflow validation: [Errno 2] No such file or directory:

'C:\Program Files\OpenCut\server_internal\opencut_generated\route_manifest.json'

I searched the OpenCut installation and could not find route_manifest.json.

The _internal\opencut directory contains only the data directory.

The server nevertheless starts and listens successfully, so I don’t know whether this is expected behavior or a separate packaging problem.



Current hypothesis

At this point, the evidence seems to indicate:

1. The packaged OpenCut release contains an embedded Python 3.13 runtime.

2. OpenCut-Server.exe nevertheless discovers the system Python 3.14 installation.

3. OpenCut explicitly reports adding system site-packages from that Python 3.14 installation.

4. Windows identifies python314.DLL as the module that crashes.

5. The crash is a native 0xc0000005 access violation.

6. The crash is reproducible when /health is requested.

7. The process dies before the /health request appears in normal OpenCut logging.

8. The same fault offset occurs repeatedly.

9. OpenCut’s packaged Windows release is intended to include its own runtime, making the external Python discovery particularly interesting.

   Questions for the developers

   Could someone confirm:

   Is it expected for the packaged Windows release to discover and load the user’s system Python/site-packages?

   What code is responsible for the message:

   System site-packages: added 2 paths from ...\Python314\python.EXE

   Is Python 3.14 known to be incompatible with OpenCut 1.55.1?

   Should the packaged OpenCut-Server.exe be completely isolated from the system Python installation?

   Could the external Python 3.14 runtime explain the python314.DLL access violation?

   Is the missing _generated\route_manifest.json expected in the v1.55.1 Windows package?

   Is there a recommended way to force the packaged server to use its bundled Python 3.13 runtime?

   I have deliberately not uninstalled or modified my Python 3.14 installation, because I use it for other applications and would prefer to establish the cause before changing the system environment.

   Further info:

I examined:

C:\Users\charl\AppData\Roaming\Adobe\CEP\extensions\com.opencut.panel\host\index.jsx

That JavaScript file contains the logic that constructs and executes a temporary Windows .bat file to start the backend.

The important finding from that test was:

I altered the startup behavior so that the backend could be launched directly rather than relying on the normal CEP startup path.
OpenCut Server then successfully launched and listened on 127.0.0.1:5679.
It printed the normal startup messages, including:
OpenCut Backend Server v1.55.1
Listening on http://127.0.0.1:5679
the bundled FFmpeg path
and, importantly, System site-packages: added 2 paths from ...Python314\python.EXE
So that test established that the executable itself can start successfully; the failure occurs afterward, when the server actually handles particular requests such as /health.

What have you tried?

No response

Version and platform

1.55.1 on Windows 10 Pro

[charlesmumford-alt]

I have additional context:

OpenCut 1.55.1 packaged Windows server crashes when Python 3.14 is discoverable


Summary

I have now reproduced the problem with a completely fresh OpenCut 1.55.1 installation and isolated the failure to whether my existing system Python 3.14 installation is discoverable.

The same freshly installed OpenCut server:

works correctly when Python 3.14 is temporarily hidden

detects and incorporates Python 3.14 when it is restored

then crashes when /health is requested

No OpenCut optional tools or Whisper components were selected during the clean installation.

This appears to be a runtime-isolation problem in the packaged Windows server.



Environment

Windows 10

OpenCut 1.55.1

Premiere Pro 2026 v26.2.2

System Python: Python 3.14.0

OpenCut installed at: C:\Program Files\OpenCut

Bundled OpenCut Python runtime: python313.dll

System Python: C:\Users\charl\AppData\Local\Programs\Python\Python314\python.exe



Initial behavior

With my normal Python 3.14 installation visible, OpenCut 1.55.1 starts with:

Bundled FFmpeg: C:\Program Files\OpenCut\ffmpeg

System site-packages: added 2 paths from C:\Users\charl\AppData\Local\Programs\Python\Python314\python.EXE

OpenCut Backend Server v1.55.1
Listening on http://127.0.0.1:5679
...

The server initially listens successfully, but requesting:

http://127.0.0.1:5679/health

produces:

curl: (56) Recv failure: Connection was reset

and the OpenCut-Server process terminates.

Windows Event Viewer records Application Error 1000:

Faulting application name: OpenCut-Server.exe

Faulting module name: python314.DLL
Exception code: 0xc0000005
Faulting application path:
C:\Program Files\OpenCut\server\OpenCut-Server.exe
Faulting module path:
C:\Users\charl\AppData\Local\Programs\Python\Python314\python314.DLL

This happened repeatedly.



Controlled clean-install test

I created a System Restore point, uninstalled OpenCut completely, and renamed:

C:\Users\charl\AppData\Local\Programs\Python\Python314

to:

C:\Users\charl\AppData\Local\Programs\Python\zPython314

I then rebooted and performed a fresh OpenCut 1.55.1 installation.

During installation I explicitly left:

Optional tools: unchecked

Whisper: unchecked

The fresh installation contained the expected bundled runtime:

C:\Program Files\OpenCut\server\_internal\python3.dll

C:\Program Files\OpenCut\server_internal\python313.dll

It also contained its own bundled NumPy:

numpy 2.4.6

The missing:

C:\Program Files\OpenCut\server\_internal\opencut\_generated\route_manifest.json

was still absent, but this does not appear to prevent the server from functioning.


Python 3.14 hidden

With Python 3.14 renamed/hidden, the fresh OpenCut server reported:

Bundled FFmpeg: C:\Program Files\OpenCut\ffmpeg

Added ~/.opencut/packages to sys.path (fallback)

OpenCut Backend Server v1.55.1
Listening on http://127.0.0.1:5679
...

The server identified itself as:

Server: Werkzeug/3.1.8 Python/3.13.15

I then ran:

curl.exe -i http://127.0.0.1:5679/health

and received:

HTTP/1.1 200 OK

...
"status":"ok","version":"1.55.1"

The server remained running after the request.



Python 3.14 restored

I restored the directory to:

C:\Users\charl\AppData\Local\Programs\Python\Python314

and verified:

Python 3.14.0

was again available to Windows.

Without changing or reinstalling OpenCut, I launched the same freshly installed OpenCut server.

It immediately changed its startup behavior to:

Bundled FFmpeg: C:\Program Files\OpenCut\ffmpeg

System site-packages: added 2 paths from C:\Users\charl\AppData\Local\Programs\Python\Python314\python.EXE

OpenCut Backend Server v1.55.1
Listening on http://127.0.0.1:5679
...

The server initially remained alive.

I then ran:

curl.exe -i http://127.0.0.1:5679/health

and received:

curl: (56) Recv failure: Connection was reset

Immediately afterward, the OpenCut-Server process was gone and port 5679 was no longer listening.




Controlled comparison

This is the resulting A/B test:

Configuration

Startup runtime behavior
/health
Fresh OpenCut + Python 3.14 hidden
Bundled Python 3.13.15; fallback ~/.opencut/packages
200 OK; server remains running
Same fresh OpenCut + Python 3.14 visible
Adds 2 system site-package paths from Python 3.14
Connection reset; server terminates
The only deliberate change between these two tests was whether the existing Python 3.14 installation was discoverable.

[charlesmumford-alt]

Workaround - uninstall OpenCut and all associated files, hide Python 3.14 by renaming folder, install Python 3.13.15, reinstall OpenCut.

However... there is a new problem, which deserves its own discussion.