If an error is occured in a PAR client while create/verify/repair, that is shown as "Error : something..." on GUI. When PAR client is stopped by an error, the output of PAR client is save in log file without option setting. A user may refer the log to see what is the problem. When a user want to report the problem by sending mail to a developer, he should attach the log file with the mail.
  When "malloc" error happened, decrease the number of source blocks. If source files exist on un-writable media like CD/DVD, copy those files on HDD at first, then repair the copied files. If the source files are very large, be careful about available space of HDD. If you cannot open or repair files, other applications or system may prevent your file access. You should close others and confirm your privilege.
  When "checksum mismatch" error happened, it was caused by a hardware problem (such like failure in CPU, RAM, HDD). Because MultiPar consumes most machine power, PC may become un-stable by high stress or over-heat. If MultiPar detects calculation error, it stops to avoid invalid creation or failed repair. Your PC should be enough stable for heavy task.
 
There are some solutions to try;
(1) Change BIOS setting for safe running.
 
If you set over-clocking, return to the original value.
If you set faster memory access mode, change to slower speed.
(2) Check memory error.
 
Recent Windows OS has memory test feature.
If it finds error, you must replace the bad module.
Even when you never see a problem at daily small memory usage,
MultiPar may use larger memory space and can reveal failure.
(3) Change MultiPar setting to disable GPU acceleration.
 
There is "Hardware environment" section on "System settings" tab of MultiPar Options.
Un-check "Enable GPU acceleration".
(4) Change MultiPar setting to disable extra feature of CPU.
 
There are some check-boxes in "Extra feature".
Un-check them one by one and test until no error.
The order of un-checking is from "AVX2", "JIT(SSE2)", "CLMUL", to "SSSE3".
(5) Change MultiPar setting to use less number of threads.
 
Move "CPU usage" slider from right to left.
(6) Change MultiPar setting to use less memory.
 
Select smaller number at "Memory usage upto around".
  If hash value of a damaged file happens to be same as hash value of its original file, PAR clients cannot detect the damage. This is very rare case, but serious problem if happen. Because data in complete files are used to recover damaged files, miss-detection of damage causes failure of recovery. If you get this problem, you may check files with another hash like SHA-1.
  Because PAR uses MD5 hash, accidental collision problem will not happen normally. In addition to MD5, PAR 2.0 uses CRC-32 to check completeness, then the chance of miss-detection is very low. Caution, MD5 was broken already as cryptgraphic hash. When a malicious cracker modified files by forging same hash values, PAR clients cannot detect the intended modification.
  PAR 1.0 uses MD5 hash to distinguish source files. When there are files of same contents, their MD5 becomes same also. In this case, those files are distinguished by filename only. If one of them are lost and another is misnamed, it is difficult to determine which file is lost or misnamed. When a file is thought as lost, it requires parity volume to recover. If you know those files have same contents, it is much faster to copy from another file.
  There is a fault in the method of creating generator matrix in PAR 1.0 and 2.0. Rarely the matrix is not invertible, and repair will be failed. If you cannot repair files with enough recovery blocks, you would better try with different recovery blocks. When there are extra blocks in the set of PAR2 files, MultiPar tries to solve this problem automatically.