topic evtx is a windows event log in Intel® oneAPI Math Kernel Library

Faulting module name: mkl_core.dll, version: 11.0.4.1

kingsley_s_ — Mon, 12 Aug 2013 19:12:05 GMT

Faulting module name: mkl_core.dll, version: 11.0.4.1, time stamp: 0x5195ead6

Exception code: 0xc0000005

Fault offset: 0x00829aa0

I'm hoping this is a known issue that has been fixed in a later updated. We've been running for several months performing a 2D FFT on 10,000's of images and this is the first time that the MKL library has failed. Not much to go on. Basically the program crashed and a couple of events in the system log.

Kingsley

What is bis-crash.evtx file?

SergeyKostrov — Fri, 16 Aug 2013 06:01:07 GMT

What is bis-crash.evtx file? Please explain.

evtx is a windows event log

kingsley_s_ — Mon, 19 Aug 2013 13:49:05 GMT

evtx is a windows event log file. You should be able to just ckick on it and windows will display the two log entries that were created. Not much in it really, but that is the only info I have. Really all I get out of it is:

Faulting module name: mkl_core.dll, version: 11.0.4.1, time stamp: 0x5195ead6

Exception code: 0xc0000005

Fault offset: 0x00829aa0

Rather than try to infer

mecej4 — Mon, 19 Aug 2013 14:01:18 GMT

Rather than try to infer from event-logs what caused the C0000005 (access violation) exception, it would be more useful to isolate one (or more) input data to the FFT calculation that caused the exception. That data, and the portion of code that contains the FFT call, would be a lot easier to work with because that would be at the source code level. If you are calling from Fortran, you can enable the compiler's traceback option.

This is a rather rare event.

kingsley_s_ — Mon, 19 Aug 2013 14:26:36 GMT

This is a rather rare event. Maybe once every 10,000 frames. I already updated MKL to Update 5 (from Update 4) hoping that the problem has been fixed already. I ran two instruments over the weekend and did not have this problem again. Maybe collected 5,000 frames. Statistically, meaningless.

It is being called from C#.It is happening on the release code build as the debug build is too slow for actual instrument acquisition.

The fault offset will tell you which routine in the mkl_core.dll is crashing, but that is about all.

>>...That data, and the

SergeyKostrov — Mon, 19 Aug 2013 14:30:12 GMT

>>...That data, and the portion of code that contains the FFT call, would be a lot easier to work with because that would be >>at the source code level... I agree with that point and Windows Event logs are not helpful because they do not show how MKL API was actually used. kingsley, Why wouldn't you upload a test case that reproduces the problem?

>>> Why wouldn't you upload a

kingsley_s_ — Mon, 19 Aug 2013 15:08:51 GMT

>>> Why wouldn't you upload a test case that reproduces the problem?

The program crashed and all information is thus lost. It may take another three months to reproduce this issue. The image is newly acquired, so I do not have a copy of that either.

Quote:kingsley s. wrote:The

mecej4 — Mon, 19 Aug 2013 15:36:00 GMT

kingsley s. wrote:
The fault offset will tell you which routine in the mkl_core.dll is crashing, but that is about all.

True, but not very useful to find the reason for the failure, particularly since users do not have the MKL source code.

From your own experience, we know that most of the time no crash occurs at that location (or the location is not even encountered). Thus, the crash occurs only for some input argument values. Therefore, we have to find those values and investigate the crash using that set of values.

One way of capturing the faulty input set is to print an image number to a log file or the screen after each successful FFT call. Note the last number printed out before the program, and recreate the input data using that number. If this approach is too slow, use binary search.

More information on this

kingsley_s_ — Fri, 20 Sep 2013 15:26:32 GMT

More information on this issue. I think it may be a threading issue. The exception is being thrown on the line:

int ret =DFTI.DftiCreateDescriptor(refdesc, precision, forward_domain, dimension, len);

The parameters are always the same. Precision is DFTI.DOUBLE. forward_domain is DFTI.REAL. Dimension is 2. Len is {1024,1024}. What I am thinking is that the previous image may still be processing its FFT. Are you limited to processing one FFT at a time? Thanks.