Troubleshooting a deployed c# program

I've been writing a c# program for the last couple weeks and the text build just got its final signoff. I published it via visual studio, sent the installer package to my client, and it simply does not work on their computers. I've installed the exact same binary on theirs that I have on my own for the sake of testing. It is a program that starts with a series of pop-up windows, and after the final pop-up, the program simply closes rather than bringing up mainwindow. I understand that without access to my source and my clients' computer troubleshooting is impossible, but frankly I don't even know where to begin with this one. Could I get some suggestions on what things to look at? We're both running Windows 7, and while I have the 64 bit edition I don't think that should make a difference, especially since the program starts running.

Any advice on where to start looking?

edit My solution depends on a custom control library which does not appear until the this.Show() command that (I'm guessing) the program fails at. Is there a way to check if that's somehow not being included but, since it was built on my computer, the reference is working there? I ask because 开发者_JAVA技巧the publish button just names my project and not the solution as a whole, though when I build it works fine on my computer and the project has the library set as a dependency in its dependencies.

I would suggest that you take a look at the Windows Event Viewer. Most likely, it contains some useful information about the crash. Also, It is possible to remote debug your application as it is explained in the How to: Set Up Remote Debugging. This is what I would do. Also, try to catch all exceptions raised in your application by subscribing to the Application.UnhandledException and AppDomain's UnhandledException events. This will allow you to obtain the callstack.

From the comment about Excel Interop is being used I got this from MSDN. It maybe obvious, but anyhow.

1. You must have Excel installed on your system for this code to run properly.

2. To use COM interop, you must have administrator or Power User security permissions. For more information on security, see .NET Framework Security.

In their example they are using the following code. May be good to add a similar check in your start-up code.

Microsoft.Office.Interop.Excel.Application xlApp;
xlApp = new Microsoft.Office.Interop.Excel.Application();
if (xlApp == null)
{
   Console.WriteLine("EXCEL could not be started. Check that your office installation and project references are correct.");
}

(note: I have never used this myself so I know little about it, its purely a lead from comments and some searching on MSDN).

If you can make changes to the app you could try and log any exception thrown using Trace output or long term with a dedicated logger like log4net. Also a look at the dependencies might be useful using DependencyWalker - 64 bit might still be an issue if you have assemblies loaded at runtime, you could get the famous "BadImageFormat" exception.

If you can I'd also setup a Win 7 32 bit VM to simulate the client environment on a "clean" machine, this might help reproduce the problem.

Edit to clarify trace configuration:

You can add a trace listener in your app.config:

<system.diagnostics>
    <trace autoflush="true" indentsize="4">
        <listeners>
            <add name="LogFileWriter" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:\logs\FooApp.log"/>
        </listeners>
    </trace>
</system.diagnostics>

This will cause all Trace.Write() statements in your program to write to your log (provided you have right to write to the configured folder).

What is your target CPU? Maybe you have set it to x64 and your client is running on a 32bit version of Windows 7

1. Add log possiblity and (if it's not yet in) and "architect" it at least for "simple" and "verbose" logging, where:

   Simple: just common information stirng that you will may need to read

   Verbose: just everythign you can, or have a meanning to log (depends on your application)

2. Make sure that you log handled exceptions and is able to handle even Unhandled via standart subscription of your AppDomain.
3. Add log on every window Show() and OnClosing() method (at least on those ones which hangs)
4. Verify if the OS is the same on yuor build machine and on client.
5. If you software writes somethign somewhere, make sure that you have enough previleges to do that (simple test is just ask to client run your program As Administrator
6. If still not work enable Verbose mode and run app on client and check logs.

Soon or later you will find something that may be will not directly explain your problem, but will definitely help you find a right way to resolve it.

Regards.

What helped me once in a situation almost similar to yours was to install DebugView, from System Internals, in the client machine and deploy a debug version of the application (here's how to trace and debug from C#).

DebugView will show all the debug messages that your program emits, and that may make it easy for you to figure out what is going wrong.

After installing both DebugView and your application, the client would then run DebugView, make sure capturing is active, then run your app. All your debug messages (sent to System.Diagnostics.Debug) will show up in DebugView, which can then be saved to a file by your client and sent to you for analysis.