views:

413

answers:

4

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

A: 

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.

AMissico
WinDbg can actually be used perfectly to debug .Net applications. Especially with the sos extension. See http://msdn.microsoft.com/en-us/library/bb190764.aspx
Lars Truijens
+2  A: 

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.

Christian.K
+5  A: 

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

Lex Li
+1 for using adplus.vbs in crash mode. The debugging tools are a simple, small install, and you can write them a batch file to run adplus in crash mode. We use this for customers who have problems we can't reproduce in-house
the_mandrill
Adplus.vbs is obsolete. Please switch to ADPlus.exe in the same folder.
Lex Li
LexThanks for your answer. This is exactly the kind of answer I was hoping for. You said "Ask your end user to launch you appliction in WinDbg, and execute .dump /f path" Is it obvious how to do that? How easy is it? Can you give a brief step-by-step? I take it the "path" is the path to the dump file. In any case, perfect answer. Will take a look now. Seth
Seth Spearman
One other thing. I found the following url...http://support.microsoft.com/kb/286350. This seems to describe the vbs script that you say is deprecated. Can you give an URL to the download for the EXE you mentioned?
Seth Spearman
One other thing. That article specifically mentions that "If you must troubleshoot a program or process that quits unexpectedly during startup" that ADPLUS is not the best choice. Also...any hints on analyzing the dump file?
Seth Spearman
As I already mentioned, Adplus.exe is in the same folder the contains ADplus.vbs (latest Debugging Tools installation).Execute .dump /f path is not obvious. You can write a test application and play with it. (1. Launch WinDbg, 2. File|Open Executable..., After that you need to see what is displayed the debugger breaks and stops, and determine if that's the time to execute ".dump /f path" or "g".) Regards,
Lex Li
A: 

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

Seth Spearman