I was discussing various ways to do a live debug of a strange issue with one of my colleagues and came up with an interesting option which I thought I should share here. Let’s consider we have a windows service which is causing some trouble during the startup. The trouble could be either a service crash or something that you expect the service to do which it isn’t doing. Let’s assume the service is crashing on startup here.
You have quite a few options if your service is running for a while and then crashing. You can attach one of the debuggers to the service, wait for a second chance exception to happen, and then proceed with analyzing further by looking at the call stack/exception or capturing a memory dump to analyze this later. But we are not left with these options if the service is crashing on startup as you would have no time to attach the debugger to the service before it crashes.
For this scenario, you can go for Image File Execution (IFE) as explained in ‘Configure a service to start with the WinDbg debugger attached’ section of the KB article – KB 824344
Note that this KB article talks about enabling “Allow Service to Interact with Desktop” option for the service. This option, as the name suggests, allows the service to interact with desktop without which the UI displayed or debugger attached through
So how would you troubleshoot an issue when the issue happens only when this option is not selected? How would you troubleshoot such a startup issue when the service is not running under the default SYSTEM account (for which you do not seem to have an option to allow service interact with desktop in the SCM)? This is exactly the scenario that we had to troubleshoot.
This is when you can make use of Remote Debugging option in WinDBG. Remote debugging might not be exactly meant to troubleshoot such a scenario but yeah, can be made use of here to achieve what we want. As you might be aware, remote debugging would have a server instance (which actually gets attached to the process) and a client instance (where you do the debugging after connecting to the server instance).
I am not getting too much into the details of WinDBG’s remote debugging as it is already nicely documented in the help file that comes along with it. But what we need to do here is attach an instance to of WinDBG as a ‘server’ to the crashing service using
Ø Follow the instructions in ‘Configure a service to start with the WinDbg debugger attached’ section of the KB article – KB 824344
. Note that you can safely ignore Step 2 in this section as you would no longer need the service to interact with desktop.
dd the following command line parameters to the path of the debugger: (let’s assume debugger is installed in ‘C:\Debuggers’ instead of ‘C:\Program Files\Debugging Tools for Windows’ for convenience)
C:\Debuggers\WinDBG.exe -G -c ".server tcp:port=1234"
Ø Start your service from Service Control Manager.
Ø By now the debugger is already connected to the service as a ‘server’. You would have reached the ‘Initial Breakpoint’ waiting for a g (Go) command from the debugger.
Ø Launch another instance of WinDBG and connect to the ‘server’. There are many ways to do this; the simplest would be to go to File->Connect to Remote Session->Browse->Enter machine name->Refresh. Hit OK on your ‘server’ that is listed to connect.
You are now all set to do a live debug of the service startup issue for a service which is not allowed to interact with desktop. You can play around with the command line parameters to WinDBG depending on your needs.
WinDBG -? contains a detailed description of the command line syntax that WinDBG uses.
Link for reference: