Access Violation in GetOpenFile function

[dannycat]

I am encountering a problem when calling the windows Common Dialog GetOpenFile function from an IVF FORTRAN windows application recently converted from CVF. The function works fine on the CVF version of the application and I have also tried, unsuccessfully,to reproduce the problem using both the 'GetOpenFile' sample and a modified 'Generic' windows sample (calling the subroutine taken from my application). This leads me to believe that the problem is caused by the libraries that are referenced at the linking stage. I get the following warnings when the program has compiled and linked:

LIBCMTD.lib (crt0init.obj) : warning LNK4098: defaultlib 'libcd.lib' conflicts with use of other libs; use /NODEFAULTLIB: library

LIBCMTD.lib (crt0init.obj) : warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB: library

Is it safe to ignore these warnings?

The program crashes reporting a 'Unhandled exception at 0x7639db6d in IVFtest_dbg.exe 0xC000005: Access violation reading location 0x20202020.'When I break into the code it puts me in the disassembly listing which I don't understand.

I believe that access violations are caused when the program is trying to read or write to an invalid address but the only argument for the GetOpen Files function is the T_OPENFILENAME structureset using the same methods definedin the sample. I've tried isolating the problem by ignoring each field in the data structure and the only time it does not cause a crash is when I don't assign the lpStrFile member (i.e. leave it = 0) whereby the function returns without displaying the Common Dialog box.

Has anyone got any ideas on this?

[GVautier]

Hello

Trying to access an 0x20202020 address looks like an invalid pointer in the T_OPENFILENAME structure like pointing to a string rather than to its address.

[dannycat]

All lpstring fields are populated using the loc() intrinsic function. This should provide the address of the string buffers.

[Jugoslav_Dujic]

LNK4098 is a FAQ, but it shouldn't cause the behavior you describe. It shouldn't happen in IVF though. In CVF, the root cause are different settings for C/C++ and Fortran run-time libraries. In this case, you have 3 "Multithreaded debug" (libcmtd), "Single-threaded debug" (libcd) and "Multi-threaded" (libcmt). Have you rebuilt everything? It's advisable to fix this, though it's probably not crucial.

0x20202020 suspiciously looks like a string of four blanks (" ") mistaken for an address. Can you please post the code assignments to OPENFILENAME members and their declarations?

[dannycat]

I have found out what is causing the crash. In the WinMain procedure I have tried to check if a filename exists on the command line. ie. when the user double clicks the application icon. To do this I used the following lines of code:

character*255 cmdline

pointer (lpfile,cmdline)

lpfile = lpszCmdLine

I later initialised the cmdline which put spaces in 255 bytes probably going beyond the end and corrupting a region of memory used by the common control functions.

Regarding the link issue, could the link messages be caused by the fact that I am linking to C libraries created in an older version of Visual Studio (6.0). When I tried to recreate them in Visual Studio 2008 the FORTRANapplication failed to link because of unreferenced routines defined in the C libraries. I couldn't find what settings affected the C calling conventions. I tried changing the call convention in the FORTRAN project but all this did was cause more problems with call to COM modules, OpenGL, SQL libraries etc.

[Jugoslav_Dujic]

dannycat:

Regarding the link issue, could the link messages be caused by the fact that I am linking to C libraries created in an older version of Visual Studio (6.0).

Hm. What happens if you don't specify any C library? That should fix it. Fortran run-time library already contains linker hints to the corresponding C one, and referencing run-time libraries by name is generally a bad idea.

Newer RTL versions should be compatible with the old ones, but who knows...