1. I have been using a Fortran DLL for the past several years (10+) which contains several utility functions. These functions are called in Excel VBA code via wrapper functions.
2. The DLL has always been created using the default project settings except
Configuration Properties -> Fortran -> External Procedures -> Calling Convention: CVF(/iface:cvf)
Configuration Properties -> Libraries -> Runtime Library: Debug Multithreaded (/libs:static /threads /dbglibs)
3. When the DLL was rebuilt using Intel® Parallel Studio XE 2018 with Microsoft Visual Studio Community 2017 last week, opening an Excel file that accesses the DLL generates the following error and causes Excel to crash.
Microsoft Visual C++ Runtime Library
Program: <Path to DLL>
Damage before 0x24DBE430 which was allocated by aligned routine
(Press Retry to debug the application).
4. I have tested the DLL within Fortran by using a Fortran main program to call the same functions and it works without error. Somehow, the rebuilt DLL is incompatible with Excel.
5. Further, I had saved a copy of the same DLL built with Intel Parallel Studio 2017. Excel is able to access the functions in the same DLL built with the earlier version.
6. So somehow, IPS2018 seems to be causing a problem.
Your help will be greatly appreciated.
Have you tried building the DLL with Runtime Error Checking and Generate Traceback Information turned on? These can be informative. I use Custom and check the first three options.
There's not a lot to go on here.
How much debugging of the crash have you done? You can debug through the Excel process into calls to your dll and try and narrow down the problematic code.
Thanks for the responses so far. The issue appears to be in the mixed-language interface within Excel since the DLL works without error in a Fortran environment. Debugging or traceback has been difficult since Excel crashes as soon as any legacy file is opened. So far I have managed to start Excel in manual calculation mode, delete all worksheets calling these functions and then incrementally start calling functions one at a time. Some functions are working fine whereas, in others, the results are meaningless upon return.
At the same time, the legacy DLL built with IVF2017 is working normally in Excel.
So I plan to reinstall IVF2017 and rebuild once again to see if I can create a normally functioning DLL. I will keep everyone posted.
Apparently, this error has been discussed on this Forum before though not related to Excel in the thread "What is up with "Debug Error!" from Microsoft Visual C++ Runtime Library?" by FortranFan.
You can debug this from MSVS.
Create a debug version of your DLL; if Excel is loading the DLL from a specific location, copy the DLL to that place.
In MSVS, set the debugging command to be Excel.exe (you probably will need to provide the full path to the exe file).
Set some break points in MSVS after the entry points in your DLL.
Start a debugging session ... this will start Excel.
Then load your Workbook that calls the DLL, and you should be able to see whether execution can get to the DLL, and whether execution fails before, during, or on exiting the DLL. This will help narrow down the cause of the problem.
print *, array(i)%z ! OK
Most likely, you have a bug elsewhere in your program that is corrupting memory.
Your INIT procedure has a deallocate statement in it - I assume that is a typo.
Do those procedures have an explicit interface accesible at the point they are called? Are they defined in a module?
Allocatable components (versus pointer components) do not need to be manually deallocated ahead of the object that they belong to ceasing to exist.
I agree with Ian "5. The process of deallocating the individual components was generating the error since the MSVS debugger showed that the components z were defined prior to entering FREE but were undefined once FREE was entered. Interestingly, the contents of individual z's could be printed within FREE but not deallocated."
This I think is a bug in the debugger/fortran integrations that is well documented elsewhere on the forum. I do not think it is the cause of the problem. You have changed the code and it magically now works, but this could also be that the meory corruption bug has just moved to somewhere less damaging/obvious.
@IanH - You correctly point out that the deallocate statement is a typo in my pseudocode. These procedures all have an explicit interface but are not in a module. I thought there was a bug somewhere between calling INIT and calling FREE, but code execution works normally until FREE is entered. In fact, the process of deallocating the component occurs normally if it is done just before calling FREE. So clearly, corruption is either in FREE or not detected before calling FREE.