Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26736 Discussions

Intel MKL Pardiso Solver crashes on Windows 7


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:, time stamp: 0x58b4f49e
Faulting module name: MCSN.EXE, version:, 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.


0 Kudos
5 Replies
New Contributor I

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?



Honored Contributor I

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.


Black Belt

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.

Honored Contributor I
Yes it could be the dreaded Heisenbug - a software bug that seems to disappear or alter its behaviour when one attempts to study it.
Black Belt

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).