5

Just a simple (maybe dumb) question: is there a simple small debugger tool I can use when I do remote-assistance (I use VNC or TeamViewer)?

My C# app is deployed to thousands customers in my country, and sometimes there was some errors I cannot simply reply. If there was a simple debugger, I would use it to test the particular installation and environment, and I would probably find the problem in minutes.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Ferdinando Santacroce
  • 1,047
  • 3
  • 12
  • 31
  • 1
    Visual Studio Express editions are free and relatively small - but I wouldn't call them simple though. – ChrisF Apr 05 '11 at 12:39
  • 4
    [WinDbg](http://msdn.microsoft.com/en-us/library/ff561300.aspx)? You'll also need the SOS extension to debug managed code. – Cody Gray - on strike Apr 05 '11 at 12:39
  • @Cody Gray: and relevant symbols, for anything particularly useful. – Dan Puzey Apr 05 '11 at 12:47
  • @Dan: Agreed, but I assumed that was a given, as he's already doing remote debugging. The assemblies should just be shipped with the PDB files if you think you'll want to do this more than once. – Cody Gray - on strike Apr 05 '11 at 12:48
  • 1
    I found this, looks interesting! CLR Managed Debugger (mdbg) Sample [link](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=38449a42-6b7a-4e28-80ce-c55645ab1310&displaylang=en) – Ferdinando Santacroce Apr 05 '11 at 12:53
  • @all My app is relatively small; I deploy it withoud PDBs, but if necessary I will recompile it in debug mode, transfer it via remote-assistance, then start the test/debug session. So WinDbg has .NET capabilities? I will look at this now. Link I posted, mdbg look nice, too: what do you think about? – Ferdinando Santacroce Apr 05 '11 at 12:58
  • Do note that PDBs and compiling in Debug mode are orthogonal to one another. There's no reason you should ever have to deploy a Debug version of the app. I talk more about [generating PDB files in Release mode here](http://stackoverflow.com/questions/5457095/release-generating-pdb-files-why/5457250#5457250). The upshot is that you can ship a full Release compile of the app, and simply include the generated PDB file without affecting run-time performance or anything else. – Cody Gray - on strike Apr 05 '11 at 13:01
  • @FerdinandoSantacroce : How about if you accept the suitable answer? –  Dec 08 '11 at 14:06

4 Answers4

3

You can use Redgates Reflector with Deblector. http://reflectoraddins.codeplex.com/. But we generally log our all unhandled exceptions to text file and whenever client approaches us we take out the log file. And release a new build with the issues fixed.

  • nice - not seen that - must have a closer look. Is it any good? – Rob Levine Apr 05 '11 at 12:41
  • 1
    Frankly, i have'nt used deblector. Instead i use reflector and its file generator for reverse emgineering, and its works flawlessly, so i hope deblector will work too. –  Apr 05 '11 at 12:43
  • Very interesting... I produce tons of logs too, but sometimes it is not enough. :-) Thank you for you suggestion! – Ferdinando Santacroce Apr 05 '11 at 13:20
  • It seem just what I need; it uses mdbg, as I linked before: [link](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=38449a42-6b7a-4e28-80ce-c55645ab1310&displaylang=en). I need to play with it a little bit, indeed. :-) – Ferdinando Santacroce Apr 05 '11 at 13:54
2

I can't think of a small alternative debugger that would let you step into running code in the way that Visual Studio does.

However, you can always create a dump file which will give you a snapshot of the entire process, with all threads and stack traces, etc. In more recent versions of Windows, this is as simple as right-clicking on the process in task manager and selecting "Create Dump File".

Once you have this, you bring it to your local dev box, run WinDbg with SOS and you can get a full view of what was going on.

Tess Ferrandez blogged some brilliant beginner's labs to get people started with this sort of thing.

Rob Levine
  • 40,328
  • 13
  • 85
  • 111
  • You don't need a dump, you can also attach to the live process with WinDbg and SOS. – driis Apr 05 '11 at 12:41
  • Indeed - my thinking was that it is probably easier (on a remote client's machine) not to require WinDbg/SOS, but to pull the dump file back to a dev workstation. – Rob Levine Apr 05 '11 at 12:43
  • Thank you Rob, I didn't know about this possibility. I never used WinDbg, I definitely need to acquire some skills using it. :-) – Ferdinando Santacroce Apr 05 '11 at 13:12
  • No problem Ferdinando - my pleasure. I'd recommend Tess's labs as a good starting point. – Rob Levine Apr 05 '11 at 14:11
2

For 2.0, there is a core framework debugger - http://msdn.microsoft.com/en-us/library/7zxbks7z(VS.80).aspx - not something I've personally used since 1.1 of the framework!

It looks like in 4.0 there is this command line debugger - http://msdn.microsoft.com/en-us/library/dd233107.aspx - and it looks like the source code for this is available - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ce94e626-c43d-419c-8538-173f6a042ef5 - looks like an interesting project.

Stuart
  • 66,722
  • 7
  • 114
  • 165
1

Without symbols and source files, you're not going to get very far. A debugger won't give you much useful information without those things, and for a large application that can be quite cumbersome.

A more likely useful solution is to implement some kind of log/dump collection so you can bring useful information back to your machine for analysis.

Alternatively, the VS remote debugger would allow you to attach the VS debugger via network to a remote machine, but this is quite painful to work with over a slow internet-type connection.

Dan Puzey
  • 33,626
  • 4
  • 73
  • 96
  • Yes, attaching to a remote machine is quite difficult to me, and painfull. You say I need the source to step through the code I want to debug: I didn't think about before, in effects... It would more be complicated than I hoped. :-S Thank you! – Ferdinando Santacroce Apr 05 '11 at 13:18
  • Even without pdb files or source you can see the call stack including method and class names, see local variables, inspect the stack, set breakpoints, etc. All this information is always in a managed assembly. – Lars Truijens Apr 19 '11 at 17:53