Unable to Attach process using WinDbg

WINDBG
1

In SAN boot machine, I have my windows service ( daemon process ) which is in stopped state once booted.

I have to figure out that whether StartServiceCtrlDispatcher function gets suceeded. I have added log messages below that function.

My service start type is: Automatic, Since my service is automatic, My service is started by SCM ( Service Control Manager ) after the wininit process. Changing service type to boot, or manual doesn’t help to start my service.

Using windbg attach to process i tried to debug my service. Windbg command ( F6 - Attach to process ) lists services only which are in running state. Since my service is in stopped state, my service doesn’t gets listed. So I am unable to debug my service.

In elevated comand prompt tried to attach a process with process name using the command windbg -pn MyServiceProcessName,
I am getting the error
Unable to find process ‘MyServiceProcessName’, HRESULT 0x80004002’
No such interface supported.
Kindly help me regarding this…

  • D Anantha Krishnan

  • D Anantha Krishnan

2

A windows service is basically an application started by the SCM. In its stopped state, it’s not running, and there is no process to attach to.

Assuming you have its corresponding pdb, a good way to debug a service during its startup is to attach a debugger using Gflags - see https://msdn.microsoft.com/en-us/library/windows/hardware/ff554648.aspx and use windbg as the remote client debugger.

I use ntsd as the Gflags debugger with a command similar to

c:\debuggers\ntsd.exe -server tcp:port=5000,icfenable -G -y "C:\path\to\service\symbols"

which sets up ntsd as a debugging server listening on tcp port 5000 with an initial breakpoint but no final breakpoint (-G), with the service’s .pdb file in C:\path\to\service\symbols\

and then, in Windbg, “Connect to a Remote session…” with a connection string like

tcp:server=192.168.1.30,port=5000

(don’t forget to use the correct target IP address).

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-584405-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 09 June 2015 05:57
To: Kernel Debugging Interest List
Subject: [windbg] Unable to Attach process using WinDbg

In SAN boot machine, I have my windows service ( daemon process )
which is in stopped state once booted.

I have to figure out that whether StartServiceCtrlDispatcher function
gets suceeded. I have added log messages below that function.

My service start type is: Automatic, Since my service is automatic, My
service is started by SCM ( Service Control Manager ) after the wininit
process. Changing service type to boot, or manual doesn’t help to start
my service.

Using windbg attach to process i tried to debug my service. Windbg
command ( F6 - Attach to process ) lists services only which are in
running state. Since my service is in stopped state, my service doesn’t
gets listed. So I am unable to debug my service.

In elevated comand prompt tried to attach a process with process name
using the command windbg -pn MyServiceProcessName, I am getting the
error
Unable to find process ‘MyServiceProcessName’,
HRESULT 0x80004002’
No such interface supported.
Kindly help me regarding this…

  • D Anantha Krishnan
    This email message has been delivered safely and archived online by Mimecast.

For more information please visit http://www.mimecast.com

3

David Boyce, thanks for reply

Still I am not able to attach, the thing I tried in my lab are as follows,

  1. In my host ( Debuggee )machine - ip: 192.168.30.169, where I have MyService which is in stopped state. This MyService, I have to attach to windbg and debug for that
    In elevated command prompt ran, gflags.exe and made following changes

Image file < Tab >, In Image wrote MyService.exe
Tick marked on Enable heap tail checking
In Debugger box given, c:\debuggers\ntsd.exe -server tcp:port=50241,icfenable -G -y "C:\path\to\service\symbols" clicked apply and ok.

  1. In my debugger machine - ip:192.168.168.30.178, opened windbg
    connect to remote session, in connection string wrote
    tcp:server=192.168.30.169,port=50241

doing this way, I am getting the error
‘tcp:server=192.168.30.169,port=50241’, HRESULT 0x80004002
No such interface supported.

  1. Ping gets succeeded for 192.168.30.169

kindly suggest whether I did what you have said, and how to resolve the above error.

  • D Anantha Krishnan
4

> David Boyce, thanks for reply

You are welcome.

Still I am not able to attach, the thing I tried in my lab are as
follows,

  1. In my host ( Debuggee )machine - ip: 192.168.30.169, where I have
    MyService which is in stopped state. This MyService, I have to attach
    to windbg and debug for that
    In elevated command prompt ran, gflags.exe and made following
    changes

Image file < Tab >, In Image wrote MyService.exe
Tick marked on Enable heap tail checking
In Debugger box given, c:\debuggers\ntsd.exe -server
tcp:port=50241,icfenable -G -y "C:\path\to\service\symbols" clicked
apply and ok.

Did you check that the paths above are correct for the target machine? (e.g. is that where ntsd.exe actually is? is the symbols path correct (although this is not so important) ?)

  1. In my debugger machine - ip:192.168.168.30.178, opened windbg
    connect to remote session, in connection string wrote
    tcp:server=192.168.30.169,port=50241

doing this way, I am getting the error
‘tcp:server=192.168.30.169,port=50241’, HRESULT 0x80004002
No such interface supported.

ntsd doesn’t actually start until you try to run the service (either as automatic start or manual start). What gflags is causing to happen is that when MyService.exe is requested to start, ntsd is called instead with an argument of MyService.exe. Because the initial breakpoint is set, ntsd runs as far as the initial breakpoint and should now be listening for a client debugger to connect. This is your opportunity.

The point to grasp is that nothing happens until you try to run the service.

  1. Ping gets succeeded for 192.168.30.169

This just says the machine is up. It says nothing about anything listening on port 50241 (but you can find out on the target machine using “netstat -t”).
This email message has been delivered safely and archived online by Mimecast.

For more information please visit http://www.mimecast.com