I've got virtual machine with VirtualKD drivers installed and attached to windbg running on the host machine.
So far I've managed to set breakpoints on user-space processes by switching to the desired process context in the following manner :
# get procID
!process 0 0 myproc.exe
# use procID to switch context
.process /i <procID>
# continue till scheduler context switch to the desired process
g
# set break point on process' context (symbols should be visible)
...
the problem here is that the process must already be available (otherwise we won't be able to get its context).
Perhaps there's an easier way to state the process name in the breakpoint command with the ability to wait for the process to come up ?
EDIT :
Found out that with sxe ld myproc.exe I can get my breakpoint on process load .. However, in this stage, not all its libraries are loaded so I cannot set breakpoint on their method. Perhaps there's a way to get better notice when a library x.dll is being loaded in process myproc.exe ?
Put __debugbreak() into your code. Compile. Copy into VM. Run the exe with debugger attached. Once your code hit __debugbreak, it'll break you in windbg.
Related
Can i set global breakpoint, using windbg, like softice (for example: bpx MessageBoxA) so it will break on all user mode running apps?
On Windows 95/98/ME, the main system libraries like kernel32 and user32 are shared by all processes. A normal usermode debugger cannot set breakpoints at all on these libraries on these systems.
On Windows NT based systems each process has its own copy and if you set a software breakpoint the modified page will not affect other processes.
If you want to debug a process and its children, you can do this with WinDbg. A script could probably set the breakpoint for each new process.
If you want to catch it in all processes for some insane reason you could maybe use a kernel debugger and a processor breakpoint ba?
If MessageBox is the actual thing you want to capture, you could probably use SetWinEventHook or a CBT hook instead of a debugger...
I would like to set a memory breakpoints on access in windbg in the kernel mode debugger
I want the debugger breaks everytime a specific module in usermode is hit with the kernel debugger.
but I've read somewhere its impossible to set it, in order to make a memory breakpoints I have to write a plugin to make it
I tried to use SDbgExt plugin with the !vprotect command, but it fails to set memory bp
If I have to write a plugin to allow memory bp in kernel mode It has to be a driver?
I've read some chapters in windows internals book, but it doesn't help me at all.
I couldn't find too much info how to start deal with it
You can set breakpoints on user mode addresses from kernel mode. The only thing you should take care is to switch to the right process with ".process /i " command
If it is a one-off breakpoint -- that is, you are content with process being destroyed by debugging -- zero out the entire module using e command (edit memory). Set the whole thing to cc (which is int 3 as far as I remember)... zeros will do as well. You will break as soon as you touch any of the module's code.
Next step, remember where you were (relative to the module) and set a proper breakpoint.
Hope that helps.
(editing) Do you have full symbols? If you do, did you try bm module!*
Sounds like you want to set a "breakpoint on access" but instead of specifying an address you want to specify a range? I have never seen it done in windbg. The BA breakpoints uses HW debug registers instead of inserting INTs like SW breakpoints so this is definitely HW platform specific.
I have done this on an ARM chipset once using a HW debugger. ETM on ARM allows you to set triggers on address ranges.
I'm debugging a WDM Kernel driver IOCTL using Visual Studio Kernel Mode Debugger via pipe Serial connection to a Hyper-V VM running Windows Server 2012 R2.
Once I hit a breakpoint inside the Driver IOControl is it possible to view the user mode call stack?
At the moment I can only see the kernel stack, eg:
SIoctl!SioctlDeviceControl+0x14b [d:\workspace\ioctl\c++\sys\sioctl.c # 320] C/C++/ASM
nt!IovCallDriver+0x3cd C/C++/ASM
nt!IopXxxControlFile+0x8d2 C/C++/ASM
nt!NtDeviceIoControlFile+0x56 C/C++/ASM
nt!KiSystemServiceCopyEnd+0x13 C/C++/ASM
ntdll!NtDeviceIoControlFile+0xa C/C++/ASM
KERNELBASE!DeviceIoControl+0x73 C/C++/ASM
KERNEL32!DeviceIoControl+0x80 C/C++/ASM
0x9c402408 C/C++/ASM
> 0x0000005e`2f5af9c8 C/C++/ASM
Yes, you need to switch to the desired process first and then you have access to it's stack(s). See .process:
The .process command instructs the kernel debugger to use a specific user-mode process as the process context. This usage has several effects, but the most important is that the debugger has access to the virtual address space of this process. The debugger uses the page tables for this process to interpret all user-mode memory addresses, so you can read and write to this memory.
Note If you are performing live debugging, you should use the /i or the /p parameter. Without one of these parameters, you cannot correctly display user-mode or session memory.
The /i parameter activates the target process. When you use this option, you must execute the target once for this command to take effect. If you execute again, the process context is lost.
The /p parameter enables the forcedecodeuser setting. (You do not have to use /p if the forcedecodeuser option is already active.) The process context and the forcedecodeuser state remain only until the target executes again.
I am aware you asked about Visual Studio and I answered about WinDbg. I think you should use a tool appropriate for the job. WinDbg is infinitely more flexible and more powerful when it comes to debugging. I think in VS you would use the Process context, but I would recommend, again, use WinDbg.
I have tried that by using !process 0 0 app.exe and then doing .process /i pid or .process /P id as well, both fail to display the user stack.
I think it's because I'm already in that process, even thought it is inside the kernel driver, the running process is the application.exe. So when I either look in the call stack window or type in k I only see the kernel stack.
The "Visual studio way" of "switching" to different processes does not seem to work, the only thing I can do is walk around the different stack frames (within only the kernel stack - same as shown in the call stack window).
I'll try doing it in WinDbg see if it's any different.
EDIT:
I did something different now, after switching the context I did !threads and then .thread to the one thread that showed up and it is now working within a sleep call. Somehow in my IOCTL it does not work. But I tried it now using WinDbg and it works wonderfully!
Many Thanks!
I have to perform some post mortem debugging on a C++ project.
Known way to perform is to set the cdb debugger as a minidump generator and to process the dumps collects afterwards.
I read nearly the whole web and I didn't find a solution to produce a minidump with the name of the process that has crashed
Is there a way to set AeDebug\Debugger registry variable in such a manner that cdb generates a dump file with the name of the process ?
When I encapsulate the call to cdb.exe in a batch file, it starts well but stays blocked on the symbol searching.
I must perform a Ctrl+C in order to stop the batch, then the minidump, with the correct process name, is created... but of course I can't set up such a thing in an unattended production environment...
Has anybody done that before ?
it starts well but stays blocked on the symbol searching.
What is it looking for? You can do "!sym noisy" to turn on noisy output about symbol loading. It shouldn't block forever, though--it should eventually timeout. If you fix your symbol path, that would help, too. You could set your symbol path to nothing, then it couldn't possibly be blocked loading symbols from anywhere.
About generating the dump with the process name, a colleague of mine (Jeremy) suggested this on the cdb/ntsd command line:
-c ".foreach( obj { lm 1m a #$exentry; } ) { .dump /m /u ${obj}.dmp;.dump /ma /u ${obj}.dmp; }; q"
And he also says "Make sure you use #$exentry and not just $exentry, else it'll attempt symbol resolution and bust your for loop."
But an easier way might be to use the Windows Error Reporting (WER) LocalDumps feature:
http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx
Instead of a dump file with the process name, there will be a directory with the process name in it that contains the dump file, which may satisfy your needs. For maximum info in the dump, set the DumpType to 0, and CustomDumpFlags to 0x1B65.
Note that this feature is purely for configuring local dumps: "These dumps are configured and controlled independently of the rest of the WER infrastructure. You can make use of the local dump collection even if WER is disabled or if the user cancels WER reporting. The local dump can be different than the dump sent to Microsoft."
Also note that LocalDumps doesn't support managed processes.
I have a main C++ app built in Visual Studio 2005, called A.exe. It spawns a child process, B.exe. I run process A in the debugger by hitting F5 -- the only way I know to hit breakpoints in process B is to wait for A to kick it off, then run Debug -> Attach to Process, and manually select B.exe. This doesn't work very well if I need to debug initialization code in process B -- I have to start putting in 10 second sleeps at the beginning.
Is there some trick in the vs2005 GUI that I'm missing?
I'm using native code, by the way.
Thanks,
Nathan
You can tell Windows to automatically attach the debugger when a certain process is started (by specifying the process name in a registry setting).
The details are here:
http://msdn.microsoft.com/en-us/library/a329t4ed(v=vs.100).aspx
You'd be hard pushed to make use of the debugbreak command in the child process as the debug process is not yet attached.
However, there is another that may be of use. Seeing as your creating the process, you'll have the handle to it. So give the DebugBreakProcess function a whirl.