Shotcut UI locks up and memory consumption goes nuts under Windows 11

This is continued from “Is Shotcut broken now?”, which would not let me post after the author found his solution… Shotcut used to work perfectly under Windows 10, but now is pretty much unusable with Windows 11 (Pro) - locking up the UI and consuming memory without any seeming limit when even small MP4 files are imported. Please see the referenced thread for more details of everything looked at and tried so far.

I looked into my OneDrive settings and found that the automatic “upgrade” from Windows 10 to 11 seemed to have removed the OneDrive app from the system (although it left a local “OneDrive” folder behind with a few files in it).

I reinstalled the OneDrive app from their store, mostly so I could make sure it didn’t have any automatic synchronizations enabled that it may have been trying to do. Although i could then bring up the OneDrive UI, the Windows settings button for “Set up (OneDrive) syncing” didn’t do anything (no response to pushing it at all). I reported this presumed bug to Microsoft’s feedback mechanism, so hell will probably freeze over before anything gets done to correct it…

I tried running Shotcut again, after the OneDrive app (and presumably the underlying service) were reinstalled - with the same results, a totally frozen UI and out of control memory consumption. Attached is a memory performance graph which shows the growth once Shotcut started importing a small 119MB MP4 clip, a steady climb in memory usage starting a minute or so later, and then the memory dropping back to zilch after I killed Shotcut from the task manager.

I also looked at the Shotcut application log (that I recently figured out how to find) and saw nothing abnormal looking even at the bottom which is included below:

(Sorry, log file could not be inserted, due to forum restrictions - only 2 links per post)

The only funny thing I saw a few times in the log file were the “Leap Motion” error messages. I looked in Shotcut’s settings and didn’t see anything that mentioned “Leap Motion” or network stuff at all - so have no idea what that’s about…

The mystery continues for me at least.

Those will reveal a lot more than the built in task manager and standard monitoring utilities if you;re willing to give them a shot (you will need to do some reading to understand how they work).

Thanks, I’ll take a look!

Do you get the same performance if files are on your C drive?

I know you posted extensively on the other thread. Have you ever tried testing Shotcut without any Anti-Virus programs running?

I’m willing to test a clip and follow your same filter and export settings, but in my opinion, we would have a world of difference because I am not running any anti-virus programs. Nor am I running One-Drive.

But for the sake of science, pick a clip from here: Create a project file from that 1 clip and upload your MLT file here, so I and possibly others will test the same exact settings. You will need to share your export settings in text.

Thanks - great idea!

I downloaded two test files from Pixbay - a short 15 second video and a longer 1:15 video. I then watched Shotcut try to import both of them using the sysinternals Process Explorer that PoisonedSlice suggested above. Both test videos were at 1920x1080 resolution.

The first test video was named: "“Woman - 58142.mp4"”.(12.5MB)

The second test video was named: "“Colours - 26493.mp4"” (56.5MB):.
(The mechanics of this forum gets upset if I try to post actual links, but you should be able to find them by searching for these names).

The first, 15 second long video was imported into Shotcut quickly and perfectly, with the UI not locking or hanging up at all. I watched it with the Process Explorer for about 10 minutes after it had loaded, since in some of the failure cases I have seen previously the memory consumption would start skyrocketing 2 or 3 minutes after the import process was started (but before the Shotcut UI had shown the video loaded at all). Here is what the performance graph looked like:

(The forum limitations wouldn’t let me upload a second screen shot of the detailed performance numbers).

You can see the small amount of I/O show up in the graph when it is presumably actually reading the imported video in.

I then started to repeat the same test and measurements with the second test video. It totally locked up the Shotcut UI and as I had seen before began consuming memory hand over fist. It got up to grabbing about 45GB of memory before it crashed Windows - so I wasn’t able to get the same screen shot images of the Process Explorer output.

I have two anti-virus like products running: “Norton’s anti-virus” and “Spybot Search and Destroy” (which i didn’t even know was running as a background service. It seems to be integrating itself into the Windows Security Center app).

Because Norton has sort of dummied-down the UI for their anti-virus, I haven’t really been able to figure out exactly how to tell it to turn itself off - as they used to have a simple interface for doing. Likewise, Spybot S&D doesn’t have anything I can see from its UI to do that either, other than halting the services that I see it running (simpler to find that all the separate ones that Norton seems to have going on). I’ll try that and report back - and continue to look for a simple way to turn Norton’s anti-virus off for a while to re-try Shotcut again.

I’d expect that you’ll probably be able to import and process both of the test videos above just fine. Please note, I’ve never seen any problem with Shotcut rendering an output export job - just it going nuts when it tried to import anything bigger than very, very short video clips.

Thanks again all for your thoughts and assistance!

I trued stopping the Spybot S&D scanning service and the updating service, but Windows wouldn’t let me stop the integration service - that integrates it into the Windows Security Center app.

With those services stopped, the “Colours.mp4” test video above still started to consume memory like crazy when I had Shotcut try to import it. After a few seconds, I killed the process as it reached 4GB of memory being grabbed…So Spybot S&D isn’t the culprit it would seem.

Back to seeing what i can do to stop Norton’s anti-virus and rerun the test…

O.K., I temporarily turned off Norton anti-virus’s “auto protect”, which they say is how you disable it, and re-ran the test with the “Colours.mp4” test video. Got some mixed results.

The first time I did it, Shotcut loaded the video successfully after about 15 seconds, ehich while it was longer than it normally should have taken, at least it did it successfully without going into the memory consumption loop.

I then created a new project and tried importing the same video again. This second time, it did not complete successfully and started grabbing memory like crazy after a minute or so - until I quickly killed it.

I then verified that Norton’s control panel still thought that its auto-protection was turned off - which it was.

So sort of inconclusive even though it did allow the small, 56.5MB video file to be imported successfully the first time. I’ll mess with it some more tomorrow and try looking at it with some of the other Sysinternals tools too, to understand more about the behavior when it is failing to import.

I just downloaded the larger file ( opened Shotcut (it was then using around 300MB of memory), opened the file in Shotcut, which never used more than 580MB of memory, with no problems at all.

I’m using Shotcut 22.10.25 on Windows 11. The specs of the laptop on which I ran it are:

I was running several other apps at the same time, including a 1GB footprint Google Chrome with 40 tabs.

I presume you downloaded the officially supported Shotcut from the webpage here: Shotcut - Download

Have you tried re-installing it with the option to remove registry entries selected?

Thanks for your testing! I’m using the same version of Shotcut (22.10.25), which I have re-installed several times - even after totally de-installing and removing it from the system completely. For some of these re-installs I had it purge the saved settings as well, which I presume may be included in the registry…

Even when Shotcut’s UI is totally locked up and it’s consuming memory, all of the other services and programs on my system are continuing to run perfectly as expected. Not so very recently, with the Shotcut memory consumption actually crashing Windows, but before that - when Shotcut would hang (and gobble up a ton of memory, way more than it would ever need to contain the imported video), everything else on the system continued to run normally as well.

The paging configuration of my system is pretty beefy, with system managed size paging files across all 4 of my hard disk drives. These don’t seem to have a lot of I/O activity on them even when Shotcut is obviously in some sort of memory consumption loop. I expect that the reason that Windows is crashing when Shotcut tries to import some of the recent video files is just that what it is asking for is exceeding all the space that “the system” had allocated for paging space across all my drives. (I don’t have any idea how “the system” figures out how much space to allocate on each drive, or what logic it has for expanding it - if it does - as needed).

One thing which seems odd to me is that after I import a file in Shotcut, I quickly see the I/O spike as it reads the file itself in - and then a minute or two later the memory consumption loop begins. Unclear why very small input files sometimes don’t trigger this, but then files like the still pretty small 56MB test file used above do Historically I’ve used Shotcut to successfully process 15 and 20 gigabyte input files with no sweat.

I tried to post the end of the Shotcut log file the other day, but the forum mechanism wouldn’t let me do it because it had too many “links” imbedded in it - even though it was cut and pasted from what appeared to be a simple TXT file. It wasn’t very informative to me, but I’ll see if I can remove the “links” and post it here again.

You can upload the file (the little bar with an up-arrow above here).

Here is the bottom of the Shotcut log file, after attempting to import the “Colours.mp4” input file:

Sample=shotcut-log.txt|attachment (2.7 KB)

In the text file you uploaded, it shows you’re using a 1080p, 60fps Video Mode.
I also see that your files are on a HDD.

I used the Colours - 26493.mp4 file. The file is 1080p, 25fps.

For my test, I used the 1080p, 25fps Video Mode.
Used a 7500rpm HDD.

Shotcut open, no files loaded.

Exporting default. Watching a stream, multiple programs open.

32gb Memory
4.3 GHz CPU (water cooled)
Windows 10 Home
Windows Defender is active with Shotcut’s folder whitelisted.
No other antivirus
Windows and Shotcut are installed on an SSD drive.
Shotcut 22.10.25

Not able to duplicate memory issues as outlined in the 1st post.

Based on the following:

I’m assuming you’re doing a clean boot with all startup items disabled before testing any of this?

I’d be disabling Microsoft teams and a bunch of other cr*p too.

At last - Eureka!

I “uninstalled” to removed Shotcut from the system. verified that its install directory was totally gone, manually removed the contents of the app data directory, and then re-installed it with the option to clear all its configuration settings in the Windows registry. I’d done most of these steps several times before, but I’m not sure I did all of them at once, exactly like this.

Anyway, bang - now it works perfectly once again! Not dead sure why though, as the app data directory didn’t have much in it except for some really basic configuration stuff (the SQL DB was empty) and the log file, and the registry entries should have just had more configuration information from the description in the installer. (I would have thought that the “uninstall” process should have removed the registry entries too, but apparently it didn’t).

It’ll be nice to be able to use Shotcut once again, as I really like its interface for editing much better than the other editors I did some testing with!

Thank you all for your numerous suggestions and assistance in working through this and figuring it out! While I still have no clue what was actually going on, the fact that it’s fixed is all that matters!


Congrats, and well done. I bet that feels good!
My bad for not pointing you to this post, which is my go-to for “complete uninstall”.

Glad you got it sorted and reported how you did that. This may help others in similar situaltions.

And just like that, it’s broken again…

After running Shotcut successfully, without issue last night (after cleanly re-installing it), when I tried to use it again this morning on my test input file - it was back to the same old problem! After attempting to import the small MP4 input file, the UI hung, and a minute or so later the Shotcut process once again started consuming memory hand over fist. I killed the process when it was passing 8GB of memory usage for the 56MB input file…

Not clear what could have “broken it” from last night to this morning. About the only desktop apps I had run were the web browser, standard Windows e-mail client, and Destiny 2 (off EPIC). All the normal background services were constantly running of course which included: Abyss web server, Bonic, CoreTemp, CrashPlan online backup, Discord’s background service, Filezilla FTP server, iSpy security camera hub, Telegram, and Zoom’s background service. All of these have been running for years, successfully co-existing with Shotcut for all of that time. None of the messaging apps that Microsoft packaged in Windows 11 were enabled or running.

So as a quick fix, I simply re-installed Shotcut again - this time over top of the same install directory - again having it clear all the registry entries. I also manually removed all the stuff in Shotcut’s working directory - noting that this time the SQL DB actually contained some data, which it had not when I went through this last night.

Upon restarting Shotcut again, I changed it’s temp working directory from its default location on the C-drive and after it restarted itself again noticed that the SQL DB again had something in it - so I manually erased it again.

After all that, yep - Shotcut was able to import the test file just fine, taking a second or two to do it with the UI responding normally as soon as it was done. Now the question is, for how long will this keep working?

It’ll be sort of painful if I’ll have to re-install Shotcut every time I want to use it and begs the question - what is in the Shotcut registry entries and where exactly are these hidden in the registry? I haven’t played around enough with the Sysinternals utilities enough yet to figure out how to get it to show me…

I can’t really imagine that any other app would be messing with the Shotcut registry entries, or how corrupting them could or should cause the hung UI and wild memory consumption effects.

Does anyone know of any way to turn on more detailed debug entries in the Shotcut log file? Really curious about what it thinks it’s doing when it’s grabbing half a gigabyte of memory every second or so.

Also, does anyone know where it stashes its entries in the Windows registry and exactly what type of information it is keeping there? The installer implies that it is configuration information, but that also seems to be some of what’s in the working directory too.

Back to square one!

Forgot to mention, when I had test Shotcut last night I did restart it, and it still seemed to work o.k. afterwards.

I just tried to import another tested video into the same instance of Shotcut that I’d just re-installed, and it went into the weeds again, wildly grabbing a gigabyte of memory a second for a small 150MB input file after it had been “thinking about it” with the UI hung for a couple of minutes. Once again, what’s going on here?

Just did another test sequence - repeatedly importing the same two test input files (one after the other) after hitting “new” from the File pull down menu first. Worked perfectly a dozen or so times in a row.

However, when I exited Shotcut, restarted it, and then hit “File->New” before trying to load one of the test files, it immediately went down in flames again.

The more I look at this, the more confused I get about what’s going on! :crazy_face:

Sorry to hear your problem is back. The Windows Registry entries (and their location) are described here: