Debugging LSASS ... oh what fun, it is to ride..

I spend a lot of my time debugging LSASS or Winlogon due to what I specialize  in ( Active Directory \ Security \ PKI \ GPO’s )

As of XP and greater I have historically done a kernel debug to get at LSASS. If you try to debug it from usermode on the machine you are debugging, you may end up killing LSASS and the machine will reboot due to LSA dying. You are also limited in what you can do ( since the action may  require LSASS, and you are debugging it – chicken \ egg thing )

 

 

 

 

Debugging LSA from Kernel

 

A kernel debug also gives me the advantage of debugging any other process on the machine. LSA ends up processing a lot of requests from other processes via LPC calls. So,  many time, it is very nice to be able to set breaks in these other processes.

 

When doing a kernel debug with LSA I like to use something like this:

 

Get the process address for LSASS

 

0: kd> !process 0 0 lsass.exe

PROCESS 815196c0 SessionId: 0 Cid: 010c Peb: 7ffdf000 ParentCid: 00e4

    DirBase: 042d2000 ObjectTable: 81519aa8 TableSize: 859.

    Image: LSASS.EXE

 

Switch to the process context:

 

Either

 

.process /p /r 815196c0

 

Or

 

.process –i 815196c0 ;g;.reload /user

 

Debugging CSRSS via setting gflags and NTSD, then piping that info through kernel;

 

This method will also give you access to all processes on the machine via the  |  command  to switch between them.

So, I can look at LSA, or winlogon, or whatever using this method.

 

The basic setup is to set gflags for FLG_ENABLE_CSRDEBUG and under the execute option – specify NTSD.exe with  the –d switch so the output is sent to a kernel debugger.

Note that your symbols must reside on the target machine  in order to access them during the debug.

 

More info here

 

Enable debugging of Win32 subsystem

Abbreviation

d32

Runs the Client Server Run-time Subsystem (Csrss.exe) in the Windows Symbolic Debugger (Ntsd.exe) with the following parameters:

-d Send output to kernel debugger console.

-p 1 Attach the debugger to already running Csrss process, as identified by its process ID, 1.

This flag is effective only when the Debug Initial Command (dic) or Debug Winlogon (dwl) flag is also set.

 

I used to use this one quite a bit – but not so much anymore. There are some risks doing this and plenty of pre-setup work which needs to be done to avoid ending up in a BSOD.

 

Debugging LSA via dbgsrv.exe

 

This is my latest best friend ( thanks to a colleague of mine on the base Dev Support team ) .. easy to use and not all the setup of a kernel or csrss debug. You don’t have the risks of debugging LSA on the same machine, nor do you need to reboot to use this method.

 

When using this method you don’t need symbols on the target either – another bonus.

 

On the target machine:

Find the PID for LSA via  tlist.exe

Then run this command:

C:\Program Files\Debugging Tools for Windows>dbgsrv.exe -t tcp:port=1234,password=spat

 

On your debugger:

Run this command to attach to LSA on the remote machine.           

            I:\debugger>windbg.exe -premote tcp:server=192.168.1.102,port=1234,password=spat -p 596 -- where 596 = PID of LSASS

 

Set your symbols on your debugger:

 

0:021> .sympath

Symbol search path is: SRV*i:\symbols_pub*https://msdl.microsoft.com/download/symbols

Note that anything which needs LSASS on the target machine, will be postponed while you debug LSA ( until you ‘g’  the debugger )

 

Now you are ready to go!

 

When you want to quit – make sure you use ‘qd’ to  ‘quit and detach’ so you don’t kill LSA  on the target machine.

 

Have fun debugging...

 

spat