Build 14.3.0 crashing on Export
Using the new Export dialog in Build 14.3.0, Capture One is crashing frequently for me - sometimes it happens after doing a single export... other times I've been able to do an export, go back and do some more editing, and then it'll crash on the next attempt to export... or the attempt after that. There doesn't seem to be a consistent pattern other than after some number of exports the program will freeze, or crash completely and shut itself down.
I've tried enabling/disabling hardware acceleration... no difference. I've tried using the default workspace rather than my customized dual-monitor workspace... no difference.
When the program freezes, I open Task Manager and I can watch the memory usage climb rapidly until all of my RAM is consumed (I have 32 GB).
The old Output tool (the previous version, before the new Export dialog arrived in 14.3.0) never gave me any trouble at all... so the issue strongly points toward the new Export dialog as the culprit.
Is anyone else experiencing multiple crashes with 14.3.0?
Mike
-
Hello Mike,
yes, i have the same problems.Good to know that ist also happen to others. I thought it has to do with my computer.
Everything was fine with Version 14.2.0.
Greetings Robert
0 -
Thanks Robert - I thought the odds were pretty low that I'd be the only one experiencing this problem.
Since the original post I updated my GPU drivers, which seemingly forced Capture One to go through the "Setting Up Hardware Acceleration" procedure once again. It is yet to be seen if this eliminates the crashing issue.
I've also noticed that when I click on "Export" to load the new export dialog, the tools shown down the left side of the dialog (Location, Naming, Format & Size, etc.) seem slow to load. If I then look at Task Manager, I see that Capture One's CPU utilization has jumped to 15% simply by opening the Export dialog and it remains that high until I close it again, where it returns to normal (about 1.5%). In other words, simply opening the Export dialog and leaving it open (while doing nothing else) causes a 10x increase in CPU utilization.
I'm going to try a few more experiments with 14.3.0, if the crashing persists I'm just going to roll back to 14.2.0 and be done with it.
0 -
A quick update: 14.3.0 is still regularly crashing after the GPU driver update.
I give up, I've rolled back to 14.2.0 and exporting (i.e., using the "old" output tool) works properly again.
0 -
Hi Michael,
yes, with me the CPU shoots up massively as soon as I click on the export button. It often happens that the window disappears after 1 second. Or the program freezes for several seconds. I then have to force Capture One to exit using the Task Manager. Very frustrating ...0 -
I also have problems with the export function. The export of all my Leica DNG formats into a normal jpg ends with the attached result. The export of jpg's or tiff's is working properly. Greetings Frieder
0 -
v14.3.0 is seemingly misusing Windows virtual memory (paging file).
FWIW *NOTHING* else crashes on my workstation ...except C1 v14.3.0:-!
My most stable workaround includes:
* paging file drastically reduced/ and limited to min 16MB & max 64MB (everything else copes)
* before exporting change cursor focus to another image then return to the image you actually want to export
* removing the 'scheduling' feature of Hardware Acceleration ...use of HA itself seems OK (preview and display)
* (nVidia) use of GPU acceleration is unavoidable (may even help CrashOne to cope with its v14.3.0)
* restarting CrashOne frequently - resource leak over time?I returned to my 'idle' workstation to find the video card's fan screaming, CPU (water) cooler working overtime, CPU utilisation high and actual MEM max'd out ...doing NOTHING. CrashOne was hung and had to be crash exited.
PhaseOne please fix CrashOne soonest, v14.3.0 should not have left the premises:-/
1 -
Yesterday C1 became useless. Freezing every 2 minutes. Cannot get any work done.
Using a PC, Quadro graphics, Xeon chip, 32 gig. Latest win 10.
Is this software killing my computer?
Ridiculous waste of time and frustrating.
0 -
I wonder if this has to do with how thumbnails are generated? Or priorities? Stop everything until task completed. This is what is so frustrating. During actual import, all other software functions are disabled, or will lead to a crash or freeze if I click on the toolbar.
All resources are being used to update thumbnails.
I have recently started using a 100mp sensor, though I am not importing hundreds of images at a time. Is C1 having problems parsing too many larger files?
I have also noticed random thumbnails become unreadable, as a previous user mentioned above on export.
0 -
IMHO C1 is currently misusing the windows paging facility. Restrict paging as in my above post. C1 was iffy when I was scanning old 35mm slides but got worse after moving on to my old 6x6 transparencies. I'm now on old 35mm negs, C1 is keeping up with my workflow and not screwing windows. I have not returned to 6x6 stuff yet.
0 -
They just updated. 14.3.1 is out, it is clearly more stable.
0 -
Cheers, thanks for the heads-up:-) Notice that the update needs a restart ...will keep windows paging limited until I'm sure C1 has stopped messing with the virtual scratchpad.
0 -
Still running here with a clamped minimal page file. Editing a (just the one) 6x6 scan seems to have been OK. Heal layer vector arrows still 'disappear' (?resources?) when I work too hard (and expect C1 to keep up). Export area sub panel sizes *STILL* not being saved from one export to another:-| Various paging file issues (?now addressed?) and these sub panels size/placements not being saved used to plague us oldies back in the last millennium, so I assume PhaseOne has young programmers who haven't lived through those old regimes of coding issues:-/ Progress huh. Mutter. Mutter. I'll stress 14.3.1 some more later with a long(er) workout before signing the instability issue off. Then I will release the clamp on dynamic paging sizes and put that back under windows control.
0 -
My limiting of paging to 16MB-64MB is still a valid workaround but big exports get to be hard work. After a long edit of a single 6x6 transparency the export function simply didn't output. It went through the export setup motions but the resultant 'Export 1 image' button did not proceed with an export - no extra CPU no extra MEM no output. Had to restart C1. Export then worked after that clean start but it was hard going in such a small paging area (!obviously!). However C1 proved stable ...albeit with unfixed issues.
Have now returned windows paging back into windows control which seems to have chosen... "Total paging file sizes for all drives: 11776MB". The good points are that C1 seems more stable and that it has not forced windows to improperly increase paging (?yet?) though I have not fully exercised C1 with my normal workflow:-) That means I don't yet know if the healing layer broken-circle-with-arrows symbols still disappear after long/hard work and that the issue must be grouped into the unfixed issues remaining.
Unfixed issues remaining:
* EXPORT - various sub panels' sizes, positions and opened/closed status not saved.
+ PhaseOne please SAVE whatever it is that I have taken the trouble to select/amend/reposition.
* HEALING layer instantiation NEVER allows an immediate/initial spacebar pan - yes, the hand symbol appears but other (unwanted) heal options appear and are or can be actioned instead. Workaround: make a faux heal first, delete the faux heal, then the faulty code allows spacebar pan action to properly spawn the hand symbol and actual panning activity. It's a bit of a mouthful to explain but simple enough to understand if you just do it.
+ PhaseOne please heal the heal's instantiation functionality.So, now looking forward to 14.3.2...
0 -
I've been working with 14.3.1 for several days now and the crashing on Export issue seems to be resolved for me. It's still a bit too early to crack open the champagne, but things are generally looking much more stable. So far, I only have HA enabled for display, but not yet for processing... I'll reenable that next, see what happens, and report back in a few days. Fingers crossed.
1 -
Got back to working on big image files (300MB) and v14.3.1.14 got back to misusing the windows paging file ...flashing up the eternal so-called 'Optimizing...' advice panel (at almost every healing or spotting click). Watched the OS ramping up the scratchpad (! last viewed @ 55MB? or GB? ! )... knowing that CrashOne was heading inexorably to its usual conclusion. Which it did and I completed the CrashOne note and submitted it. PhaseOne Please Fix CrashOne.
Will now revert to one of my earlier mentioned workarounds to ameliorate CrashOne's propensity to fatally mess itself up in the OS. Switched the usual, totally stable, dynamic virtual memory total paging size functionality over to a limited 16-64MB ...to stop CrashOne's misuse of paging.
Keep crossing your fingers people:-| Still looking forward to a fix in 14.3.2?
0 -
16-64MB limit on paging is no longer sufficient to keep this faulty code alive... C1 just crashes earlier now rather than labouring on until the OS virtual file possibly becomes too turgid or latent:-| Will keep paging limited because at least the C1 crash occurs earlier rather than later.
Will now try similar editing after a clean reboot of my workstation and also without anything else running or loaded. However computers and their code should do multiple things at once... This iteration of code is the pits:-| I'm getting no work done.
0 -
Pathetic. Put OS back to dynamic/auto virtual paging. Clean reboot, no other programme running except C1. Dropped file size down from a colour 300GB to a B&W 90GB. Worked on healing and spotting on a very badly visually damaged file. Within a minute or two paging was ramping up (47662MB) but all was well until CrashOne did its now normal thing:-/
Not Fixed. Please Fix. Never even managed to get to an export attempt, which REALLY stresses the paging virtual area, before the Crash Report required filling in and submitting. One again, this iteration should NOT have left the factory. Coders need more caffeine and the betas need to get more active. This is really not good. Unhappy.
0 -
Some stuff from 'one' of the myriad fails of CrashOne:
2021-09-13 16:31:00.886> Managed heap status: 2, free = 0%
2021-09-13 16:31:00.886> (9 identical messages logged; delayed 19.703s .. 10.945s.)
2021-09-13 16:31:00.886> ImgCore heap is fragmented.
2021-09-13 16:31:00.886> (8 identical messages logged; delayed 19.703s .. 10.944s.)
2021-09-13 16:31:00.886> Managed heap status: 3, free = 0%
2021-09-13 16:31:00.886> (8 identical messages logged; delayed 19.703s .. 10.944s.)
2021-09-13 16:31:00.886> Managed heap releasing rawcache: 1, not leaving top item
2021-09-13 16:31:00.886> (18 identical messages logged; delayed 20.250s .. 10.944s.)
2021-09-13 16:31:00.886> First chance exception (thread 13012): 0xE0434352 - CLR exception
2021-09-13 16:31:00.886> (107 identical messages logged; delayed 26.173s .. 10.643s.)
2021-09-13 16:31:00.886> (ERROR) CImageBuffer::SetMinimumCapacity: failed to resize buffer [-2080374784 bytes; cloneSrcImage]
2021-09-13 16:31:00.886> First chance exception (thread 5056): 0xE06D7363 - C++ exception
2021-09-13 16:31:00.886> (EXCEPTION) CImageBuffer::SetMinimumCapacity: could not resize unmanaged buffer.
2021-09-13 16:31:00.886> (ERROR) Exception in CTileExecutionManager::genericPrepareChain, step=10, name=PackageBitmapCPUProcessor0
(CRASH) Analyzing... (thread 13224)
(CRASH) Suspended main thread (thread 12932, code 0)Draw your attention to this particular line...
2021-09-13 16:31:00.886> (EXCEPTION) CImageBuffer::SetMinimumCapacity: could not resize unmanaged buffer.
...possibly!?0 -
Maybe there is something amiss with the format of the scanner's image files? Will now try an image file from one of my cameras and attempt to do some similar massive (wholly unnecessary) editing work. Maybe CrashOne doesn't like the large file output of my scanner?
0 -
Just a quick update - for several days, 14.3.1 seemed to be stable for me... but then randomly and for no apparent reason, it crashed again on an attempt to Export a single image (same symptoms as stated at the beginning of this thread, i.e., the user interface froze, memory usage climbed rapidly and I had to force-exit C1 using the Task Manager).
I'm working with raw camera files only, from a Nikon D810 and/or a Fuji X-T3, so the average file sizes are in the 30 - 45 MB range.
0 -
There's a C1 issue associated with file format and/or size.
I tried a camera which can outputs 85GB B&W DNG vaguely similar in size to the scanner's 90GB B&W TIFF. Editing the 85GB B&W DNG camera file was stable, C1 appeared to be able to keep up with my editing work rate. Stuff seemed much punchier and I didn't lose so many of the editing icons (the broken circles with vector arrows) in my usual editing frenzy. NB: my camera images do not have the visual flaws that I have to correct with my 50yrs old negatives but I simulated a similar workflow. C1 was both stable and did not cause the OS to massively ramp up (dynamic) paging. Total paging file size started at its own setting of 2048MB (min 16 max 4096) and ended similarly. Task Manager showed no particular stress on CPU or MEM. Normal.
Maybe it's the scanner's TIFF that is causing C1 to inflict so much grief on the OS? Part of the TIFF format? Compression maybe? Does C1 expand once at launch or does it try to work decompression dynamically - on demand? I could see why that might cause processing problems.
Will try to reconfigure the scanner to output without TIFF compression and also as DNG/RAW. Try ...the settings are not brilliantly clear. Though the s/w is very configurable the results of changes are not always as expected... This may take some time.
0 -
@Michael Sorry posts crossed and the forum code did not pre-warn me. My cameras typically chuck out 45MB colour and 85MB B&W files.
I'm now scanning 50yr old ?620? format negs from my late father's old LandCamera (I think it was called). As much of what I find I have never seen, even knew of, I'm keen to capture at the max. My medium format trans get output by the scanner at some 180MB. There will be some sub-miniature (James Bond spy camera) stuff later if I can man-handle them into a transport frame for the flatbed but their sizes will be a LOT smaller. In summary: the bigger the file size the worse this C1 issue becomes or possibly the quicker its fatal onset.
Over the decades (!?) I've found compression to be problematic - for everything - but space. I vaguely remember way back when my old IBM PC needed a full sized hardware expansion card just to use compression!
Back to the scanner... well its bridging software actually (the excellent VueScan). A few months ago I started with the outputs as DNG but found the files mostly did not thumbnail properly in Windows Explorer but were parsed OK in RAW editors. So I switched to TIFF. Much bigger files. So I switched on compression for RAW and/or DNG - the helpfiles are not clear.
Basically I ought to clarify exactly what it is that is messing up C1 so badly that the latter overdrives the OS paging to the point where the former crashes into becoming CrashOne.
This may take some time... but *I will be back* - just like Arnie:-)
0 -
Update:
Scanner's 300MB compressed TIFF bloats to 870MB optioned without compression.
C1 still crashes before reaching the end of much editing (before attempting to export).Scanner's DNG came in similarly as 870MB. So, apparently without compression.
C1 didn't crash per se despite copious editing (healing spotting). Only tested 1 file so far!
Many 'Optimizing Heal...' panels. OS dynamic paging just kept growing ...max'd out at 59GB (!)
Responses got more and more lethargic (obviously) but managed to keep alive despite latency.
Handful of OS-like 'out of memory restart prog' panels. No CPU activity at that time.
So, reduced C1 display to 'fit' and then managed to exit properly.
Paging settled back to 4438MB.Unsure whether it is the TIFF format or its optional compression or both
whilst set against the large files that C1 cannot properly handle/process.My scanned DNGs have no compression, there's no specific option. Tiny/wrong thumbnail shown in OS.
My cameras' DNGs have no compression (?think?), ditto but good thumbnail.Currently C1 can only handle small simple tasks - say with just 85MB files.
Have not yet determined the general cutover (into file sizes that are patently
obviously too difficult) for it to manage to process without crashing.Lowest common denominator is C1 misuses OS paging attempting to process large files.
0 -
TLDR: it's the big(ger) files - C1 messes with WIN paging, which ramps overly until C1 crashes.
Small files 85MB stable. Larger files 300MB 'seem' OK. Largest files 870MB problematic.
Moot: why is C1 messing up paging (driving paging to avalanche and eventually a C1 crash).
A file size of 870MB leads to C1 crashing using uncompressed TIFFs or DNGs.
Compressed 330MB TIFF also leads to C1 crashing; presumably the C1 expand 'uses' 870MB.Dropping my usual (6400dpi) 620neg scan down to 3200dpi resulted in just a 218MB image file.
Worked on this - much as usual - paging was not bothered by C1. The export ramped up paging a
little and again when I loaded up a reliable RAW editor (SilkyPIX) concurrently (all to be expected).I've been working with 300+MB files ...but, yes, have had C1 crashes (undocumented).
Between 300 and 800MB C1 starts messing with paging and, sooner or later, crashes.
Need to get back to artwork restoring old archives AOT IT sleuthing. Cannot rely on this iteration
of C1 to reliably rework my larger file size scans and then give me the desired exports. To have to
say that Capture One is proving inadequate for the task is a little unexpected. Something's amiss.0 -
TLDR: C1 does not mess with OS paging whilst using a file size of *up to* 222GB
Workaround: Dropped my target resolution down from a max of 6400dpi to 3200dpi B&W RAW DNG (16bit grey) of 60yr old '620' negatives. This has allowed CrashOne to revert back to Capture One in that it did NOT mess with the OS total paging file and me being actually allowed me to edit and then be able to use the output tool. C1 barely shifted paging, its faulty code certainly didn't ramp the OS paging up to the insane levels (59GB) that are proving so fatal to C1. This was in a regular workflow with lots of other normal stuff running ie not uniquely favouring C1's environment. Finally the tail is not wagging the dog. PhaseOne still needs to fix CaptureOne.
I have actually been allowed to work! Still watching paging and task manager:-/ A whole day without C1 crashes - mainly by limiting the scanner to 3200dpi and its resulting file sizes of 222GB (vice 6400dpi/870GB).
Another related workaround: during heavy healing the 'broken circle with vector arrow' icons start NOT to be displayed. You then have to heal blind as it were. Useful sometimes when the correction area is cluttered up to the point where you are obliged to swing the cursor off page (forcing a display without any icons at all). Toggling from the active healing layer to the background layer and then back to the healing layer appears to REFRESH the available stock of new icons (?stack heap?) and also the dynamic masking/painting functionality (temporarily) returns. It's akin to the necessary cleaning brush action when physically painting with watercolours.
Somewhere between a 222GB image file size and one of 870GB, during heavy editing, CaptureOne mutates itself into CrashONE and starts to mess fatally with the OS paging. Some accumulation of usage, stack heaps, memory leakage or whatever ...not yet determined?
0 -
Robert,
Have you used the "Submit a request" option to create a Support Case with Capture One and share your findings?
If not you probably should consider it.
This section of the forum is not part of an official support system. You are discussing things with fellow users who may have an interest in this specific subject but not with any visible Capture One employee involvement.
0 -
@SFA
>> Have you used the "Submit a request" option to create a Support Case with Capture One and share your findings?
I have not.>> If not you probably should consider it.
Have in the past ...found it to be 'unsatisfactory'.
FWIW over several decades I've become used to speaking
directly to programmers ...though now called developers.>> This section of the forum is not part of an official support system.
Noted. Should be ...'nuff said.>> You are discussing things with fellow users who may have an interest in this specific subject
If I can help fellow users, well, I find that to be wholly 'satisfactory':-)>> but not with any visible Capture One employee involvement.
I've already a direct unique email account here on my personal email server.
C1 can find me if they want to either bother or need to speak to me, I rarely bite.
Had no interest from previous myriad crash reports (cf: flogging a dead horse).
Meanwhile if I can help my fellow users that's excellent, they've helped me.
Not forgetting all this is available on the search engines ...for everyone to see.0 -
Hi Mike, hi Robert,
I think you won't like to hear, but on my PC I can work with scans like a TIF with 501MB (11693x15000px) and a PSD with 674MB (11693x15000px) with GPU acceleration Auto. Both are performing well with my CO V21 (14.3.0185). I just tried again. I just added one of the output JPEGs to your info.
Okay, my machine has 64GB RAM but that should not make a serious difference. Not at all as I am waiting on new graphics card and use an old Nvidia GTX-970 in the meanwhile.
Regards
Ernst0 -
@Ernst - No, it is EXACTLY what I believe:-) My machine has 32GB RAM.
On your 64GB machine it *DOES* 'make a serious difference'. The overriding reason is that working with big(ger) image files causes image editors to have to hand off to virtual paging rather earlier on a 32GB system than it would have to on a 64GB system.
I probably didn't document it clearly earlier but I found that a clean restart and C1 launch lasted better with larger images than on a messy, normal, work-a-day C1 launch with other programmes running. Having more memory installed is even better ...just as you have found, my thanks.
BTW I can use C1 with 32GB RAM installed and those earlier 870MB images without a problem ...until I have done some heavy intense editing, noticing ramping levels of virtual paging, after which an export is simply out of the question.
IMHO it is faulty C1 code that is messing with the OS total paging file functionality that leads the former to its fatal demise within the latter. C1 should NOT be misusing the OS paging, in this manner, whatever the level of available installed memory. It's a bug not a feature and it should be fixed by Phase One.
Several decades ago I managed to raise eyebrows by getting PS (I think it was v4.02 way back then) running on a PC with only 8MB in Win 95 or W2k... How times have changed! 'They' said it couldn't done but I pared down all the OS requirements. Yes, it ran but it wasn't pretty. I don't use Adobe any more.
NB: Will be some delayed response(s). Am experiencing a little difficulty rebuilding my server ATM... [moderator: hence the 'relaying denied' and email bounces, sorry]
0 -
I have the same problem here.
0
Post is closed for comments.
Comments
33 comments