1

In my development environment my application runs, then when I installed it in a client machine it is not starting, my only idea to see the reason was to show a message box with the exception:

AppDomain.CurrentDomain.UnhandledException
            += delegate(object sender, UnhandledExceptionEventArgs args)
            {
                var exception = (Exception) args.ExceptionObject;
                MessageBox.Show("El programa se ha detenido debido a un error interno: " + 
                       Environment.NewLine + exception.Message + exception);
                Environment.Exit(1);
            };

This shows the next message

Object reference not set to an instance of an object. controli.Program.Main()

I am familiar with that exception but not at Program.cs file, how is it possible that this fails in a client machine? And not in mine.

Finally I know about remote debugging but the problem is that it only allows to connect to a process has already started, and my application throws when loading

Do you have any suggestions or tools that I can use

Ňɏssa Pøngjǣrdenlarp
  • 38,411
  • 12
  • 59
  • 178
bto.rdz
  • 6,636
  • 4
  • 35
  • 52
  • 2
    Have you considered logging the exception to a file? Also, you'll get better information if you have access to the full stack trace rather than just the exception's message. – allonym Oct 04 '14 at 00:20

2 Answers2

4

Solution 1: Tell application to wait until you are ready

If it is possible to alter the application, you can set a named event, and wait for it. Then, create another application that sets that event. Then do the following:

  1. Start your application. It will wait for the event to be set
  2. Attach the debugger.
  3. Using the little application on the target system, set the event.

After that your application will continue executing and you will be able to debug it.

If you are unfammiliar with named events, have a look at this tutorial.

Solution 2: Add logging and exception handling

You can use a free library like nlog to add logging to the application. This will help you with the flow. You can also add try catch blocks and log the exceptions along with the stack at that point.

Note that even if your application uses multiple threads, nlog supports logging each one separately.

Odys
  • 8,951
  • 10
  • 69
  • 111
  • 1
    Mightn't it be simpler to just wait for System.Diagnostics.Debugger.IsAttached? – allonym Oct 04 '14 at 00:24
  • Cool little feature, thanks! – Odys Oct 04 '14 at 00:28
  • can you give me a clue @allonym, my question is because i dont know a tool to make this – bto.rdz Oct 04 '14 at 00:32
  • 2
    in the entry point of your application, before anything else, write a while loop until System.Diagnostics.Debugger.IsAttached becomes true. put a short wait inside the loop to keep it from spinning too tightly. This will give you an opportunity to attach the remote debugger; the loop will end once the debugger is attached. – allonym Oct 04 '14 at 02:05
0

There are just too many scenarios under which an application will run just fine in a development machine and fail to run at all or crash in others. Start by considering how the client machine's environment differs from your development environment. For example:

  • Are there security-related differences in both environments that could cause the application to crash in one and not the other?
  • Is the client's machine .NET installation and configuration in the right shape for your application?
  • etc.

About the right debugging approach, you should consider ways of inducing your application to create a minidump file upon crashing (see this question) and then using WinDbg + SOS to debug your application using VS (unless you're using Visual Studio 2013 Ultimate, in which case you might not need WinDbg/SOS at all).

Community
  • 1
  • 1
AFranco
  • 1