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

The Value of ESP not saved & Access Violation


Dear Team,  Please forgive the lack of understanding I have on this matter, but the scenario is as follows:

There is a VB6 GUI that calls a Fortran dll (I'll call dllA and is the code that I'm working on) which in turn calls another external Fortran dll (dllB).  This setup appears to have worked for the past decade, although I suspect some 'impurities' lie buried in the Fortran code as far as declarations etc are concerned.  I now wish to call another Fortran dll (dllC) from dllA, but then encounter the attached error message 1 in Visual Studio.  Even though dllA is trying to call dllC, it looks like the error message refers to the VB6 GUI ('SIT_Perf.exe')

I have the rights to change the code in the VB6 program and dllA, but not the other two dlls, although I do have their IO code.  Besides the error code, I've also attached the call code and declarations from the VB6 program and the three dlls.  If certain run-time checks are reinstated, error message 2 also appears.

I am aware that you may need more information!  Please feel free to request it.

Regards, Guy

0 Kudos
4 Replies
Black Belt Retired Employee

Error message 2 highlights the probable cause - a mismatch in calling conventions. The screenshots you provided do not show a complete picture of what is happening. 

VBA has no idea that the error involves DLLs, so it just reports the error as being in your EXE.

The first thing is to make sure that all three DLLs agree on the calling conventions (STDCALL vs. the default C).


Dear Steve,

Happy New Year!  I am honoured that you should (appear to) respond on Christmas Day morning!

I have attached the entry code to dllB that was missing from the first batch of files I sent.  To my inexpert eye, they all seem to be using STDCALL where the declarations for the programs are concerned.  STDCALL is not used in dllB or dllC for the argument declarations.  dllC uses a mixture of REFERENCE and VALUE for these, dllB uses REFERENCE only as shown in the relevant code snippet.

I tried using FreeLibrary (free_status = FreeLibrary (hLibModule=lib_handle) )after calling dllB and before calling dllC, but it does not seem to make a difference, the error message is the same.

Stepping through the program, the 'call pemsCombined_dll' statement is reached and then, when attempting to execute this statement, jumps back to the line beginning 'Q = getprocaddress' and shows the attached message 'Error Message3-Microsoft Visual Studio.png' which is similar to the 'Error Message1-Microsoft Visual Studio.png' sent earlier.  When 'Continue' is attempted, the attached message 'Error Message4-Microsoft Visual Studio.png' appears.  By this time, dllB has already been called and run apparently successfully.

Please let me know if there is more supporting information I could supply that would help the diagnosis.

Your learned and enlightened thoughts would be greatly appreciated.

Best regards,

Guy S


Black Belt

When you produce a debug build, the MS debug libraries typically initialize undefined variables to 0xCCCCCCCC. Access writing location 0xCCCCCCCC is indicative of using an undefined variable (reference).

If I were to guess, the interface to getprocaddress is not declared properly, and is using VALUE for libhandle.

Jim Dempsey


Many thanks for all your help - much appreciated!  There was indeed a mismatch between what dllA was calling with and what dllC was expecting.

Best regards,