My simple understanding is OllyDbg is a user mode debugger, which you could use to debug "normal" apps. WinDbg is a kernel mode debugger, which you could use to debug itself.
Is that right?
WinDbg is a kernel mode debugger developed by Microsoft which can be used to debug Operating System itself on which it is running. Technically, it means it can debug kernel code which is privileged code running in Ring 0.
OllyDbg is a user mode debugger which is capable of debugging only user mode executables such as Exe.
Note that Windbg is a powerful debugger which encompasses the functionality of Ollydbg as well. However, its a command line debugger which beginners find it difficult to dealt with in beginning. Ollydbg is a GUI debugger much similar to Visual Studio debuggers.
WinDbg is a GUI debugger which can be used to debug both kernel-mode and usermode programs. It subsumes the functionality of the command-line debuggers, kd (kernel) and ntsd (user). Windbg can be used for live debugging of local usermode processes and remote debugging of kernel and usermode. It can also debug crashdumps after the fact.
Related
Why there is no GUI kernel debugger like SoftICE, which allows to debug kernel driver on a local machine nowadays? Why remote machine is obligatory for driver debugging in Windows 7 and higher?
An in-system kernel-mode debugger is an extremely complicated software because it must take care of many low-level kernel resources and operations. If kernel internals are changed in the next OS version, the debugger must be updated accordingly. Debugger developers must work together with kernel developers and have access to kernel source code. All that makes in-system debugger development complex and expensive.
And any kernel-mode debugging on the development system is a dangerous and inconvenient process. Even if no FS damages and/or other data losses occur due to a BSOD, booting a development system, starting all required applications to re-create convenient development environment is much longer process than rebooting a dumb target machine (hardware or virtual).
When hardware computers were expensive, there was no efficient remote debugging interface and there were no efficient virtual machine solutions, SoftICE was an acceptable tool. But in the last 15 years, remote kernel debugging in Windows had been greatly improved, so using WinDbg is much more convenient that using SoftICE, even though WinDbg has many flaws and bugs.
I'm developing a bootloader for the MPC5748G in C.
The bootloader will be running on RAM so i want to know how can i debug the bootloader code running on the MPC Target.
Thanks
Without further information on the platform you are using, the general guideline is that you compile your Bootloader software with Debug symbols, and once loaded, start a debugging session which should be configured to attach to the process (instead of the classical load-then-break-at-main). Then, hitting pause should interrupt the target, and from here on it is a normal debugging session.
In the hypothetical world where it is desirable to disable 64 bit Windows Kernel Patch Protection (which is disabled when running in debug mode), are there any downsides or implications to running a system permanently in debug mode?
Specifically, is performance meaningfully impacted by this? Or are there any specific limitations that users of a debug system may encounter?
What behaviours, apart from KPP, does the kernel or system as a whole alter if booted with Kernel Mode Debugging enabled? Is the answer different on Windows 7 vs Windows 8/8.1 vs Windows 10?
The machine can freeze. Some user mode failures get bumped up to kernel breaks.
The DVD software stops working (DRM protection)
Boot time is impacted. (Waiting to attach debugger)
Don't leave it on if you don't need it
Not seen a difference with different os's
I have a code running in Ring0 and it is crashing. I do not have any gdb server in my software. It is pure assembly diagnostic software. I am using Corei7
In embedded systems I used a hardware debugger (with Jtag), I can stop the core and check the exception registers...
I am not able to find the same process in x86 based boards.
Can someone point out how they do debugging of assembly code without using gdb.... Or if you use a JTAG/HW debugger please let me know as well
thanks
On x86 GDB uses some special hardware resources (debug registers?) to set watchpoints. In some situations, when there is not enough of that resources, GDB will set the watchpoint, but it won't work.
Is there any way to programmatically monitor the availability of this resources on Linux? Maybe some info in procfs, or something. I need this info to choose machine in pool for debugging.
From GDB Internals:
"Since they depend on hardware resources, hardware breakpoints may be limited in number; when the user asks for more, gdb will start trying to set software breakpoints. (On some architectures, notably the 32-bit x86 platforms, gdb cannot always know whether there's enough hardware resources to insert all the hardware breakpoints and watchpoints. On those platforms, gdb prints an error message only when the program being debugged is continued.)"
"Too many different watchpoints requested. (On some architectures, this situation is impossible to detect until the debugged program is resumed.) Note that x86 debug registers are used both for hardware breakpoints and for watchpoints, so setting too many hardware breakpoints might cause watchpoint insertion to fail."
"The 32-bit Intel x86 processors feature special debug registers designed to facilitate debugging. gdb provides a generic library of functions that x86-based ports can use to implement support for watchpoints and hardware-assisted breakpoints."
I need this info to choose machine in pool for debugging.
No, you don't. The x86 debug registers (there are 4) are per-process resource, not per-machine resource [1]. You can have up to 4 hardware watchpoints for every process you are debugging. If someone else is debugging on the same machine, you are not going to interfere with each other.
[1] More precisely, the registers are multiplexed by the kernel: in the same way as e.g. the EAX register. Every process on the system and the kernel itself uses EAX, there is only a single EAX register on (single-core) CPU, yet it all works fine through the magic of time-slicing.