One of the things that I’ve used a lot when working with Windows 8.0/8.1 code is the option where you ask the debugger to get itself ready to debug your code but you ask that it doesn’t “launch” your application itself when the debugger starts.

This is something that you’ll find off the properties page for the project and I find it even more useful in some ways on Windows Phone than I found it on Windows;

If you have a Windows Phone 8.1 application then when you run that application under the debugger with this option switched on nothing seems to happen. Here’s the emulator displaying that “nothing” when I have pressed F5 on a project called “App132” on my machine;

and what’s “interesting” here is to watch the debugger’s “processes” window. Here, you can see that the debugger isn’t doing anything much;

but if I run the application on the emulator – i.e. actually use the home screen to launch the app;

then as soon as the app launches, the debugger attaches itself as you can see from the processes window;

and if I was then to shut the application down using the gesture on the phone (i.e. hold down the back button to get the task switcher and then swipe the app down);

then I’ll notice that the debugger detaches because the process exits;

and what’s “nice” here is that if I run the application again;

then, once again, the debugger attaches to the new process;

and so this is great as a way of debugging a few things;

1. Application startup code. If you want to (e.g.) see how the application is launched “cold” from an association or similar then this is perhaps the best way of doing it.
2. The application if you want to run it multiple times then I find this easier than having to keep going back to Visual Studio and hitting F5 and especially if the application debugging is happening on a device rather than the emulator.

and scenarios like the one that I mentioned in a recent post where I referred to a procedure that an MSDN page gave for attempting to debug the situation where a Windows Phone 8.1 app uses the FileOpenPicker.PickSingleFileAndContinue method and you want to debug what happens when the OS terminates the app in order to show the file picker dialog and then re-runs and activates the app in order to provide the file that has been selected. In that case you do something like;

1. Run the app under the debugger using the “debug my code when it starts” option.
2. Run the app.
3. Navigate to the point where it raises the file picker and raise it.
4. Use the debugger to  suspend/shutdown the app.
5. Set a breakpoint where the apps gets activated with the file chosen in the picker.
6. Pick the file in the file picker.

and that works really nicely.

Generally, for me, I think this will become the default way that I debug on the phone – I like it better than having the debugger automatically launch the app and assume that I only want to debug one process until it’s shutdown.