An opportunity to learn things about Windows NT that I couldn't learn/discover otherwise. For me learning new things and solving complex problems are the two most important things when dealing with computers.
	An opportunity to develop what I think is one of the most interesting projects I can think of. With the amount of internet information about everything in the field of technology and development, I was searching something to develop that would force me to extract and deduce the required information myself, with reverse engineering, in this case. Nowadays developing any other type of application consists, in most cases, in doing a search in Google, CodeProject or MSDN and then putting together the found code samples...

	BugChecker Debugger driver: this is the debugger itself. It is implemented as a Windows NT Kernel Driver. This means that you can debug with it both user mode and kernel mode code.
	BugChecker Video driver: this NT Driver is required in order for the debugger to be used. Its start mode is set to "boot" and it is started when Windows 2000 is booted up. This simple driver (compared to the debugger driver itself), when started, hooks and patches some DirectDraw API entry points in order to be notified about the current video display mode and the start in kernel protected memory of the display framebuffer.

	Kernel/user debugging of 32-bit code.
	SMP support. The debugger can be used also on multiprocessors systems (PIC/IOAPIC/APIC support): the reentrancy in the debugger code is prevented.
	Full source code support (via .pdb files). Coded, but still not exposed in the debugger (mixed source file/assembly view, stack trace, C types inspection etc.).
	Kernel and user breakpoints features. The user breakpoints are maintained in a special database that is synchronized with the NT Page Frame Database. The breakpoints of this type can be specified as process and/or module specific.
	Support of DirectDraw compatible video cards.
	Support of PS/2 Keyboards and Mouses with handling of keyboard LEDs status and restore of hotkey press/release state in OS when exiting from the debugger.
	Saving of the current floating point status (if used in the current NT process context) when entering in the debugger thus allowing the creation of macros that handle fp data, for example (without interfering with the current running process).
	Integration of a special C compiler written by Vito Plantamura in the debugger code itself. Every macro written and every command entered is compiled instantly and linked in realtime in a debugger special reserved memory area.
	Macro writing support.
	Text editor with basic clipboard commands for allowing the writing of macros and scripts.
	Scripts and macros can access and call a set of APIs that allow the writing of very complex breakpoint handlers and that can be used to "automate" the debugger itself.
	Symbol loader MFC application that allows the conversion of .PDB files in .BCS files for loading into the debugger memory.
	Support of resizable windows (ala SoftICE).

	BC : Clear breakpoint. ( syntax: BC list|* )
	BD : Disable breakpoint. ( syntax: BD list|* )
	BE : Enable breakpoint. ( syntax: BE list|* )
	BL : List current breakpoints. ( syntax: BL (enter) )
	BPE : Edit breakpoint. ( syntax: BPE breakpoint-number )
	BPINT : Breakpoint on interrupt. ( syntax: BPINT interrupt-number )
	BPIO : Breakpoint on I/O port access. ( syntax: BPIO port [/R|/W|/RW][/Lsize][/DRreg] )
	BPMB : Breakpoint on memory access (byte size). ( syntax: BPMB address [/W|/RW][/G][/DRreg] )
	BPMD : Breakpoint on memory access (dword size). ( syntax: BPMD address [/W|/RW][/G][/DRreg] )
	BPMW : Breakpoint on memory access (word size). ( syntax: BPMW address [/W|/RW][/G][/DRreg] )
	BPX : Breakpoint on execution. ( syntax: BPX address [/DRreg|none][/Pname|none][/Mname|none] )

	? : Evaluate expression as dword (integer). Use EVALF for fp. ( syntax: ? expression )
	CPU : Display informations about all the CPUs or a CPU in particular. ( syntax: CPU [(enter)|#cpu] )
	DASH : Go to dashboard. The execution will return to Windows. ( syntax: DASH (enter) )
	EC : Enable/disable code window. ( syntax: EC (enter) )
	EVALF : Evaluate expression as floating point. ( syntax: EVALF expression )
	HBOOT : Reboot the system (total reset). ( syntax: HBOOT (enter) )
	I3HERE : Direct INT3 to the debugger. ( syntax: I3HERE [ON|OFF|DRV] )
	VERSION : Display VpcICE version informations. ( syntax: VERSION (enter) )

	F4 : In-place compilation of the Script File.
	F6 : Toggle the Code Window Mode.
	F7 : Toggle the Script Window Focus.
	F8 : Single step.

	The command "list breakpoints" (bl) was entered. There is only one breakpoint: note that in BugChecker the user breakpoints are maintained storing the relative byte address, the module name and the process name. You can however set a breakpoint that is process name generic (it will trigger in any process, regardless of its name) simply omitting the process name when setting the breakpoint itself.
	Note that a macro was defined in the script window. Its name is "test" and it accepts one parameter of type "int". After defining this macro, it is used in an expression specified as the address parameter of the "bpx" command, for setting an "execution breakpoint". Later, when the execution resumes in the OS, this same breakpoint triggers and the control returns to BugChecker.
	The same macro of the screenshot above is evaluated with the "?" command.
	An other macro was defined with the name "complex_macro". Note that the macros defined in the script window have to be compiled before their use in expressions for commands or other macros (this is accomplished pressing the F4 key). Later, the command "evalf" is used on the "complex_macro", specifing as parameters the results of two calls to the "test" macro. Note that "complex_macro" returns a float value, and takes as parameters two other float values. Everything you enter in BugChecker (script, macros, breakpoint handlers, commands) is first compiled, then executed in the private context of the debugger.
	As a proof of what stated above, you can see the debugger response when entering a wrong syntaxed command: the debugger tries to compile the command "evalf complex_macro ( s )", but the compiler is unable to understand the meaning of the "s" symbol.
	A "breakpoint on I/O port access" was set on the keyboard i/o port, for read and write operations and on the debug register 3. In the screenshot it triggers because of a keyboard interaction and the execution goes to BugChecker for debugging.
	A "breakpoint on memory access" was set on the address of the PCR structure in virtual memory. The FS:0 address refers to this same memory in kernel space.
	A screenshot of the symbol loader application.

BugChecker 32bit Debugger for Win2000/XP/S2003 (UP/SMP) - (Ver0.9 - Bld107).
Copyright (c) 2003-2004 Vito Plantamura Consulting. All Rights Reserved.
----------------------------------------------------------------------------------------------------
BugChecker: Settings File: "\SystemRoot\system32\drivers\bugchk.dat": Loaded.
BugChecker: Allocated 512Kb for Symbols.
BugChecker: User Probe Address is "0x7FFF0000".
BugChecker: Number of Processors in the System: 2.
BugChecker: Active Process List: ProcessListHead = 8055CC68, IdleProcess = 80547370.
BugChecker: Allocated 4286 KBytes for MiniC Compiler.
BugChecker: Allocated 131072 Bytes for BugChecker System Stack.
BugChecker: "MapViewOfImageSection" Entry Point located at 8051AB10.
BugChecker: "UnMapViewOfImageSection" Entry Point located at 805A838E.
BugChecker: "NtTerminateProcess" System Table Index located at E0.
BugChecker: Pentium TSC Calibration result: 999 MHz.
BugChecker: I/O Apic found at linear address "0xFFD06000".
BugChecker: Using Linear Address for accessing Per-Processor Local Apic at "0xFFFE0000".
BugChecker: BugChecker Inter-Processor Interrupt installed at Vector "0xF5". ISR at Linear Address "0x8053D08A".
BugChecker: Real Mouse Interrupt Vector detected at 0x52.
BugChecker: Real Keyboard Interrupt Vector detected at 0xB3.
BugChecker: Installing Mouse Trampoline for Interrupt Vector 0xF7.
BugChecker: Installing Keyboard Trampoline for Interrupt Vector 0xF6.
BugChecker: Installed trampoline for IRQ12 (PrevISR: "0x8053D098", NewISR: "0xBA7841C0").
BugChecker: Installed trampoline for IRQ1 (PrevISR: "0x8053D091", NewISR: "0xBA783B48").
BugChecker: Exiting "InstallBugCheckerInterruptHooks" with Success.
BugChecker: Debugger User Space Memory: Address: 6F800000, Size: 8000.
----------------------------------------------------------------------------------------------------
BugChecker: PS/2 Mouse detected. Device ID = 0x03.
BugChecker: Load32 -> START=75050000  SIZE=2C000  KPEB=8523A860  MOD=netmsg.dll
BugChecker: Exit32 -> PID=4B0  MOD=net1
BugChecker: Unload32* -> MOD=net1.exe
BugChecker: Unload32* -> MOD=ws2help.dll
BugChecker: Unload32* -> MOD=ws2_32.dll
BugChecker: Unload32* -> MOD=wsock32.dll
BugChecker: Unload32* -> MOD=netmsg.dll
BugChecker: Unload32* -> MOD=samlib.dll
BugChecker: Unload32* -> MOD=NETAPI32.DLL
BugChecker: Unload32* -> MOD=netrap.dll
BugChecker: Unload32* -> MOD=rpcrt4.dll
BugChecker: Unload32* -> MOD=WLDAP32.DLL
BugChecker: Unload32* -> MOD=dnsapi.dll
BugChecker: Unload32* -> MOD=ntdsapi.dll
BugChecker: Unload32* -> MOD=msvcrt.dll
BugChecker: Unload32* -> MOD=NTDLL.DLL
BugChecker: Unload32* -> MOD=ADVAPI32.DLL
BugChecker: Unload32* -> MOD=secur32.dll
BugChecker: Unload32* -> MOD=KERNEL32.DLL
BugChecker: Exit32 -> PID=588  MOD=net
:cpu
CPU|PCR-Base|IDT-Base|GDT-Base|IRQL(Priority)| TID|       CS:EIP|Proc(ID)
00 |FFDFF000|8003F400|8003F000|  DISPATCH(41)|0000|0008:8053C66C|Idle(0000)
01 |85E83000|85E873C8|85E87BE8|  DISPATCH(41)|0000|0008:8053C66C|Idle(0000)
:
:

	Checking for fields offset changes in the PCR, KTEB, KPEB and DriverSection system structures.
	Fixing the system functions search routines for discovering the correct addresses of the following functions: "MapViewOfImageSection", "UnMapViewOfImageSection", "NtTerminateProcess" (when symbols are not available). It is necessary to check whether the prototypes and logic of the aforementioned functions is still the same in Windows XP and Windows 2003 (probably yes...).
	Implementing a VAD Walking Function that is compatible with Windows 2003 (where the Virtual Address Descriptors structures and algorithms have changed.)
	Checking whether the Process List iterator still works with WinXP.