(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
From time to time it's useful to be able to debug an application without launching it from within the debugger - sometimes you need to start programs in their natural launch environment to reproduce a problem. Of course you can always attach the debugger to an existing process, but this doesn't work so well if you need to debug it from startup rather than attaching once it's running. (E.g., maybe it's crashing on startup.)
Fortunately you can tell Windows that you'd like to do this, and have it automatically fire up a debugger for you whenever a particular application is launched. And despite the fact that this has been written about before, I always forget the details, so I thought I'd blog them - that way I know where to look next time I need to do this! And lots of people don't seem to know about this, so it's worth bringing up anyway.
The trick is to add a registry key underneath this one:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Underneath here you'll find lots of names of executables. You can add a key with the name of the executable you'd like to debug as soon
as it starts. Just put in the file name without the path (but including the .EXE extension). And underneath that key add
a string value called Debugger. In here you can specify the name of a program to be used as a debugger (including
the path this time, unless your debugger happens to be on your system path). With this in place, whenever something tries to run
the program, your chosen debugger will run instead.
Note: the Debugger value must not contain any spaces. If necessary, use the 8.3 style path.
(The DOS legacy still has its uses...)
So what do you choose as the debugger program? Well, you can just point the VS.NET exe, devenv.exe at it, passing in the
/debugexe switch. Or you can use the vs7jit.exe launcher.
The one problem with these is that they will fire up a new debugger instance. This is a pain if you wanted to open a particular VS.NET project, or attach with an instance that is already running, like you can do with the normal JIT debugging dialog.
This gets better with Whidbey. If you've got VS.NET 2005 installed, just use vsjitdebugger.exe as the debugger.
This gets installed on the system path, so you don't even need to specify its location - just the name is fine. This brings up the same
debugger picker UI you get when JIT debugging, enabling you to choose either a new debugger instance or one that's already
running.
(I got really confused by this earlier today. My machine has a copy of vsjitdebugger.exe because
it had a beta of Whidbey installed at one point in the past. It didn't get removed when I took the beta off. And since that's been the
JIT debugger executable on my system for ages, I hadn't realised it was a whidbeyism, and so it took me a while to work out why
it wasn't present on a colleague's machine... *Sigh* Still, it's handy that it happens to work with VS.NET 2003!)