fMRIPrep errors: recon report and mri coreg

Hi there,

I’m using fMRIPrep version 20.2.2 and so far have run pre-processing for 17 participants. However, I have to run pre-processing for the remaining participants, but run into these two errors: recon report and mri coreg, time and again and don’t know what to do.

Please find the attached crash reports:

crash-20210818-070922-root-recon_report-17d54cd7-2523-46d7-8d00-6419b7eec97a.txt (2.2 KB) crash-20210818-071002-root-mri_coreg-568b7ab9-bbed-43de-ab74-f5e7118c093c.txt (4.2 KB) crash-20210818-071041-root-mri_coreg-0bfe4343-61b9-41cc-804e-591e54de8d8b.txt (4.2 KB) crash-20210818-071119-root-mri_coreg-beaf86d2-aaed-4e62-911e-69a92d96b58e.txt (4.2 KB)

This is the code I used: fmriprep-docker /mnt/c/Users/rubin/BIDS /mnt/c/Users/rubin/derivatives participant --participant-label sub-J1121053 --fs-license-file /mnt/c/Users/rubin/fs-license/license.txt --low-mem

I would be so grateful if anyone has come across this issue and resolved it or if anyone can point out how I can overcome this error.

Many thanks in advance for your help.



Hi Rubina, it seems some of your files are corrupted for some unknown reason. I’ve opened indexed_gzip.indexed_gzip.CrcError: CRC/size validation failed - the GZIP data might be corrupt · Issue #265 · nipreps/smriprep · GitHub, please follow up there.

Hi @oesteban,

Thank you so much for getting back to me. That’s really strange because I used MRIcron to convert DICOMs to Niftis (dcm2niix)

In any case, I can send you the Nifty files for verification. I can’t attach it here given the limited formats in which I can attach files but is there an email address I can send these files?

Many thanks,


The bad file appears to be freesurfer/sub-J1121053/mri/ribbon.mgz. There may have been an issue with running FreeSurfer. Can you check whether the file can be opened with freeview?

If it is corrupted, probably the easiest thing to do is to delete that subject from the FreeSurfer directory and re-run.

I opened the .mgz file and here’s the details of the file (please see attachment).

This is happening with other subjects as well. Should I just delete this file, and run the code again?

Are you able to view the file in freeview or another image visualization tool like mricron? The tool you’re currently using is only showing some basic metadata and does not indicate whether the contents are corrupted or not.

I used mricron to open the file and I get the following message:

So I would say the file is corrupted. Re-running FreeSurfer would probably be the best bet. Could you share how you ran it in the first place?

This is the code I used: fmriprep-docker /mnt/c/Users/rubin/BIDS /mnt/c/Users/rubin/derivatives participant --participant-label sub-J1121053 --fs-license-file /mnt/c/Users/rubin/fs-license/license.txt --low-mem

I also tried deleting everything and starting from scratch but still get the same message with other participants.

Should I delete the .mgz file when it appears? I usually delete the -IsRunning file in scripts located under FreeSurfer.

When you say deleting everything and starting from scratch, what exactly are you deleting?

If you’re seeing IsRunning files, then this means FreeSurfer did not exit correctly, and probably crashed, either due to running out of disk space or memory. This makes me wonder why you’re not seeing failures during FreeSurfer, but instead in jobs that depend on FreeSurfer outputs. Are you just deleting IsRunning.* from the FreeSurfer derivatives and re-running fMRIPrep?

Without more to go on, I would probably delete your entire FreeSurfer directory and start over.

When I recently and repeatedly saw the crash errors, I decided to delete all the directories (fmriprep and freesurfer) for those participants and started all over again.

I only deleted IsRunning.* files. I did this for other participants (I already ran preprocessing for 17 participants) and it worked out just fine with no errors reported.

What do you suggest I do at this stage? Should I not delete the IsRunning.* file?

I apologize if I’m being dense, but these seem contradictory to me:

Deleting the whole freesurfer/sub-<label> directory should restart FreeSurfer processing for that subject on the next run of fMRIPrep.

It’s hard to give advice because I don’t understand how we got here, but here’s what I would do:

  1. For a subject exhibiting this problem, delete that subject’s entire directory in FreeSurfer’s outputs.
  2. Run fMRIPrep for that subject.
  3. If it fails, post the full logs. Do not try to clean things up and re-run first.

My apologies for not explaining the issue well enough.

When I said that “I decided to delete all the directories (fmriprep and freesurfer) for those participants”, I was talking about the “Derivatives” folder for those participants. While the code was running, I was constantly deleting the IsRunning.* files because doing so worked in the past when I ran the code for other participants.

In any case, thank you so much for getting back to me with a solution and I’ll take your suggestions on board. I will run the code again and I hope it works but if it doesn’t, I’ll get in touch again and post the full logs here.

Many thanks and best wishes,


Oh, I see now. These should only be deleted if FreeSurfer has crashed and you need to restart it. While it’s running, it’s how FreeSurfer tells itself not to interfere and possibly corrupt your data.

Oh okay, I didn’t know. Thank you for explaining the reasoning behind the IsRunning.* files :wink:

Hi @effigies,

I ran the code again (and didn’t delete the IsRunning.* files) but unfortunately, I still end up with the same crash errors :frowning:

Do you have any suggestions on how I can resolve this issue?

Thank you for your help.



Are you able to share the logs from fMRIPrep? There should also be logs in the scripts/ directories.

I have these logs from fMRIPrep but I cannot share these because of the limited file extension. Please see a screenshot of these below:

Here are the logs in scripts (I cannot attach some files because I’m not authorised to):

build-stamp.txt (58 Bytes) build-stamp.txt (58 Bytes) patchdir.txt (1 Byte)

If need be, I can send the remaining logs via email, if you like.

Specifically we need to look at recon-all.log, recon-all-lh.log and recon-all-rh.log. You can just add .txt to the extension if uploading is a problem. And for fMRIPrep logs, I meant the console output.

Here are the three logs:

recon-all.txt (207.9 KB)
recon-all-lh.txt (176.0 KB)
recon-all-rh.txt (183.7 KB)

I’m not so sure what you mean by “console output”?