Access violation error when calling DlgModeless

[Jonathan_K_1]

Hi all,

I'm having an issue with a few of my Visual Fortran Solutions. Every time I try to run a 32bit build of our software, I get an Access Violation (0xC0000005) or "The application was unable to start correctly (0xc0000017). Click OK to close the application.". Any attempt to debug this crash leads me to a tab that says "Frame not in Module. The current stack frame was not found in a loaded module. Source cannot be shown for this location.".

Has anyone experienced these sorts of errors before? They both only occur on 32bit builds, and don't appear when I build in 64bit. In some solutions, I can at least start debugging the program, and fails at a call to DlgModeless(dlg, nCmdShow).

I'm using the latest Intel compiler (Composer XE 2016, update 3) on Visual Studio 2015 Update 3 on a Windows 10 x64 laptop.

Any tips would be very much appreciated.

[Steven_L_Intel1]

Can you provide a short program that reproduces the problem? My guess is that the actual cause is separate from the DlgModeless call.

[Jonathan_K_1]

Hi Steve,

Thanks for the prompt response. I've attached one of our smaller Fortran projects that just doesn't want to work with the latest compiler and visual studio suite. It compiles okay, but dies just after entering the main program.

Any insight you can provide would be greatly appreciated.

Best regards,

[Steven_L_Intel1]

Set the project property Fortran > External Procedures > Calling Convention to Default. You have it set to CVF. In most cases this is harmless, but not when you are using callback routines such as with the dialog box support. The mismatch causes stack corruption.

[Steven_L_Intel1]

Another thing I noticed - you have at least one place where you do:

IF (logical-var == .FALSE.) ...

This is very bad practice, as the variable might not have the exact binary value of .FALSE.. It is far better to write this as:

IF (.NOT. logical-var)

[Jonathan_K_1]

Thank you so much for the reply Steve, that completely resolved the issue on that project. When I try the same fix on a different project though, I get a bunch of linker errors in the *.obj files that don't appear when I build the project in 64bit.

The errors are:

 : error LNK2019: unresolved external symbol __imp__TUFAST_S4 referenced in function _SOLVEGPU
 : error LNK2019: unresolved external symbol __imp__TUFAST_INITIALISE referenced in function _SOLVEGPU
 : error LNK2019: unresolved external symbol _BOUNDNATURAL@52 referenced in function _BOUND1
 : error LNK2019: unresolved external symbol _REPORTTIMEINFO_mp_ISREPORTTIME@8 referenced in function _TRANSX
 : error LNK2001: unresolved external symbol _REPORTTIMEINFO_mp_ISREPORTTIME@8
 : error LNK2001: unresolved external symbol _REPORTTIMEINFO_mp_ISREPORTTIME@8
 : error LNK2001: unresolved external symbol _REPORTTIMEINFO_mp_ISREPORTTIME@8
 : error LNK2001: unresolved external symbol _REPORTTIMEINFO_mp_ISREPORTTIME@8
 : error LNK2019: unresolved external symbol _REPORTTIMEINFO_mp_INITREPORTTIME@4 referenced in function _TRANSX
 : error LNK2019: unresolved external symbol _SOLVEGPU@40 referenced in function _EXTRAN
1>*removed*.exe : fatal error LNK1120: 6 unresolved externals 

Do you have any idea what might be causing these? I've attached the project file if that helps at all. 

Thank you so much again for your help. I inherited these projects that have been passed down through many pairs of hands over the years, and as you can see they haven't always been kind to the code quality!

[Steven_L_Intel1]

You may need to do a full rebuild of the project and any libraries it uses. It looks as if you have a mix of STDCALL and C calling conventions. x64 doesn't have STDCALL but use of /iface:cvf will change where string lengths are passed so it is critical that all parts of the application agree on the calling conventions.