I am pretty new to this forum and Windows kernel debugging. I am using Linux (Ubuntu) as my base machine and running two Virtual Machines (both Winxp: one as a debugger vm and another one as debuggee VM).
When I press CTRL+K in the Windbg running in Debugger VM, I get the control of the other Virtual Machine (debuggee). However, the whole OS of the debuggee machine freezes (as expected).
Is there a way, where I can only attach to a one running process in the debuggee VM instead of making the debuggee OS freeze.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, December 06, 2011 9:41 PM
To: Kernel Debugging Interest List
Subject: [windbg] How to use windbg to debug a process without freezing the
target OS?
Hi All,
I am pretty new to this forum and Windows kernel debugging. I am using Linux
(Ubuntu) as my base machine and running two Virtual Machines (both Winxp:
one as a debugger vm and another one as debuggee VM).
When I press CTRL+K in the Windbg running in Debugger VM, I get the control
of the other Virtual Machine (debuggee). However, the whole OS of the
debuggee machine freezes (as expected).
Is there a way, where I can only attach to a one running process in the
debuggee VM instead of making the debuggee OS freeze.
debugging a single process is best done by local debugging rather than
kernel debugging
ie install windbg in the debuggee vm and
use open executable
or attach to process or
.attach
windbg -pn name of executable and so on and so forth
if you must really use kernel debugging connected over 2 vms and
attach to a PROCESS rather than kernel and you can try use ntsd in
debugee vm
ie ntsd -d “Proceess Name” …
to redirect the output to kernel debugger
On 12/7/11, xxxxx@gmail.com wrote: > Hi All, > > I am pretty new to this forum and Windows kernel debugging. I am using Linux > (Ubuntu) as my base machine and running two Virtual Machines (both Winxp: > one as a debugger vm and another one as debuggee VM). > > When I press CTRL+K in the Windbg running in Debugger VM, I get the control > of the other Virtual Machine (debuggee). However, the whole OS of the > debuggee machine freezes (as expected). > > Is there a way, where I can only attach to a one running process in the > debuggee VM instead of making the debuggee OS freeze. > > Thanks in Advance!!! > > — > WINDBG is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
I did not have any specific reason. I wanted to know how does this method work against some malware samples that generaly injects code in other running processes and then activates the rootkits.
I’ve done quite a lot of thread/process debugging with a kernel debugger. This is a good approach in some situations. For example, one doesn’t know in advance which process needs debugging or where in a specific process one should debug BUT one does know that a certain kernel component is called by whatever process/thread turns out to be of interest. Here the kernel component may be no more than a point to get purchase on the matter under investigation. I have used this approach in investigations of issues involving file systems, where I didn’t know in advance what user-space routine was the root of an issue.
Another situation is one where a piece of work involves more than 1 thread and maybe more than 1 process. A kernel debugger can be an essential tool in following the work. I have used this approach in following WMI activity (a very time-consuming investigation, I must say).
Another possibility is to have both a kernel debugger and a user-space debugger. Sometimes this is useful to investigate a high-traffic kernel component: It is of course possible to qualify a kernel-mode breakpoint with a thread or process, but sometimes even the checking by the kernel debugger whether the requested thread or process is in control can be very expensive and slow the OS markedly. With a user-space debugger to stop things just before a kernel call, one can separately cause the kernel debugger to activate a thread- or process-qualified breakpoint, so as to minimize impact.
There can be a lot of technical problems with kernel debugging of user-space issues. Setting user-space breakpoints correctly may be a challenge, since one has to ensure the correct process context. High-traffic DLLs used in several processes can be a real pain, because most debugger breakpoints are effected by inserting 0x03 into a module, which can cause duplication of the DLL binary upon insertion of the byte. If the page with the insertion gets paged out, things can get even harder.
All in all, kernel debugging of user-space programs can be useful but will often require expertise.