views:

426

answers:

4

I would like to debug a .NET application that fails immediately on startup (and exists without an error message or log), but I can't attach a debugger to it because the process exists almost immediately after I run it. I don't have the source code for the app, so I can't do "Start Debugging". I tried using a Visual Studio macro to start a process, attach to it, then break, but the macro is too slow and by the time it finds the process, the process has already exited:

Imports System
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics

Public Module Module1
    Sub RunAndAttach()
        Try
            Dim dbg As Debugger3 = DTE.Debugger
            Dim trans As Transport = dbg.Transports.Item("Default")
            Dim sysProc As Process = System.Diagnostics.Process.Start(New ProcessStartInfo("C:\Temp\CrashingApp.exe") With {.WorkingDirectory = "C:\Temp"})
            Dim proc As EnvDTE90.Process3 = dbg.GetProcesses(trans, "ALLON-PC").Item("CrashingApp.exe")
            If (Not sysProc.HasExited) Then
                proc.Attach()
                proc.Break(False)
            Else
                MsgBox("Process " + proc.Name + " has already has exited.")
            End If
        Catch ex As System.Exception
            MsgBox(ex.Message)
        End Try
    End Sub

End Module

Is there a way to attach the debugger to a newly created process, like F5 does?

Thanks!

+1  A: 
  1. You can use windbg from it you can start the process.
  2. You can use reflector to decompile and get the source and continue from there.

Another idea is to use process monitor to see what the process is trying to do. The fail is most probably caused by a dependency on some external thing. And process monitor can help you locate it.

Update: You can use the reflector FileDisassembler add-in to create the full solution and debug it from there.

Igal Serban
Process Monitor: Tried that. There are no failures, some internal logic makes the decision to quit. E.g. ProcMon wouldn't help if the application at startup quits if it's a Saturday. Reflector: the application P/Invokes into unmanaged DLLs, and stores the result in a local variable which I cannot view it's content due to not being able to attach a managed debugger.
Allon Guralnek
Also about reflector - if I wanted to recreate the solution from the disassemblies, how can I get it to decompile the whole assembly and save all the source files to disk? Or do I need to manually copy/paste each class and method?
Allon Guralnek
The FileDisassembler Reflector plugin was quite useful, thanks for that! While I was on the plugnis folder I noticed Deblector, a debugging plugin which unfortunately wasn't very useful, and Reflexil, which allows you to inject MSIL instruction. I just injected a MessageBox.Show("Attach now.") as the first statement in Main(), which give you as much time as you need to attach the debugger (until you press OK), but of course John's method is superior.
Allon Guralnek
+2  A: 

The debugger requires a certain amount of processing to happen before it can be attached. For example in ASP.Net, it's hard to debug "Application_Start" events on IIS, because it's too early - the application has to be started before a debugger can be attached.

You can execute your program in Windbg though and get an immediate break or memory dump. There's a great tutorial on setting up windbg here, and in some of the comments on the post there are instructions on how to run your .exe from within windbg and get an immediate dump.

womp
You can debug Application_Start by either starting the web app from within Visual Studio by setting it as the startup project, or by putting Debugger.Break() inside Application_Start and then attaching when it hits the debug dialog.
adrianbanks
Good point on Debugger.Break().
womp
Both are not options since I don't have the source code. I'll try windbg. Can I then use VS to debug a process that windbg is attached to? If not, how useful is windbg in debugging a managed assembly (local variable watch, call stack, etc)?
Allon Guralnek
Windbg is one of the most powerful debugging tools available - more powerful than VS's debugger. Unfortunately, it's also it's own environment which can be fairly cryptic and has a steep learning curve (IMO). You can use the SOS plugin to debug managed code very effectively though - I would suggest following the first few tutorials on the site that I linked, they'll get you started pretty well.
womp
A: 

I think you can just do "File\Open\Project/Solution", select the .exe as the "solution", and then hit F5.

Brian
Already tried that. Open > Project/Solution doesn't allow you to open EXEs, and Open > File simply displays the resources inside that file, but doesn't allow you to debug.
Allon Guralnek
It works for me, hm.
Brian
With what version of Visual Studio?
Allon Guralnek
VS2008 Professional
Brian
That's odd. With VS2008 Pro, when I do File > Open > Project > Project/Solution and then pick any exe file (including an exe built from my own projects) I get an error: "The selected file cannot be opened as a solution or project. Please select a solution or a project file." What products do you have installed (Help >> About)? Do you have any besides C# 2008 and Web Developer 2008 (except hotfixes and 3rd party plugins)? Is anyone able to open EXE files, or getting the above error?
Allon Guralnek
+6  A: 
  1. Create a new project (a console project is fine).
  2. Right-click the project and choose "Properties".
  3. Click the "Debug" tab.
  4. Choose "Start External Program:"
  5. Select the program.
  6. Hit F5.
John Fisher
Neat trick! Just in my case, hitting F5 would have ran the program and then it would immediately exit. Instead, using Step Into caused the debugger the break at the beginning of Main(). Thanks!
Allon Guralnek