c# console application silently exits RRS feed

  • Question

  • I have a small c# console application that use a 3rd party lirbary to read data and store into Oracle.

    It works in local environment. Once it got deployed into prod, it works partially(consistently after processing fixed number of files) and exits the execution without catching any exception or finally block.

    Could you help me with this catching the exception?

    Best regards

    Monday, February 12, 2018 5:24 PM

All replies

  • There are many possibilities. If all code using the third party library is within the try block and nothing is being caught, then it means the library is not throwing any exceptions or at least any that you can catch and trace. Since I don't have enough information to come to any conclusions on what you should do, I cannot give you a definitive answer. However I would imagine that it has to do with something that changed when the app was deployed into production such as a different build setup, or configuration, causing incompatibility for certain files. Wish you the best of luck! 
    Monday, February 12, 2018 9:14 PM
  • I know it is very broad question but I am not doing anything unusual. I am reading files and storing data into a database.It works for few number of folders and consistently it crashes after certain number of folders. It works in every other local envt except in prod envt or neither I never heard this kind of crash. I would like to understand if any possible scenarios where c# can't catch exceptions or even skips finally block. It is not even logging anything in event viewer about any abnormality.
    Tuesday, February 13, 2018 7:00 AM
  • You don't show your code; do you have a try/catch around everything in main()? Something like

    static void Main(string[] args)
        catch(Exception ex)
        Console.WriteLine("Done; press any key");

    Tuesday, February 13, 2018 9:29 AM
  • Hi, Thank you for this.

    The code is spanned into multiple methods although the purpose is just to insert data into a db from files. Here is the place it occurs. This try block gets executed for about 5000+ times(consistent number) and then the statement faces some issue and it crashes the entire application.

                        dbbFCursor.Flush(); // Commit data

                    catch (COMException comEx)
                        Console.WriteLine("Error in flush::" + comEx.Message);

    Tuesday, February 13, 2018 3:02 PM
  • Modify your code as follows.

       //Do stuff
    } catch (Exception e)
       //Consider writing out call stack and whatnot as well

    Then wait for the crash. When it crashes look at the exception and post the error info. It sort of sounds like you might be running out of memory which will cause a fast fail but you have to start somewhere. Also note that Windows will record the crash using WER so you have that info as well.

    If you're using COM and that is happening on another thread then the domain may be crashing. You might also need to hook into the domain's unhandled exception. This should occur early in your app though (main is a good spot).

    Michael Taylor

    Tuesday, February 13, 2018 4:28 PM
  • Hi,

    Thank you for pointing me towards WER file. Below is the content that is available regarding the silent crash.


    Remaining all are the dlls that were loaded. Could you help me if there is a way to find the reason from above exception trace

    Some more content from WER file is below

    Sig[0].Name=Problem Signature 01
    Sig[1].Name=Problem Signature 02
    Sig[2].Name=Problem Signature 03
    Sig[3].Name=Problem Signature 04
    Sig[4].Name=Problem Signature 05
    Sig[5].Name=Problem Signature 06
    Sig[6].Name=Problem Signature 07
    Sig[7].Name=Problem Signature 08
    Sig[8].Name=Problem Signature 09
    DynamicSig[1].Name=OS Version
    DynamicSig[2].Name=Locale ID

    Best Regards

    • Edited by suryahon Tuesday, February 13, 2018 7:53 PM
    Tuesday, February 13, 2018 5:59 PM
  • That isn't sufficient information to reveal the issue.  The only thing it is saying is that it is failing in the CLR and that it looks like you're using .NET 2.x. Are you?

    If you're getting the WER dialog to pop up then one of the links on it should be to "technical details". If you click that then it should show you the path to the dump file. Before closing the dialog go grab the dump file and copy it locally. Then load the dump file into VS and you'll get more information. 

    This is all assuming that you simply cannot update your try-catch as mentioned earlier and then rerun your code and replicate the issue. Ideally replicate it in the debugger so you can easily debug the issue.

    Michael Taylor

    Tuesday, February 13, 2018 6:11 PM
  • Hi,

    I am forcing to use 3.5 using below setting just to make it won't use any other framework.

    <startup><supportedRuntime version="v2.0.50727" sku="Client"/></startup></configuration>

    Only place I could see the error is in WER(Thank you for pointing me to the location) otherwise till now it has been silently dying without showing any crashing window and without printing any error into console. 



    Tuesday, February 13, 2018 7:46 PM
  • Hook up to the AppDomain unhandled exception event that I mentioned earlier. It is possible the exception is occurring on a secondary thread and therefore your catch wouldn't work. Note that if you update to CLR v4 later you'll need to make some additional changes to ensure your handler is called.

    The event is raised before the app terminates if the exception wasn't already handled elsewhere. At the point the event is raised you are on an undefined thread so don't reference anything that requires a specific thread. You are also effectively in an unknown state so don't try to do anything fancy like reference other objects or even allocate memory (if possible). Your app is going to terminate and there is nothing you can do about it. The best option is to simply log the exception. In the case of your console app you might be able to display a message in the console and possibly even use ReadLine to block the termination but I haven't tried it.

    Ideally though you should be able to replicate this in the debugger and so you'll have access to the entire exception object. Have you tried replicating it in the debugger?

    Michael Taylor

    Tuesday, February 13, 2018 8:36 PM
  • Hi Thank you for this.

    I tried most of these ideas. Something fundamentally wrong with those servers that are there in data centers or .net itself. I can't believe it can bypass all sorts of exception handlers and even event viewer couldn't catch the crash. It just silently leaves the execution. It won't even popup a regualar crash window with windows OSs.

    Thursday, February 15, 2018 3:25 AM
  • Could somewhere in the code be calling Environment.Exit()?
    Thursday, February 15, 2018 3:32 AM
  • Note that this behavior is consistent between all kinds of computer systems, no matter it's Windows or *nix, as long as the parent thread and child thread can run on different "run / schedule" (that's the point of multithread programming where a task can be offloaded to different cores, but it's not uncommon they're both assigned to the same core and the CPU choose to either

    1: pause the parent thread and let child thread to run to completion, so it's possible for the parent thread to handle exception thrown by the child;

    or 2: pause the child thread and let parent thread run to completion, in this case the parent thread does not exists anymore, and any error processing code in there has already been torn down.

    You will need to write code to handle this.

    Thursday, February 15, 2018 3:36 AM
  • You said WER was reporting the error. Are you saying that it now isn't? You mentioned data center - is this a web app or something hosted by a cloud server? Can you post the updated code after you've made the changes mentioned earlier.

    Do you have access to the remote server so you can get the crash dump files? 

    Michael Taylor

    Thursday, February 15, 2018 4:40 AM
  • Hi, Not that I know of unless 3rd party library has it. But it never happens else where.

    Is it possible some memory overflow can't be caught by applications and windows kills the process.

    I don't see any memory or cpu spikes also in task manager.



    Thursday, February 15, 2018 6:11 AM
  • Thank you for this.

    I will try in those lines.

    Below setting has anything todo with c# applications to fail after some duration. It fails exactly after certain number of transactions and then I restart the app, it works. I have few options as of now at DCE.


    Thursday, February 15, 2018 6:52 AM
  • Only once that WER got created because i used the windows diagnostics tool to launch the tool and copied the log in previous post. Yes the location is a data center where they create virtual machines with generic configuration.Actual app is a web app but it couldn't finish the processing. So I created a sample script with a console app and trying to test it.
    Thursday, February 15, 2018 9:19 AM
  • I'm not aware of any situation in which Windows won't log an app crash in the event log. What does the event log say? Note that for web apps it'll show up as WAS or the w3p process. But for the console app it'll show up as your app's name. For a .NET app it should show you the exception details as well.

    Not sure why you posted the screen about the paging file. The only thing I see odd there is that you have only 9GB free and you're using a fixed page file of 4GB. In general, at least with all newer versions of the OS, you should let Windows manage the page file. Managing it manually was an old school technique that isn't needed anymore and will most likely have a negative impact on performance. But none of this is likely related to your issue.

    Michael Taylor

    Thursday, February 15, 2018 3:04 PM
  • Hi All,

    Finally I am able to break the code when exception occurs.

    Below is the exception. Could you help me to interpret it?

    First-chance exception at 0x772dc54f (KernelBase.dll) in ArcObjectsTest.exe: Microsoft C++ exception: FNPNS::TSM::CDoesNotExistException at memory location 0x0020afbc..
    • Edited by suryahon Monday, February 19, 2018 10:51 AM
    Monday, February 19, 2018 9:06 AM
  • So the issue is in your C++ code (the third party library?). The exception says something does not exist so you'll need to look at the COM code and figure out why it is failing and correlate that back to the data your passing it (if any). Dropping the PDB of the library into the output folder may give you line information. Otherwise you'll have to look at the call(s) you're making into it and then go into the library code to find where it throws the CDoesNotExistException exception.

    Given that you said the code works for a while I can only assume the correct client is installed and that your TNS entries are correct. If you're successfully saving data then this is true. However if you're bouncing between TNS entries or you haven't successfully written any data yet then I'd lean toward a bad connection. If the data is successfully saved but you're running different queries each time then I'd point toward a bad query.

    Looking at your original code again I also find the finally block suspect. Does the COM object not implement IDisposable? If so then get rid of the finally block and just use a using statement. Given the fixed # of iterations I wonder if you're running out of memory because of the COM objects. You might need to run the profiler to ensure the COM objects are getting properly cleaned up.

    Michael Taylor

    Monday, February 19, 2018 4:56 PM
  • Hi, Thank you. All your assumtions are correct.

    1. TNS names are correct

    2. Data saves correctly till few thousand(fixed) iterations

    3. Those libraries work in other local environment even if it is lower or poorly configured machine.

    Lastly, do you see anything wrong with Windows OS and formatting everything and reinstalling works fine. Then hesitation comes what if the memory pointer(from exception message) is related to the Oracle location which is in Linux). Could you suggest me direction based on this?

    Best Regards

    Monday, February 19, 2018 5:14 PM
  • Please consider that they are all just virtual machines just wondering if anything could go wrong with memory locations.
    Monday, February 19, 2018 5:17 PM
  • Memory locations? Unlikely. The exception is a C++ exception that someone is explicitly throwing. By default a memory error in C++ would simply crash the app. The exception you're getting is one that somebody explicitly created and is looking for. They are trying to tell you something does not exist. Since I don't have the third party library nor can I see what your code is doing it would be very difficult to track this down mentally. Unfortunately I think you're going to have to take a closer look at that exception. Look at the exception details and call stack to see if there is anything useful. With a PDB you'd at least have a callstack that would identify the function(s) failing. You might also need to contact the library dev to see if they can help you out. They could very well have an issue in their library.

    Michael Taylor

    Monday, February 19, 2018 5:23 PM
  • Ok.

    I won't be able to get PDB file due to they came as part of installer and we only reference the libraries in the projects

    I ran  SFC.exe tool  to see if any file system got damaged or something to recover based on suggestions on internet.

    Now it throws exceptions much prior in the project at initiation. That tells me to assume something is wrong with file system

    First-chance exception at 0x7676c54f (KernelBase.dll) in ArcObjectsTest.exe: 0xE0000001: 0xe0000001.



    Monday, February 19, 2018 5:31 PM
  • Hi suryahon,

    >>First-chance exception at 0x7676c54f (KernelBase.dll) in ArcObjectsTest.exe: 0xE0000001: 0xe0000001.

    The exception is pretty general and can be caused by many things. 

    Please connect your developer to ask for PDB file.

    Best Regards,


    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

    Friday, March 2, 2018 8:04 AM