I've got some old (originally Fortran 77) subroutines that I've converted into a DLL that I am calling from Visual Basic 2008.NET SP1. I pass it several variables (some integers, floating points and one string) and it passes back an answer in one of the floating points and the string.
When I run the VB.NET application, either in the Visual Studio IDE or as a compiled executable, I sometimes encounter an error of 'ArithmeticException was unhandled' with a detail of 'Overflow or underflow in the arithmetic operation.' This error coincides with the call to the DLL. The odd part is that if I simply hit continue, the DLL returns the correct results.
Although not 100% consistent, it seems to happen mostly when one of the variables happens to be negative. In playing around, if I eliminate the string variable, I can't seem to make it crash. If I add three more dummy string variables, it doesn't crash. I've even tried passing back some arrays to see what was going on inside the DLL... adding three of them also seems to be successful.
Again, the odd part is that when it does error out, it always gives me back the correct answer on a second (re)try. To me, this seems like some sort of memory allocation issue and adding more variables to the call is simply shifting stuff around in memory and masking an underlying problem.
From VB.NET, all the numeric variables are passed ByRef and the string is passed ByVal (arrays were also passed ByVal)... it won't work any other way. I've checked to make certain the variables match in type in both Fortran and VB code... INTEGERs are Integers in VB (and I've tried declaring them as Short too, just to see) and REALs are Single in VB.
Anybody have any ideas as to what may be happening?
Tim