I share this info because it might be of help to the developers to get Quartus more stable:
Symptom: Q17.1 Q18.1 crash at the end of the compile cycle. The program is compiled, but just after compilation Quartus crashes.
*** Fatal Error: Access Violation at 0X000007FEFD7038D8
0x38d7: GetLengthSid + 0x27 (KERNELBASE)
0x1500a: MultiByteToWideChar + 0x1a (kernel32)
0x22265: __setusermatherr + 0xd5 (MSVCR120)
0x26ff5: _access_s + 0x21 (MSVCR120)
0x26fc8: _access + 0x8 (MSVCR120)
0xb772: FIO_PATH::fullpath + 0x82 (CCL_FIO)
0x3bad6: PGME_PROGRAMMER::engage_ocpp_mode + 0x8d6 (pgm_pgme)
0x295b7: QThread::start + 0x427 (QtCore4)
0x24f7e: _beginthreadex + 0x106 (MSVCR120)
0x25125: _endthreadex + 0x191 (MSVCR120)
0x159cc: BaseThreadInitThunk + 0xc (kernel32)
0x5385c: RtlUserThreadStart + 0x1c (ntdll)
Multiple times, the crash report contains PGME_PROGRAMMER.
Quartus Lite 17.1 & 18.1 = Crash
Quartus Standard 18.1 = Crash (license Nios / Uart license was missing)
Quartus Standard + all necessary licenses = No Crash Anymore = solved 100 %.
It seems that when all is fully licensed, crash do not happen any more.
Project crashing can be shared if needed.
Added to this report: 13 stack traces of practically identical crashes.
No, cleaning did not make any difference.
But, as explained in detail above, when I no longer needed the time-limited sof, because I obtained the necessary licenses, the crashes did no longer happen.
Since crashes seem to happen in the programmer part (see stack traces), your question regarding the relationship between cleaning and crashing during compile is something I am very interested in to know more about; After restarting Quartus, I could download the .sof that was generated during compile, and is was OK.
Can you explain the background of your question?
To be clear: Buying the software solved my issue but it would be nice is the lite version of Quartus also became more stable.