Krita Save Error: Files Unable to Save / Autosave

Hullo, first posting so hoping to be clear and concise.

I’ve used Krita for eight months now, saving, exporting and reloading just fine. My autosave intervals are 7 minutes, 2 backups, and I also occasionally manual-save via File > Save or keystroke ctrl+S. Today I encountered a problem I cannot solve:

At some point during work, Krita began failing to write to files. No visible errors were seen to indicate this problem, and even choosing File > Save raised nothing unusual. When I attempted to close the program, it cycled the ‘Waiting for Saving to complete…’ window for several minutes (a typical save for the file is 10 to 15 seconds). Upon force quitting the app and checking my file directory, I found there were no recent autosaves made and the last manual save (despite multiple manual saves for pauses) was four hours prior. The source file destination is a networked and active NAS directory with many terabytes of free space. Autosaves are saved in that same directory as source. Cache and temp files are saved on a local SATA HDD with 24GBs of free space. The last four hours of work was simply not saved or recorded as autosave files anywhere (%Temp% folders, cache, etc.), nor seen as anything findable via data recovery software. It’s as if Krita stopped attempting saves of any kind despite following through with messaging.

After some testing (and resisted wall-punching), I determined an error either with Krita, or my system’s other processes, randomly crashes the app or causes its saving to go unresponsive. Krita usage log displays many, MANY pages of attempts to autosave every ten seconds, as opposed to every seven minutes set in Preferences. And on occasions I attempt to manually save, it erroneously claims ‘cancelled by user’ before reporting complete. A snip below:

06 Apr 2023 21:57:03 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:03 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:13 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:13 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:23 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:24 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:33 -0400: Saving Document D:/Artwork/Mind Over Matter.kra as D:/Artwork/Tigerdile/Mind Over Matter.kra (mime: application/x-krita). 8000 * 8000 pixels, 33 layers. 101 frames, 24 framerate. Export configuration: No configuration
06 Apr 2023 21:57:33 -0400: Saving cancelled by the user.
06 Apr 2023 21:57:33 -0400: Saving Completed
06 Apr 2023 21:57:34 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:34 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra
06 Apr 2023 21:57:44 -0400: Autosaving: D:/Artwork/.Mind Over Matter.kra-autosave.kra

I was able to copy all layers to a new file, save and load that new file normally within the same session. But the original file refused to comply with any saves, autosaves, saves to different locations, saves as different names, and will not export as another filetype like Photoshop PSD. Reloads of the app didn’t solve the issue [edit: didn’t stop the issue from reoccurring]. If it helps I don’t know what size the final file size on disk was, but its dimensions were around two-dozen layers at 8,000 x 8,000 and 300dpi.

I’ve saved what crash and usage logs I could locate, and can provide them if necessary. I’d really like some insight into this phenomenon. It’s never happened in the eight months I’ve used Krita for my work and triggers a lot of uncertainty about the app.

Krita version: 5.0.6

My system specs:

|Processor| AMD Ryzen 9 3900X 12-Core Processor 3.80 GHz|
|Installed RAM| 32.0 GB|
GPU: nVIDIA GTX 1070Ti – Driver version: 516.94
|System type| 64-bit operating system, x64-based processor|
|Pen and touch| Pen and touch support with 10 touch points|

Storage: 120GB SSD 4TB External NAS HDD
Operating System: Windows 10 Home
Version 22H2
OS build 19045.2728
Experience Windows Feature Experience Pack 120.2212.4190.0

Thank you for your time and any support or insight.

~ N.

P.S.: I don’t know if it’s the same issue but the poster in this thread mentions issues that all check my issue’s tickboxes. https://krita-artists.org/t/cant-find-any-save/62253

Hello @Nikotaka and welcome to the forum :slight_smile:

This seems like a complicated situation so I hope that other users will be able to help to track it down, eventually.

Is there a reason why you’re still using krita version 5.0.6?
The latest version is 5.1.5 so could you try using that version?
I realise that this problem has recently started but if the problem is something to do with krita then any bugs or fixes can only be done relative to version 5.1.5.

Is this particular .kra file the only .kra file that shows this problem?
Have you tried editing and saving other previously used .kra files to see if they also encounter the problem?

Can you make the .kra file available via a link to a file download service/website so that someone else can try this on a Windows system?

What type/form exactly is your network storage device?
How is it mounted/interfaced to the Windows file system?

If you copy the ‘problem’ .kra file to your C:drive, e.g the Desktop, does it still show the same problem when editing and Saving with krita?

Hullo and thank you for the suggestions. :slight_smile:

Is there a reason why you’re still using krita version 5.0.6?

No other reason than neglected updates, honestly. Updating the program’s been on my list of matters, though as mentioned this is the first time over months of use that the issue’s been encountered. I can try for a repro under 5.1.5.

Is this particular .kra file the only .kra file that shows this problem?

That’s correct. I can try to make it available for testing purposes.

What type/form exactly is your network storage device? How is it mounted/interfaced to the Windows file system?

Synology Hybrid RAID (SHR) (With data protection for 1-drive fault tolerance). It’s accessed via ethernet on home network through one network switch.

If you copy the ‘problem’ .kra file to your C:drive, e.g the Desktop, does it still show the same problem when editing and Saving with krita?

Correct. I had this issue occur after saving a copy of my file to an internal SSD (the same SSD that I set temp and cache to save to), not involving the NAS at all. I’m uncertain what triggered it, but the same phenomenon of being unable to save transpired.
By then I had already tested copying the layers to a new work file and saving that one within the same session. The original file refused to save. Upon re-loading the application, the original file saved fine.

Come tomorrow (it’s now after 3am EDT) I’ll see about providing the file and seeing if it can be reproduced under Krita 5.1.5.

The aforementioned file:

Thank you for the .kra file @Nikotaka
With 5.1.5 installed on Windows 10, I have no problem opening, editing, Saving and Saving As with the .kra file with source and destination on my internal SSD (E:drive).
The RAM used is 2.6 GB which is a small amount for me and for you as well.

There is a bit of off-canvas content that looks as if it was created when you constructed borders or similar items but it’s not significant.
If you do want to remove it then Image → Trim to Image Size will do that.

All I can think of is some kind of glitch that made the internal image content ‘strange’ that was fixed after you reloaded/restarted the application.

Yeah, everything looks pretty mundane. I’ve been working on the file post-Krita update and it hasn’t shown any operational strangeness (It’s basically as it was when working in the past).

Outside of fully recreating the complex conditions I worked under–Streaming my work to a stream-hosting website using OBS, viewing the stream on a second monitor via Firefox–I’m not sure how to get it to reproduce. It only repeated itself in that specific environment the night of the report. Crash logs and dumps from the event are what I have remaining from that, which if requested can be supplied.

Beyond that, If it doesn’t happen again, well…I’ll be ecstatic. I can only hope the update to 5.1.5 did the trick. If it does however I’ll be sure to mention.

Unfortunately it seems I still have intermittent crash issues with Krita 5.1.5 that occur across different files in progress and on different days. I’m out of ideas on figuring out what the issue is as nothing seems consistent.

The Crash Log reports various ‘Access Violations’ and ‘Breakpoint’ errors.

Crashes are triggered by things as innocuous as using the Transform tool on a layer’s pixels, or beginning a pen stroke. System config hasn’t changed since the above posts.

If desired, the crash log in full is here down to April 20th (it omits my most recent crash which happened within the last hour): Dropbox - KritaCrashLog Apr2023.txt - Simplify your life

Some insight would be greatly appreciated. Thank you.

Summarising for those people who know what crash logs mean:

Access Violation at location 00007FFA82282B23 in module libkritalibbrush.dll Writing to location 0000000000000000

Access Violation at location 00007FFAA6C08D34 in module ucrtbase.dll Writing to location 0000000000000000

Breakpoint at location 00007FF95B2A5802 in module KERNELBASE.dll

Access Violation at location 00007FFFFB9C8D34 in module ucrtbase.dll Writing to location 0000000000000000

Access Violation at location 00007FFB6D808D34 in module ucrtbase.dll Writing to location 0000000000000000

Access Violation at location 00007FFB6D808D34 in module ucrtbase.dll Writing to location 0000000000000000

Did these crashes happen when you were not:

i.e. ‘Normal’ use with nothing fancy or complicated going on.

Hi again!
These crashes are in the same timeframe as using OBS and viewing using Firefox or Chrome, correct. However, today’s crash (prompting my post) was from normal Krita-only use, and did update the crash log in Krita after sending the earlier post : Dropbox - KritaCrashLog Apr2023 02.txt - Simplify your life

It’s still ucrtbase.dll, in case anyone knows about this sort of thing.

It looks like most of those crashes in the log happened when opening or creating a document, failing either in the tile manager (KisTileDataStore::duplicateTileData) or colorspace conversions (KoColorSpace::convertPixelsTo).
(The first crash in the log was when loading an ABR brush (in libkritalibbrush.dll), and the third one resizing a window (the breakpoint in KERNELBASE.dll).)