none
Using a FORTRAN .dll from c# problem on some computers RRS feed

  • Question

  • Hellow ,

    I am calling several functions which are within a fortran .dll from  c# code.

    On some computers it all works just fine and there is no problem.

    On some other computers the moment i call the first fortran function, my application get stuck. I can see in the windows device manager 50% cpu.

    All the computers configuration are the same : Windows7 SP1 , 32bit.

    My application is compiled for 32bit , using Visual2008.

    The more strange thing is that if I remove some code from a fortran function , whichis not the one that get stuck on(and is also not called by the one that get stuck) , than it is all OK on any computer.

    Does someone have any idea ?

    Thansk.

    Wednesday, November 28, 2012 4:24 PM

All replies

  • Hi Eran,

    Welcome to the MSDN Forum.

    How about the environment? Are they the same?

    Base on so little information, I have no suggestion.

    You need to check the function of the code your removed. 

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, November 29, 2012 10:24 AM
    Moderator
  • Hi Mike ,

    As I wrote , I am calling to function_1 and it get stuck. if I remove function_2 , which I dont even call , it doesnt get stuck. what is the relation in fortran between functions in the code (and again , the one i have removed is not even called).

    10x .

    Eran.

    Friday, November 30, 2012 9:31 AM
  • Hi Eran,

    Based on my known, the function_2 has refereed unavailable references. So when the application runs, it will try to load the reference or resource first. 

    To isolate this issue, you need to try different function_2: with body, without body, with just a few simple statement and so on.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, December 3, 2012 6:54 AM
    Moderator
  • Hi Mike ,

    1. As I am not a "Fortran-Person" :) , what do you mean by unavailable refrences ?

    2. And why does it work on some computers and on some it get stuck ?

    10X ,

    Eran.

    Monday, December 3, 2012 11:39 AM
  • Does the Fortran DLL come with any instructions in regards to calling conventions? Different languages have different conventions for putting data on the stack for method calls, and as I recall Fortran is usually differnet than the C default.

    "Premature optimization is the root of all evil." - Knuth

    If I provoked thought, please click the green arrow

    If I provoked Aha! please click Propose as Answer

    Monday, December 3, 2012 11:43 AM
  • Hi Eran,

    >>what do you mean by unavailable references ?

    Maybe a fortran API, maybe some system resource such as serial port, network, just a guess. I know nothing about your function_2.

    >>why does it work on some computers and on some it get stuck ?

    This is why I asked you in my first post: How about the environment? Are they the same?

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, December 4, 2012 5:13 AM
    Moderator
  • Hi Mike ,

    The only system resource used by function_1 is the file system. but why does it matter ? I am not calling  to that function.

    The system environments are the same : Windows7 SP1.

    Thanks ,

    Eran.

    Tuesday, December 4, 2012 9:53 AM
  • I have just
    found some new information:<o:p></o:p>

    1. It happens
    also when compiled with the library, not only as a dynamic load.<o:p></o:p>

    2. The computers which it is OK - corei5

        The computers which it gets stuck - core2<o:p></o:p>

    Any suggestion?<o:p></o:p>


    Sunday, December 23, 2012 7:27 AM