Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

C1 20 crashes immediately on start

Comments

9 comments

  • Ian Wilson
    Moderator
    Top Commenter

    I think it is unlikely that updating to Monterey will help. Capture One has not yet said that Monterey is supported.

    Did you have version 20 working OK at any time, or has it always crashed?

    Have you tried completely uninstalling and reinstalling Capture One?

    Ian

    0
  • SFA

    You may need to look at the log files to see how far the process of start up is getting.

    0
  • Tuomo Kokkonen

    SFA, I cannot say I understand log files, but almost in the beginning is a line "Crashed Thread: 33". Immediately after that something about termination. A screenshot is attached. Does it help in diagnosing the problem?

    Maybe related to this, my C1 has recently been unstable when browsing one folder on ssd. That might well be the root cause of the problem. However, until now restarting C1 has been uneventful and I has been otherwise normal and stable.   

     

    0
  • Marco Hyman

    Launch Capture One while holding down the Opt key.  That will stop it from opening any Catalog or Session.   If it doesn't crash doing that I'd suspect a corrupted catalog or session.  Especially since you mentioned some SSD issues.

    0
  • Tuomo Kokkonen

    Thanks for the advice. Files in the ssd seem to ok, but there is obviously a problem with the catalog.

    C1 is ok when I start it with a new catalog I just created. Opening the old catalog crashes it immediately.

    Have I just lost all picture edits with the corrupted catalog??!!

     

    0
  • SFA

    I suspect you might need to get the C1 Support Team to look at both the Mac logs and the Capture One logs and then suggest something.

    Have you already tried verifying the troublesome catalog?

    Do you have a backup of the catalog from a time when it was working without any issues?

    0
  • Marco Hyman

    Do you have a time machine backup?   If so restore older catalogs.  If not the following might do what you need, but I'm really not sure.

    • Close Capture One
    • In Finder right click on the catalog (the file ending in .cocatalog) and select Show Package Contents.  You should see a .cocatalogdb and a bunch of .cocatalogdb.backup files.  We will ignore these backups if found.  They are for going back to earlier versions.
    • Rename the .cocatalogdb file to .cocatalagdb.bad
    • Open another finder window.   Navigate to to Library (hold the opt key while looking at the Finder Go menu)
    • Navigate to Application Support -> Capture One -> Backups -> <your catalog name>
    • Navigate to the folder holding your most recent backup
    • Copy the <catalog-name>.cocatalogdb file to the folder containing the file you renamed as ".bad"
    • Close the finder window.
    • Re-launch Capture One and open the catalog.

    I don't know if this will work.  Maybe?

    0
  • Tuomo Kokkonen

    I have gone back in TM to a newest catalog version that does not crash. Ok, sort of...

    The problem is that I yesterday evening and today morning was a working on a publication and organizing pictures. Lost edits are not a big deal restoring catalog and picture ssd by hand is real pain. I guess I just have do my best and accept that some pictures maybe lost in the process.

    Yesterday evening, when working with pictures, I was thinking about updating my license to C1 22, but somehow it does not feel so good idea anymore :-(

    0
  • SFA

    Tuomo,

    Yep, lost work is an unwelcome problem. 

    Your description of the issue you face sort of suggests a corruption somewhere in the system that affects the ability to open and use the catalogue.

    The only time I have seen something similar in C1 was using, iirc, Version 7.

    I use Windows and sessions. 

    For one session with about 3000 images I was seeing crashes about every 10 to 12 images as I worked through them. After several days an some investigation that produces no consistent clues about the problem, I spotted a Browser thumbnail that looked like it had not been created correctly.  This image was near the end of the 3000 I was working on. I was already about 2/3 of the way through.

    I tried to regenerate the image and the thumbnail was still bad. So I deleted the image, re-imported it and fnd that all was well. No more crashes after that.

    I think what had happened is that the OS has somehow written a data block to disk with a "bad" block reference "number" and that the number was being "discovered" when data blocks for other images were being gathered together because of its "bad" reference. This then introduced a data error - for example an untrapped letter where a number was required - and caused the system to crash because a calculation failed.

    Deleting the file removed the reference. RE-importing did not introduce a new error. All was well. It has never happened again.

    If something similar has happened to the way your catalog, or some component of it, has been written to the disk you might well see a similar problem but without the luck of identifying a relatively easy solution.

    The catalog verification program might help  - but there is also a chance that it will not since looking for problems at the file storage level is really an OS matter  - functionality that the application will normally just rely upon to work correctly at all times. 

    Nevertheless I would recommend running the verification if you have not done so. 

    And of course the problem you have may not be anything like the underlying problem I had so long ago.

    0

Post is closed for comments.