Known Bugs and Open Points

Bugs (in order of severity)

Fix: MiMapViewOfImageSection prototype changed in Windows XP. At the current release BugChecker skips hooking this function under Windows XP.

VmWare only: The virtual 8042 controller (keyboard, mouse) under VmWare behaves differently than a native controller, in particular with regard to the D2 command ("simulate keystroke"). Tipically the D2 command is sent to the controller after the logger ISR has read the next scancode from the keyboard output register. This enables the previous ISR (the OS' one) to read the same scancode captured by the logger ISR. While this works perfectly on various tests performed on OSes with direct access to a physical 8042 controller, under VmWare as soon as the D2 command is issued by the logger ISR (when the IRQL drops OR on an other virtual processor) execution reenters the logger ISR, actually without waiting for the EOI signal, as logically expected and as implemented by real 8042s. This deadlocks the system. BugChecker implements a VmWare-specific solution to this problem (see the "VmWareKeyboardIntDeReentrancyThreadProc" function): D2 commands are sent to the controller from a kernel thread running at the lowest IRQL (i.e. PASSIVE). This solution (employed exclusively when running under VmWare) needs to be refined (sometimes Ctrl, Shift or Alt depressions are not detected by the guest OS, and, more importantly, Caps Lock or Num Lock strokes happen to hang the system).

Initialization: Not often, BugChecker initialization fails, tipically when the system is very busy in heavy I/O and/or IRQ servicing activity (disk for example). This happens because the first steps of debugger initialization (some API and interrupt ISR hooking) are done at passive level and without properly halting the concurrent CPUs: this is motivated by the fact that the debugger logs every activity at initialization through the DbgPrint API and that the initialization is suspended with a verbose output if something fails. Another reason is that the debugger touches memory at initialization that may be not present. However startup context is definitely "unsafe" and needs to be secured in some way (interrupts masked for initialization CPU and IPI/DPC+IRQL raise for concurrent CPUs + preventive touch of relevant virtual memory before IRQL raise and/or detour analysis/patching decoupling).

BugCheckerVideo stops responding consistently to debugger IOCTLs when (and if) the display driver is unloaded after system initialization: tipically this happens when the system has more than one video card and if the user switches between them.

Symbol translation engine must be converted from MsPdb dll binding to DIA SDK (partially done).