About Breakpoints and Callbacks

Breakpoints and callbacks provide a mechanism for transferring control from ring 3 to ring 0 in a controlled manner.

Callbacks are typically given by VxDs to applications so that the application can call back into the VxD as part of a service request. The application performs a far call indirect to the callback address. VMM will perform a Simulate_Far_Return before dispatching the callback to the VxD that installed it. The VxD typically inspects and/or modifies client registers, then returns. Execution then resumes in the application at the instruction following the "call far".

Breakpoints are typically installed by a VxD into existing V86-mode code that needs to be patched. When execution reaches the breakpoint, VMM dispatches the breakpoint directly to the VxD that installed it. The VxD typically inspects and/or modifies client registers, then moves the client (E)IP register past the breakpoint so as to resume execution. Note that, unlike callbacks, it is the VxD's responsibility to adjust the client (E)IP register to point to the location where execution should resume when servicing of the breakpoint is complete. If you forget to do this, the breakpoint will merely be hit again immediately.

Since there are no facilities for freeing breakpoints or callbacks, they should be treated as scarce resources. Dynamically-loaded VxDs which allocate callbacks should save the callback in a static data segment so a new callback is not allocated each time the VxD is loaded.

Note

Breakpoints are supported only for V86-mode code. Moreover, protected-mode callbacks are not supported from a Win32 application. If a Win32 application needs to communicate with a VxD, it must use the DeviceIoControl mechanism.

There are the following break point and callback services: