F11 (Step into) is not working properly in Visual Studio 2022

[Jon_D]

Using F11 button in VS2022 to step into the LossDestination_New subroutine in the following code is not working properly.

IF (lSpillsDefined) THEN
  CALL  LossDestination_New(NDiver,iDiverIDs,iStrmNodeIDs,'Diversion','spills',InFile,Diversions%SpillSpecs,iStat)
  IF (iStat .EQ. -1) RETURN
END IF

Pressing F11 moves the yellow arrow to the IF (...) THEN line. Actually, I ended up pressing F11 200 times, before giving up, hoping one of the attempts will allow me step into the subroutine. Instead, I have to find the source code for the subroutine and do a "Run to cursor" action for a source line within that subroutine.

Below is the argument list for this subroutine:

SUBROUTINE  LossDestination_New(iNDiver,iDiverIDs,iDestIDs,cBypassOrDiver,cDestDescription,InFile,LossDestinations,iStat)
    INTEGER,INTENT(IN)               :: iNDiver,iDiverIDs(iNDiver),iDestIDs(:)
    CHARACTER(LEN=*),INTENT(IN)      :: cBypassOrDiver,cDestDescription
    TYPE(GenericFileType)            :: InFile
    TYPE(LossDestinationType),TARGET :: LossDestinations(iNDiver)
    INTEGER,INTENT(OUT)              :: iStat
END SUBROUTINE LossDestination_New

I have noticed that this happens with some subroutines but not others. And for some subroutines pressing F11 a manageable number of times will eventually step into the subroutine code.

Is this something that I can fix, maybe by changing some settings of Visual Studio, so that a single pressing of F11 actually steps into the subroutine?

Thanks for any help.

Jon

[jimdempseyatthecove]

A Step Into generally won't work for a procedure that does not have debug information.

An alternate way (works with procedures without debug information), is to open a disassembly window (keep that in focus), then issue F11 until the call executes. This will bring you to the entry point of the procedure. 

Would LossDestination_New be in a DLL?

Note, DLLdebug symbols are not loaded until the DLL is loaded. If this is the case, then the F11 should work the second and later times.

Jim Dempsey

[Jon_D]

Jim,

Source file for LossDestination_New is part of the Fortran project and is compiled under Debug configuration (i.e. debug information for it is available) along with the calling code.

Jon

[jimdempseyatthecove]

When you (with source window to LossDestination_New closed), then Debug with break at call, switch to Disassembly window Step Into, does a source window with LossDestination_New open?

Does setting scope to source window, and F10 advance a statement in the source window?

One potential issue is the Object file being loaded is not the intended one being compiled.

For example, you are including an older library file with that routine (w/o symbols) before the intended object file.

Another example is in the Configuration Manager, assure that the Build check box is checked for the 

Project + Configuration + Platform you are building for your debug session.

I've experienced similar problems with both those configuration errors.

Jim Dempsey

[Jon_D]

Jim,

I am not sure how it is possible to have an older Object file. I have a single Fortran project with the calling source line in file Class_Diversion.f90 and the LossDestination_New subroutine in the Class_LossDestination.f90 file (see figure below). I do not have  separate projects for dynamic or static libraries. If there are any code changes in any of these two files, the project gets compiled automatically. Under Debug configuration all source files are compiled with full debug information generated.

Regarding your questions:

1. Yes, I am able to F10 and step over the CALL LossDestination_New(...) line without any problem.

2. When I break at the CALL, and switch to Disassembly window, I see the assembly code (see below) and subsequent F11s go through the assembly code line by line, but the actual source file does not open up.

   

Jon

[andrew_4619]

Individual source files can have individual compile commands that override the project defaults. Right click and check properties of the file in solution explorer to ensure you have debug info.

[jimdempseyatthecove]

>>but the actual source file does not open up.

You F11 through the assembly (of the caller) until the call, then the next F11 takes you to the entry point of the callee, at this point the source file should open.

As @andrew_4619 points out, you should, in the Solution Explorer, select the source with the problematic issue, and verify that the debug information is selected to be generated.

Note, individual files that have compiler options that differ from the Project default options will show a colored "tick" mark

that DMOUSE uses project default options, DOSTOP has alternate options

Jim

[Jon_D · Accepted solution]

Well, my issue is magically solved.

I updated my Visual Studio 2022 to its latest version (17.12.4) , cleaned the project and recompiled; no changes to the project settings (i.e. the problem source file never had special settings that prevented the compiler from generating the debug information for it) . And now, I am able to step into the subroutine.

I suspect the clean operation did the trick. I normally don't use "clean" assuming the compiler will detect any changes to the code automatically and recompile, but it looks like it is a good idea to use it once in a while. 

Thanks Jim and andrew_4619 for your time.

Jon