ifort/ifx debugger native only prevents Mixed mode choice problem in mixed dll debugging

[MWind2]

#include "pch.h"
#include "framework.h"
#include "cmix.h"
using namespace System;
using namespace  System::IO;
#pragma managed
void dfilen(double* ad, int isz) {
    StreamWriter^ SW = gcnew StreamWriter("dfile.txt");
    for (int i = 0; i < isz; i++) {
        String ^ sout = (ad[i].ToString("F2"))->PadLeft(10)+" ";
        if (i>0 && (i%8==0))SW->WriteLine(sout);
        SW->Write(sout);
    }
    SW->WriteLine();
    SW->Close();
};
//
#pragma unmanaged
// This is an example of an exported variable
CMIX_API int ncmix=0;

// This is an example of an exported function.
CMIX_API int fncmix(void)
{
    return 0;
}

// This is the constructor of a class that has been exported.
Ccmix::Ccmix()
{
    return;
}
#pragma unmanaged
extern "C" CMIX_API void dfile(double* ad, int isz) {
    dfilen(ad, isz);
};

C++ native/clr dll debugger in Mixed mode does not hit clr breakpoints when called from Intel Fortran - Developer Community (visualstudio.com)

C++ native/clr dll debugger in Mixed mode does not hit clr breakpoints when called from Intel Fortran. I have yet to test from a native c/c++ exe with native debugger selected.

It does the same thing with c++ native exe with Native debugger chosen for exe and dll debugger Mixed.

[Steve_Lionel]

This is not the "ifort debugger" doing this, as you demonstrated. An ifort executable can call only a native DLL, and even if there is a CLR DLL in there somewhere, the native Microsoft debugger won't break in it, at least that was my experience. You could experiment with calls to the Windows API routine DebugBreak where you want the breakpoint to see if that does anything.

[MWind2]

I wonder if it possible to allow choice by Intel for Mixed debuggers, or if as the Microsoft problem report, Microsoft could "scope" debugger use.

[MWind2]

In the interim I guess one could do no clr cpp exe and choose mixed debugger for it so the dll mixed would work, and then debug the managed "completely" before using with Fortran.

[Steve_Lionel]

Intel has no control over this. They simply provide a "Fortran Expression Evaluator" to the debugger, which is called when needed. Otherwise, the debugger is all Microsoft.

[MWind2]

The only reason why I thought Intel might be able to fix is that it would seem they provide the Fortran project VS integration, only Native is listed.  If there were no problem allowing the Debugging Type Mixed (.NET Framework) , perhaps they could make it a choice.

[jimdempseyatthecove]

What you might try as an experiment, is in the debugger, place a breakpoint in the Fortran code on the CALL to the DLL.

When at breakpoint, open a disassembly window, click on the current statement in the disassembly window (iow set focus within the disassembly window), then use Step Into through the argument pushes (if any), and into the called procedure.

Also watch the Output window. 

What should happen is you reach into "a" DLL.

*** This will be the DLL that got loaded, which is not necessarily the one you intend to load.

*** IIF this is the 1st call into the DLL, the full path of the DLL will be listed in the Output window of MS VS (not the CMD window).

FWIW

If your solution has a (C++) project that builds the DLL along with the Fortran code, you may find that the DLL that gets loaded is not the one that is in your solution. For example, you are building a Debug build, but the Release version of your DLL gets loaded, .OR. some other DLL gets loaded. In this case, any break point you set in your Solution's DLL won't trip (as your DLL wasn't loaded).

Jim Dempsey

[MWind2]

In the regular Native debugger with Fortran(and c++), I would always hit the unmanaged breakpoint in the dll(Debugger chosen as Mixed), but the managed breakpoints are never hit(unmanaged calls a managed function). The managed function is executed without stopping at breakpoints in it.

[MWind2]

I found a hack that borders on sad.

First, put a native function in the dll to Sleep(30000)

extern "C" CMIX_API void wait30(void) {
    Sleep(30000);
};

Add wait30 call to beginning of body f2mixnetx:

call wait30()

Fill in Attach to process:

Attach to: Managed(.NET 4.x) code, Native Code
filter: f2mixnetx

Start without debugging f2mixnetx.

Attach to f2mixnetx.

Hits breakpoint of native Fortran call to dfile, and then breaks on breakpoints in managed dfilen.

That such comes back to break in native Fortran makes me hope that an easy fix might be adding Mixed mode to Fortran choice for the debugger. Still in triage at Microsoft.

[MWind2]

if (i>0 && ((i+1)%8==0))SW->WriteLine(sout);
else SW->Write(sout);

cmix correction I missed.