Visual Studio 2019 crashes when debugging mixed C++/Fortran program

[Brian_Francis]

A few months back we upgraded Visual Studio from 2015 to 2019 and Intel Fortran from 2016 to 2019. Everything compiles, links and runs as expected. Quite pleased about how smooth the upgrade went.

Less pleased though about instability when debugging mixed language C++/Fortran programs. Setting a breakpoint in a Fortran function and running to that breakpoint causes VS to display a message box with title "devenv.exe - Application Error" and with message "The instruction at 0x00000000545AE283 referenced memory at 0x000000002BA20000. The memory could not be read." The memory address and instruction change at each occurance. The same problem happens when hitting a breakpoint in a C++ function when the Call Stack is active and a Fortran function is somewhere on the call stack. This instability occurs for both 32-bit and 64-bit builds.

I recorded the problem and submitted it using the VS "Report a problem" feature. It has been stuck in "Under Investigation" status now for a month. See https://developercommunity.visualstudio.com/content/problem/714437/vs2019-crashes-at-breakpoint.html

We have 7 developers with different workstations, all running Windows 10, who all have the same problem. One of our key products extensively uses Fortran, so not being able to debug it is a real showstopper. As a workaround we had to make the following changes to all C++ projects in the mixed language solution:

• Platform Toolset: Changed from "Visual Studio 2019 (v142)" to "Visual Studio 2015 (v140)"
• Windows SDK Version: Changed from "10.0 (latest installed version)" to "10.0.14393.0"

With the latest VS 16.3 update, VC16 binaries are no longer compatible with VC14. To continue using the workaround we would have to make the same changes to C++ projects in all other solutions (because we statically link libraries produced by other solutions). We cannot do this, so we've rolled back out of the latest VS update.

Is this a known problem? Are other developers experiencing this problem? Other suggested workarounds or solutions?

Thanks,

Brian.

[AONym]

I have a similar problem. My executable is C++ main pgm and Fortran library, hundreds of source files in each. I am running Visual Studio 16.4.4 and Intel Fortran 2020 19.1.0.166 on 64-bit Windows 7 Pro.

Running a debug build (x64), Visual Studio 2019 crashes when it either reaches a breakpoint in the Fortran code, or I attempt to interrupt execution of Fortran code using Visual Studio's "Break All" button. This does not happen when a breakpoint in the C++ code is reached, or when I interrupt execution of C++code using "Break All". VS will crash if I set a breakpoint at the very first Fortran subroutine statement, or anywhere else in the Fortran code.

The Fortran is run in a separate worker thread from the C++. The Fortran uses OpenMP, but the crashes occur in sections of the code that are not using any OpenMP functions, so I don't think the crashes are related to OpenMP.

Complete rebuild does not change anything. My impression is that this issue started with VS 16.3, but I am not sure about that.

As an experiment, I set a breakpoint in C++ just before the first call to a Fortran subroutine and single-stepped the assembler code through the subroutine prologue and past the breakpoint I had set in Fortran, and there was no crash. However, normal execution crashed at this breakpoint, and continuing execution at full speed from single-stepping the assembler crashed at the second breakpoint.

[Brian_Francis]

Hi Ann,

Our experience is that Studio seldom crashes when debugging Fortran. This is much better than where we were a few months back. We are using:

• Microsoft Visual Studio Professional 2019 Version 16.4.4
• Intel(R) Visual Fortran Compiler 19.1.0.166

We do get the occasional crash (Studio hangs, then restarts or an exception dialog box appears). Solutions include:

1. Hide the Call Stack window (if breaking in a C++ function), or
2. Replace subprogram parameter fixed array dimensions with (*), or
3. Disable the Fortran Expression Evaluator extension

#3 always works, but debugging Fortran code is then a bit of a pain.

Brian.

[JohnNichols]

crashes when it either reaches a breakpoint in the Fortran code,

yes I have been having this problem with a recent ODE program, I stopped using breakpoint instead I  put in write statements, it is old school but stopped the problems.  It is annoying when the program just disappears. 

[AONym]

i found a work-around to the crashing at breakpoints.

The Linker was linking to some XE2019 libraries, rather than XE2020. Using VS, this happens because the library directories are specified as, e g, "$(IFORT_COMPILER19)redist\intel64\compiler" (the $() indicates a macro which is substituted for, so this example expands to "C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.5.281\windows\redist\intel64\compiler").

Installation of XE2020 does NOT change either the macro used, or its definition; you must do this manually for every configuration of every project.

To continue the example, I changed IFORT_COMPILER19 to IFORT_COMPILER20 in the C++ (main) project.

I also changed, in the Fortran library pages, under Configuration Properties/Fortran/General/Additional Include Directories
C:\Program Files (x86)\Intel\Composer XE\mkl\include\intel64\lp64
to
$(IFORT_COMPILER20)mkl\include\intel64\lp64

With both these changes,the linker uses mkl from the 2020 directory, and does not crash at breakpoints. Unfortunately, this may just be due to the slight changes in the length and position of code in the executable due to the different compile/link options. But at least I can get some work done while it lasts.

[AONym]

An additional change: In the solution properties, under Configuration Properties/VC++ Directories/General/Library Directories, I changed IFORT_COMPILER19 to IFORT_COMPILER20. This change got rid of the remaining XE2019 libraries being linked to.

My solution still has an inherited library directory $(IFORT_COMPILER17)\compiler\lib\intel64 on this page, but the explicit IFORT_COMPILER20 library takes priority. I have not yet found where the "17" value is coming from.

[Brian_Francis]

With the Visual Studio update to 16.4.4, VS now always crashes when setting a breakpoint in Fortran code.
So I am back to where I was last August.
The only workaround is to disable the Intel Fortran Expression Evaluator, which makes debugging Fortran code very difficult.

This is really quite unacceptable.

[Steve_Lionel]

It is probably something your particular application is doing, possibly in conjunction with wrong debug info generated by the compiler. It is certainly not the general case that the debugger dies when setting or reaching a Fortran breakpoint.

If you have an example where this doesn't work, submit it to Intel.

[FortranFan]

Brian Francis wrote:

.. This is really quite unacceptable.

@Brian Francis,

For whatever it's worth, a team I had previously worked with employs a lot of mixed-language (.NET, managed/unmanaged C++, etc.) solutions and projects and also have some Fortran DLL projects.

The team's position is they need to keep up with Visual Studio (VS) 2019 update and developer feed back is Intel Fortran integration in VS is most difficult to manage.

And there is extreme, extreme dissatisfaction that when installation and set up is finally worked out, there is still the glaring gap many of the data structures show up as "undefined pointer/array" in VS debugger and tricks are needed to "view" and work with such data in the debugger without which developer productivity is severely impacted when there are issues with Fortran DLLs - see Quote #10 in thread https://software.intel.com/en-us/node/820728#comment-form.  Given almost all the developers work with other languages way more than Fortran, such tricks don't come naturally to them, these tricks aren't retained in team "memory", basically there are problems galore working with Fortran.

My own impression (I may be wrong) is little to no improvement in facilities in Intel Fortran integration with VS have been made by Intel for many product cycles now, the "undefined pointer/array" issue I mention above has been around for years, based on what I recall.  Is this acceptable for a commercial product is something to think about.

[JohnNichols]

FortranFan wrote:

Quote:

Brian Francis wrote:

.. This is really quite unacceptable.

@Brian Francis,

For whatever it's worth, a team I had previously worked with employs a lot of mixed-language (.NET, managed/unmanaged C++, etc.) solutions and projects and also have some Fortran DLL projects.

The team's position is they need to keep up with Visual Studio (VS) 2019 update and developer feed back is Intel Fortran integration in VS is most difficult to manage.

And there is extreme, extreme dissatisfaction that when installation and set up is finally worked out, there is still the glaring gap many of the data structures show up as "undefined pointer/array" in VS debugger and tricks are needed to "view" and work with such data in the debugger without which developer productivity is severely impacted when there are issues with Fortran DLLs - see Quote #10 in thread https://software.intel.com/en-us/node/820728#comment-form.  Given almost all the developers work with other languages way more than Fortran, such tricks don't come naturally to them, these tricks aren't retained in team "memory", basically there are problems galore working with Fortran.

My own impression (I may be wrong) is little to no improvement in facilities in Intel Fortran integration with VS have been made by Intel for many product cycles now, the "undefined pointer/array" issue I mention above has been around for years, based on what I recall.  Is this acceptable for a commercial product is something to think about.

Sorry for laughing, but my IT people just said I can no longer use SQL Server or MySQL as they represent a security risk.  I use these with my Fortran programs.  

The IT guy just came to install fileseek on my work computer - he could not as he was locked out of admin privilege's. 

He also said using winareotweaker to flip the registry switch to show the winver on the desktop was an unacceptable risk. 

Where the heck is Heinlein when you need to keep humour in the face of this stuff. 

I am waiting for Alexa to say -- there is a 10% chance you will get sick today and the security people require you to stay in bed. 

[AONym]

I discovered something else that may be the cause of the "crash at breakpoint" problem. I was almost out of stack reserve. Perhaps the crashes at breakpoints occur because the Fortran IDE integration is trying to use additional stack. I haven't seen any breakpoint crashes since I upped the reserved stack. Of course, Intel should be checking for adequate stack when it reaches a breakpoint. I have also noticed that when entering a subroutine without enough stack, Intel does cause VS to issue an exception, but then if you tell VS to debug, your pgm is just terminated.

[jvandeven]

I have a VS 2019 mixed-language solution (Fortran, C++, C, C#) that is organised into separate projects for each programming language.  The IDE for this solution fails almost every time I launch the debugger.  A reliable work-around that I am using is to open language specific projects as separate solutions, and run the debugger from there.  This is obviously only useful if your development problem can be divided into language specific tasks, but is otherwise a fairly low cost way of carrying on development. 

[McWilliams__Steve]

Hi.  I used Visual Studio 2010 and Intel Fortran 2011 for years, all good.  Until a few months ago, when IT said "no more".  I upgraded to Fortran 2020 and Visual Studio 2019.  I think the "professional" edition of VS?  Or enterprise?  Not sure.  MS is sure to confuse things...

Anyways, after upgrading, Visual Studio would crash while debugging.  Built and ran just fine, both debug and release, but crashed when I hit a breakpoint and I tried to display variable values.  I tried all sorts of stuff these past few weeks, nothing worked.  Every time I'd install a different version of Visual Studio, I'd just rebuild, using the same project and solutions files that I've used for years.  Today, I deleted those project and solutions files, and remade them.  Kind of a pain, you gotta go thru properties and set everything all over again.  But after I did that, things are now working!

It didn't occur to me to NOT just keep using the same project and solution files.  Maybe you are also using the same ones?  Maybe my problem isn't even related to yours.  But if you haven't tried to delete and recreate these files, I'd give it a go.

Good luck!

[jimdempseyatthecove]

>>Until a few months ago, when IT said "no more".

IT is supposed to keep your system running for its users. Obviously, they've failed in this respect.

Demand that they fix it (or retrograde your tools). This exercise will help them to appreciate the problem they have caused.

Jim Dempsey

[JohnNichols]

I was looking for something old, when I stumbled on this old comment from Jim D

IT is supposed to keep your system running for its users. Obviously, they've failed in this respect.

Demand that they fix it (or retrograde your tools). This exercise will help them to appreciate the problem they have caused.

IT people believe that they run the world and you shall not do anything to move outside their rules.   You cannot argue with them nor win.  It reminds me of ministers in the 1960's they were always correct.  

[mecej4]

It could be quite useful to have pairs (failed, successful) of project files from which one may attempt to diagnose the reasons for failure. That is, instead of deleting an old project file, quarantine it before creating a new one. Later, compare the old project file with the new project file. Can you (Steve McWilliams) provide a few such pairs? Thanks.

[CKE]

CKE wrote:

My team and me are having the same issue for mixed language software development with Fortran/C and C++. Using

Microsoft Visual Studio Professional 2019 Version 16.4.3

Intel® Parallel Studio XE 2019 Update 5 Composer Edition for Fortran Windows* Integration
for Microsoft Visual Studio* 2019, Version 19.0.0052.16

the projects compile and link without problems and have no runtime errors.

If debugging of a Fortran application is started in Visual Studio then it freezes and is closed after some seconds. As mentioned above, the Expression Evaluator might trigger this behavior. But I wanted to know, what is the root cause of this behaviour and is there any hope to get this fixed by Intel?

My team and me can debug mixed language projects again if using

Microsoft Visual Studio Professional 2019 Version 16.5.4

Intel® Visual Fortran Compiler - extension version 19.1.0055.16, Package ID: w_comp_lib_2020.1.216

Therefore the issue is solved for me, even if I don't know the root cause.

[Christian_D_1]

I've experienced exactly the same issue with VS 2019 16.5.4 and the latest update 16.5.5 and IVF 19.1.x. VS 2019 is crashing when starting debugging the  Fortran code.

[Andrew_Smith]

I have experienced crashing too. Not immediate crashing but a second or two after hitting a breakpoint. I have no longer eperienced the issue since I deleted all breakpoints. Adding fresh breakpoints works without crashing.

[Devorah_H_Intel]

Is this issue still happening with oneAPI 2021.4 compiler? Please provide the entire VS solution that illustrates the crash.