Internal write chrashes the DLL

Internal write chrashes the DLL

I am programming with VB.NET (VS .NET 2003). My VB-application makes calls to many external FORTRAN-routines. I collected these FORTRAN-routines in two DLL's, the simulation- and graphic-module.
The graphic module does some drawings using the DC of a picturebox control. I use an internal write to put some numbers on the axis and the graphs. It looks like:

WRITE(strText,'(F7.2)') xmax

Everything worked fine using CVF 6 + VB 6 and also using VB 6.0 and IF7/8. Now I am using IF 9 and VB.NET. My VB.NET application crashes right during the internal write with

System.NullReferenceException: Object reference not set to an instance of an object

Does anybody have a hint for me.

Many thanx in advance


Message Edited by OliverK on 03-02-2006 05:55 AM

33 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It could be that the string is not being passed properly from VB to Fortran. Intel Fortran and CVF have different defaults as to where character lengths are passed, but if you converted the project from CVF, you should have /iface:mixed_str_len_arg to override that.

I suggest stepping into the function ith the debugger and verify that all the arguments are correct.

Retired 12/31/2016

I gave too less information, sorry about that

strText ist declared in the FORTRAN-Module as

CHARACTER*25 strText

and I also checked that xmax is always suitable with the format specifier (i.e '(F7.2)')

Meanwhile it seems to be an installation problem of VS.NET 2003 on my computer. Because the next point is, if I try to debug the fortran dll's on my computer, I always get a message about "Unmanaged Debugging Not Available".

Using an other computer everything is working fine, also the debugging of the dll's.

Thank you very much for your help, I am going to kill my computer right now :-)


Isn't there a switch "Allow unmanaged debug" somewhere on VB project properties? It's possible that it's not a part of .vfproj file, but should be set up for every individual project (i.e. you can't carry it to another computer).

Is strText a local variable or a dummy-argument? If the latter, fixed-width declaration CHARACTER*25 smells like trouble...


Hurra, my partner got the problem on his computer now too. So the problem seems to be alive. He guesses it could be the .NET-garbage collector. We will work on it. If we find a solution, I am going to post it here.

To Jugoslav: I did set the switch "Allow unmanaged debug" in the VB-project.

strText is a local variable inside the dll

I do not pass any text strings from VB.NET to the Fortran-DLL's. I have read all the mesages about passing arguments from VB --> Fortran and vice versa in that forum. It is a really good source.

I also checked my passed arguments inside the dll's using the debugger, therefore I am quite sure, that there is no mistake in passing arguments.

Hi, I have been trying to port some qwin subroutines from CVF 6.6c (where they work fine) to Intel V9.0 and have seen the same problem with the formatted internal write. I found that if I use a listdirect i.e. write(text,*)x instead of write(text,'(G11.4)')x it works, although I really want the text string to be formmatted. Please email me if you find a work around. In the mean time I going to write my own conversion routines.

Thank you.


Please send a test case to Intel Premier Support. If there's a bug to be fixed, we want to fix it.

Retired 12/31/2016

Hello, Steve.

I have been trying to reproduce this errror in a code fragment without any success. The code that I'm having trouble with is about 4000 lines long and is very convoluted, many recursive calls and a lots of pointers. I have also tried to use a formatted write statement to a scratch file and got the same error on the write but if I use list direct I don't get the error writing to the file. Give me a couple of more days to see if I can reproduce it in a code fragment, if not I will send the subroutines with a driver program.


... we still working on it:

We have 5 different computers:

1: Celeron D 2.8 GHz: no problems

2: Pentium 4 2.4 GHz: no problems

3: PIII 1.3 GHz: System.NullReferenceException

4: AMD XP 2400+: no problems

5: AMD XP 2500+: System.NullReferenceException

(a week ago I had the problem on #2)


If I substitute

WRITE(strText, '(F7.2)') xmax

with (xmax is in this case xmax = 234.45)

WRITE(strText,*) 234.45

the called graphic routine works 6 times fine and crashes within the 7th-call at the internal write statement with the described System.NullReferenceException: Object reference not set to an instance of an object

If I start the program again it chrashed within the 6th call.

and once again: within the 7th call and now it occurs stable at the 7th call

What could it be? Does anybody have an idea?


Message Edited by OliverK on 03-07-2006 07:20 AM

Message Edited by OliverK on 03-07-2006 08:47 AM

My guess is that you're corrupting the stack due to a mismatch between the caller and callee. Show the VB declaration of the routine and the corresponding Fortran declaration including any directives and argument declarations.

Retired 12/31/2016

Hello Steve,

many thanks for your fast reply. Here we go


Declare Function SiWaProGM_DrawIsoline Lib "SiWaProGM.dll" ( _

ByRef hWnd As Integer, _

ByRef IntegerVariables As typIntegerVariables, _

ByRef KX As Integer, ByRef x As Double, _

ByRef y As Double, ByRef z As Double, _

ByRef Normalized As Double, ByRef minNorm As Double, _

ByRef maxNorm As Double, ByRef xObs As Double, _

ByRef zObs As Double, ByRef yObs As Double, _

ByRef IsolineControl As typIsolineControl) As Integer

and the call

SiWaProGM_DrawIsoline(hOnlineFlowGrafikWnd, _

IntegerVariables, KX(0, 0), x(0), y(0), _

hNew(0), Saturation(0), minSat, maxSat, _

xObs(0), zObs(0), yObs(0), FlowIsolineControl)

in the Fortran DLL:

INTEGER FUNCTION SiWaProGM_DrawIsoline(hGrafikWnd, IntVars, KX, x, y, z, &

Normalized, minNorm, maxNorm, &

xObs, yObs, zObs, IsolineControl)



!DEC$ ATTRIBUTES ALIAS : 'SiWaProGM_DrawIsoline':: SiWaProGM_DrawIsoline





!DEC$ ATTRIBUTES REFERENCE :: Normalized, minNorm, maxNorm





USE GlobalConst

USE GlobalData

TYPE (typGrafikFenster), POINTER :: Grafik


TYPE (typIntegerVariables) :: IntVars


INTEGER, INTENT(IN) :: KX(IntVars%NumEl,4)

DOUBLE PRECISION:: x(IntVars%NumNP), y(IntVars%NumNP), z(IntVars%NumNP)

DOUBLE PRECISION:: Normalized(IntVars%NumNP), minNorm, maxNorm

DOUBLE PRECISION:: xObs(IntVars%NumPoints), yObs(IntVars%NumPoints), &


TYPE (typIsolineControl) IsolineControl

All these arrays do not have a fixed size. I use the ReDim statement within the VB main program for allocating the array size.
I also checked the numbers in my arguments for any mismatches, but I didn't find any :-(

Ok - that all looks fine to me. What is your setting for "Use run-time libraries" for the DLL project? I recommend "multithreaded DLL" (not any of the Debug variants).

Retired 12/31/2016

Right now, I have "Debug Single-threaded DLL". I gonna try the Multithread DLL ....

... still the same, after the 7th call the System.NullReferenceException occurs

I also think, that the problem is caused by a corrupted stack. The corruption occurs somewhere else in the DLL and will turn out later during the internal write to the NullReferenceException. The question is: How find the bug in the code?

I am really happy, that I am able right now to reproduce the error. So I can search for it. But on this machine (#3) the debugger is not yet available (unmanaged debugging not available).

I keep searching ....


There's a VB.NET project option to enable unmanaged code debugging.

Retired 12/31/2016

Debugging does not work on comupter #3 and I don't know why. I already reinstalled IF9, VS.NET 2003. But every time if I check the box "enable unmanaged debugging" (This is a translation from german --> english, I hope it meets that, what you see in the properties box of an VB.NET-project) and try to start the debugging, I get an error message "Unmanaged debugging not available".

Debugging the FORTRAN-DLL works on #2, but it don't have the problem there anymore ....


Interesting. I would suggest:

1. Uninstall Intel Fortran integration into VS.NET
2. Do a Repair/Reinstall of VS.NET (Add/Remove Programs, Change/Modify)
3. Reinstall Intel Fortran integration

See what happens

Retired 12/31/2016

Hello Steve,

1.)I uninstalled the Intel Fortran integration into VS.NET
2.) I did a Repair/Reinstall of VS.NET (Add/Remove Programs, Change/Modify)
3.) I reinstalled theIntel Fortran integration


and here are my results:

1.) debugging works fine (I should have known this, thank you)

2.) the System.NullReferenceException occurs now in my other DLL also within an internal write like


WRITE(Zeile, 1020)

1020 FORMAT('Der aktuelle Zeitschritt..')


Meanwhile I also found the older threads on the similar topic #8647 form 04-08-2004 and I am going to try, to link again against the multithread dll.

Please also make sure that you are using a current compiler (9.0.030).

Retired 12/31/2016

I downloaded .030 at 03-06-2006 and installed it also that day immediately after downloading.
Now I tried to link against the multithread dll (I also set the option "Use Common Windows Libraries" = NO) and got the System.NullReferenceException at its usual, formerly known place in the graphic-dll. But it occurred now not before the 286th call to the routine.

Another point: On this machine (#3, W2K) I do not need to have the libraries libifcoremd and libmmd in the same directory like the exe ( On the othercomputer (#2, WinXP) I need to have themin Could it mean anything else than a missing variablein the path environment?

The need for the DLL in the local folder is simply a PATH issue.

Here's what I would do. I would set a breakpoint in the debugger at the Fortran routine. When the breakpoint is reached, I would note the value of the ESP register (you'll need to view the Debug..Registers window.) Then let execution continue until the breakpoint is reached again. Ideally, the ESP value should be the same each time the Fortran routine is called, assuming it is from the same location in the VB code. If it is not, that suggests a calling interface error with adjusting the stack.

Retired 12/31/2016

The total simulation time of my case is 756, the time step is between 1E-4 and 0.5, the routine gets 3 times per time step called. After 10 min clicking I am getting tired and ESP is not changing.... :-(

Is there any other chance for tracking the ESP? For instance writing it to a log-file?

If ESP is not changing after several calls, then that probably isn't the issue. Though you can set a "stop after" count for the breakpoint of you want. Are you sure that the string you're writing into has the correct length?

Retired 12/31/2016

1.) I set the breakpoint at the first statement in the routine (line 23)

2.) the ESP was there constant at 0012B08C

3.) if the System.NullReference Exception occured at line (42) the ESP was at 0012AF7C (I guess it nothing unusual, if the stackpointer chnges inside a routine?


To your question: Since this error occurred I disabled all internal write statements and have only one left at line 42:

WRITE(strText, *) 234.45


1.) I set the breakpoint at the first statement in the routine (line 23)

2.) the ESP was there constant at 0012B08C

3.) if the System.NullReference Exception occured at line (42) the ESP was at 0012AF7C (I guess it nothing unusual, if the stackpointer chnges inside a routine?


To your question: Since this error occurred I disabled all internal write statements and have only one left at line 42:

WRITE(strText, *) 234.45


1.) I set the breakpoint at first executable statement in the subroutine (line: 23)
2.) the ESP was always constant at 0012B08C
3.) if the System.NullReferenceExeception occurred at line 42 the ESP was at 0012AF7C
I guess that is not an error if the stackpointer changes inside a subroutine?
To your question: After the error turned out, I disabled all internal write statements, except the one at line 42 in this module:

WRITE(strText,*) 234.45

where strText is a local variable declared with

CHARACTER*25 strText

It is normal for the stack pointer to change during execution of a routine.

Retired 12/31/2016

Hello Steve,

I still have my troubles with the internal write. I installed now the latest compiler version and I set my string variables (target and format string) to static (SAVE). But it doesn't help.

Does it help if I supply the debugger information as follows:

libifcoremd.dll!for_set_reentrancy() + 0x17f
libifcoremd.dll!for_set_reentrancy() + 0x31a
libifcoremd.dll!_fq_settextposition() + 0x7e9
libifcoremd.dll!for_write_int_fmt() + 0x23
>SiWaProGM.dll!OWS(TYPGRAFIKFENSTER * GRAFIK=0x100907e0, char [6]* FMTX=0x10090d4c) Zeile 41 + 0x72Fortran

No, it doesn't help. We would need to see a complete program that demonstrates the problem.

Retired 12/31/2016

I tried now to take the destination string variable(s) into/away the stack and declared them also as


but the error message keeps telling me:

System.NullReferenceException: Object reference not set to an instance of an objectI don not know now, where else to look for ...

Message Edited by OliverK on 05-16-200611:26 AM

You need to debug this and have the debugger break when an access violation occurs. That is probably what is resulting in the error you are seeing. I don't think anyone here can help you more without seeing the code in question.

Retired 12/31/2016

Finally after a lot of grey hairs more, I found the reason:

It was actually a statement

WRITE(strText,'(F5.2)') xmax

wherexmax = -1234.56

Thank you to all for your support

It sounds as if strText is intended to be a Stack local variable.

Depending on options, the array of characters might get compiled as a static array.

Try adding ", automatic" to the declaration which will force it to be on the Stack.

Jim Dempsey

Leave a Comment

Please sign in to add a comment. Not a member? Join today