Debugging .NET 2.0 Winforms application using Debugging Tools for Windows

Question

I support a .NET 2.0 Winforms application that is fairly widely deployed. On rare occasion we get a support call from a customer in which the application returns a .NET runtime exception AS SOON as you attempt to launch the application.

In the past we have helped the customer re-install the .net framework and very often that works...but occasionally not.

In such a situation could the Windows Debugging Tools be used to determine the cause of the problem. If so would you HAVE to download debugging symbols to the target computer (want to avoid since that can be several hundred MBs of stuff to download to the target.)

Is this overkill for a .net app? Any alternatives. How would you go about debugging this. Non-specific step-by-step would be appreciated. Of course, this app is compiled as a RELEASE configuration on the target machine. The customer will very likely NOT have dev tools installed or debugging tools. We DO usually have remote control access to the computer. To re-iterate. This happens AS SOON AS the customer attempts to run the application and it fails immediately.

What is the quickest path to solving this problem for the customer?

Here is an example of a recent error from the Event Log.
EventType clr20r3. .exe P2 2010.1.0.0, p3 4B857AFD P4 BLAH BLAH system.invalidoperation, P10 NIL.

Source: .NET Runtime 2.0 Error. EventID: 5000

Thanks in advance.

Seth

Answer 1

I don't think you want the "Windows Debugging Tools". Debugging symbols are for the OS, not the .NET Framework. (Reminder, your Windows.Forms application lives in the .NET Framework, not in the OS.)

Will "Remote Debugging" help at http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx?

I usually include a "StopSwitch", but this is not a requirement to enable JIT. (See "StopSwitch Stops Execution for Just-In-Time Debugging" at http://missico.spaces.live.com/blog/cns!7178D2C79BA0A7E3!309.entry) This allows my to enable the switch then attach to the running application when it hits the debugger stop statement.

You can debug the "release" builds. The release pdb are helpful for stack traces.

I had this problem before. I enable the StopSwitch, the check was the first line, but JIT was not launch because the problem occurred before the .NET Framework even loaded my application.

Answer 2

Edit: Just saw the "happens immediately on startup". Indeed WinDBG can help.

While the Debugging Tools for Windows are indeed mainly ment for native applications, they are usefull for managed applications as well. Not only are managed apps "native" in the end, when they execute, but there is also and in particular the SOS extension for WinDBG or CDB (if you prefer the command line).

Especially (mini-)dumps of crashed applications can be analyzed quite nicely with the SOS extension. If your application is complied in release or debug mode does not matter a whole lot, as long as you've got the matching symbol files (.PDB) at hand when analyzing a dump.

There is a whole lot information out there, way to much to talk about in this answer, but your best bet is searching for "windbg sos".

Concerning the example you gave

EventType clr20r3. .exe P2 2010.1.0.0, p3 4B857AFD P4 BLAH BLAH system.invalidoperation, P10 NIL.

it could be something else, but to me it looks like an uncaught exception in the .NET application - in this case a System.InvalidOperationException.

If you can get a minidump of the crashed application (look into the ADPlus tool, which is part of debugging tools to get a dump "on demand" or "on event"), then you can load that into WinDBG and use the SOS extensions (commands !clrstack, !dumpstack, !threads, etc.) to figure where that uncaught exception came from.

Answer 3

Why not use that?

For customers' machine, you won't be able to do remote debugging. Therefore, it is recommended to capture crash dump for crashing and hang dumps for hang problems, and WinDbg or ADPlus.exe is very useful here.

Ask your end user to launch your application in WinDbg, and execute

.dump /f path

to save a crash dump, then you can ask for the dump file and analyze the crash.

On target machine, no symbol is required. Symbols are useful when you analyze the crash dump on your own machine, and that's where things such as SOS are useful.

Of course there are other ways to get crash dumps,

http://blogs.msdn.com/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx

Answer 4

I wrote a blog post with some step by step instructions along with helpful URLs.

http://www.spearsofttech.com/2010/03/09/how-to-use-debugging-tools-for-windows-to-debug-a-net-application/

Seth