I am testing the Intel MKL Pardiso solver and the Release build crashes in all cases on Windows 7 but solves successfully on Windows 10. To add to the frustration, the debug build solves successfully on Windows 7 and Windows 10.
One particular frustration is that fault fails silently with no exception thrown that I can attach debugger. The only clue that something went wrong is in Event Viewer. Typical exception text...
Faulting application name: MCSN.EXE, version: 184.108.40.206, time stamp: 0x58b4f49e
Faulting module name: MCSN.EXE, version: 220.127.116.11, time stamp: 0x58b4f49e
Exception code: 0xc0000005
Fault offset: 0x000000000004dbd0
Faulting process id: 0x1ba0
Faulting application start time: 0x01d2dfcede933818
Faulting application path: c:\<install folder>\MCSN.EXE
Faulting module path: c:\<install folder>\MCSN.EXE
Report Id: 1d5da2e0-4bc2-11e7-b77b-4061868fe62f
Despite enabling traceback, none is listed in the exception so I am inclined to think that the fault is in the MKL code.
I am dual booting into the same machine so the hardware is identical. Both operating systems are fully patched and code is compiled with Intel Parallel Studio XE 2016, Update 4.
Are the MKL files statically linked or dynamically? Just my guess. Is it possible that when you compile the Release build, the MKL is linked dynamically, and you are accessing an old MKL version that you have stored on your computer?
To get some more insight into the problem adding some old fashioned write statements into the code to send some progress info to a text file might prove useful.
If adding WRITE statements to a log file can be done without suppressing the bug, by all means use them.
If not, the exception code (C0000005) and the 64 bit code offset (0x000000000004dbd0) can be used to locate the problem source line using (i) the debugger, or (ii) by using a linker map, if available or generated afresh as needed, or (iii) by using the Dumpbin utility on the faulting EXE or DLL.
It was a Heisenbug that caused me to make my first post in these forums, in 2010. It was almost a year later that I discovered the name "Heisenbug" and realized that the name fitted the optimizer bug that I reported (and which Intel had already fixed).