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

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:

There have been previous reports of memory increases on small projects that have been solved by changing the Display Method. What are you using?(Menu item SettingsDisplay Method)

I am using “DirectX (ANGLE)” on Windows 11, if you have a different setting setting, try that. Another one to try is “OpenGL”.

Thanks! I poked around in Regedit and found a few obvious references to Shotcut - some of which were easy to understand and some were incomprehensible numbers. I’ll look through the link you posted tomorrow.

Don’t forget to try changing the Display Mode.

Thanks! My Display Method defaults to DirectX, which is what I’ve always used historically and never seen any particular problem with. My video card has 8GB of memory and can handle DirectX-12 if need be. I tried switching the Display Method to OpenGL a few days ago with no effect. I don’t have any preview scaling enabled at all

A few days ago I upgraded to the latest 22H2 version of Windows 11 and tried the Pixabay file again. Again, no problems at all. I really don’t know what else to suggest.

I looked at the Shotcut settings in the Windows registry and from the variable description given above, I see that the “appdatadir” is set to the Shotcut working folder which (again from the variable description document) means that all the other variables are being set from the INI file there, not from the registry. Not sure this is correct though, because I don’t see the “savePath” variable set anywhere in the INI file, and Shotcut is remembering it and getting it from somewhere… Anyway, here is my Shotcut.ini file, which I don’t see anything wrong with:

recent=B:/Screen_Capture_Videos/2022-11-16_01-10-43.mp4, B:/Screen_Capture_Videos/2022-05-06_00-27-36.mp4, B:/Screen_Capture_Videos/2022-05-06_00-34-09.mp4, D:/Downloads/Colours - 26493.mp4

hardware=hevc_amf, hevc_nvenc, hevc_qsv



Here’s what’s in the registry too (the sub categories just have a few simple preference settings in them, not that interesting):

All of the variables listed in the description document seem pretty harmless, as far as telling Shotcut to go nuts or something. Most of them aren’t even set in the INI file at all, and I don’t see any variables that would keep track of running output jobs - something that it does keep track of, but where?

Well, I haven’t really thought of anything else to try… I tried turning off the anti-virus again, after removing Spybot S&D completely - but still the same problem.

The only good news is that I’m getting better at all the weird keystrokes needed to do basic editing with Davinci Resolve (DR), which like OpenShot is able to successfully import and process any input source videos that I have. DR has one unusual rendering setting that tells it not to re-render a clip if it “doesn’t need to” (i.e. the output resolution and frame rate is the same as the input’s I presume) - and that saves a bunch of time to create the output file! I created an edited down 12 minute video in just over 4 minutes, while only using about 15% of the CPU resources, instead of the nearly 1:1 ratio with the video’s length that I can often see. Interesting and useful setting!

Anyway, it seems unlikely that any future version of Shotcut will be able to fix my problem, given that it can’t be duplicated by any of you at all. I know everyone probably thinks my system is weird, broken, or running some odd-ball stuff to make Shotcut behave this way, but everything else I run - even stuff like Cygwin, OBS Studio, more games than I can count, web and ftp servers, VirtualBox, and iSpy universally work perfectly. What ever is going on to make Shotcut fall into a black hole, I still have no clue.

Thanks everyone, for your help and good ideas to diagnose and correct this issue!. I’ll be waiting for a miracle to fix this I guess! -:slight_smile: