none
exit() in a C DLL closes the invoking application. How to fix this RRS feed

  • Question

  • I have a c code that I compiled as a dll and I'm running it in C#.

    some of the functions have exit(0) as a way of termination, and when I run my entry function, eventually the dll terminates the whole parent app. Is there a way to "soft" exit the dll? 

    4 example is there a way to "bubble up"/force the "return 0" to the entry function from one of the child functions in the dll? 

    or something that would function as "Throw "0" so the C# would be able to consider that function complete?

    that would save me a lot of time without having to worry with threading and async await back in the C# code. 

    thanks for helping out

    Monday, February 3, 2020 10:24 PM

All replies

  • I have a c code that I compiled as a dll and I'm running it in C#.

    some of the functions have exit(0) as a way of termination, and when I run my entry function, eventually the dll terminates the whole parent app. Is there a way to "soft" exit the dll? 

    4 example is there a way to "bubble up"/force the "return 0" to the entry function from one of the child functions in the dll? 

    or something that would function as "Throw "0" so the C# would be able to consider that function complete?

    that would save me a lot of time without having to worry with threading and async await back in the C# code. 

    thanks for helping out

    exit will terminate the calling application.  That is its purpose.  Refer to https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/exit-exit-exit?view=vs-2019

    Why do you call exit(0) from within the dll?

    Monday, February 3, 2020 11:47 PM
  • I think he is porting a C EXE to DLL to be called in C#, hence the question.

    The traditional way is to move all return values to "ref" or "out" parameters (i.e.: pointer to variables), then make the function returns "error code", and then define some error codes that indicates the caller should end the application.


    Tuesday, February 4, 2020 1:23 AM
    Answerer
  • Converting the exe to a DLL is obviously not as easy as you hoped. There might be an easy solution but the best way to solve the problem is to analyze the code and design something appropriate for the code. It is unlikely anyone can provide a good clear answer without a better and clearer description of the code. And my experience is that, like an iceberg, there is more beneath the surface that will sink you if you ignore it, so that is why I say you need to take a closer look.


    Sam Hobbs
    SimpleSamples.Info

    Tuesday, February 4, 2020 5:48 AM
  • I think he is porting a C EXE to DLL to be called in C#, hence the question.

    The traditional way is to move all return values to "ref" or "out" parameters (i.e.: pointer to variables), then make the function returns "error code", and then define some error codes that indicates the caller should end the application.


    If an error is so severe that an application should be terminated it seems unwise to simply return an error code to the caller.  The caller could then continue execution in an unstable environment and the results of further processing could be undefined or the application could crash later on at a location far away and unrelated to the actual problem code which complicates debugging.

    The OP must determine the reason why the code calls exit(0) to terminate processing.  If it is symptomatic of a severe and unrecoverable failure then there are other problems that need debugging.

    Tuesday, February 4, 2020 12:07 PM
  • Hi Lilith5th,

    Did you solve your problem? If your question has been answered then please click the "Mark as Answer" Link at the bottom of the correct post(s), so that it will help other members to find the solution quickly if they face a similar issue.

    Best Regards,

    Xingyu Zhao

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, February 13, 2020 9:01 AM
    Moderator
  • These were the dates where SEH was not a thing, and it was also considered a rude thing for library code to intentionally crash the main process, as not only the memory it allocated would not be freed (this is better recently since Windows now keep track of memory resources and will free the memory owned by terminating process automatically), there were a lot of hardware that will refuse to work if the process previously holding handle to it don't free it (and this is still true for a lot of hardware today).
    Friday, February 14, 2020 2:54 AM
    Answerer