Hook_PM_Fault

include vmm.inc

mov     eax, FaultNo          ; fault number to hook
mov     esi, OFFSET32 FaultProc ; points to a fault handler
VMMcall Hook_PM_Fault

jc      not_installed           ; carry flag set if not installed
; The following line is optional. See the following comments section.
mov     [Previous], esi         ; points to previous fault handler (if any)

Installs a fault handler procedure for faults encountered by protected mode applications. Virtual devices typically install fault handlers while processing the Sys_Critical_Init control message to handle faults, such as general protection faults, that the VMM fault handlers cannot handle. The VMM installs its fault handlers only after the Sys_Critical_Init control message. Virtual devices install fault handlers after Sys_Critical_Init to handle faults before the fault is passed to the VMM fault handlers. Uses ESI, Flags.

• Returns with the carry flag clear if successful, set otherwise. If the carry flag is clear, and if FaultProc is a hook procedure, the address of the previous handler is stored into the hook variable. If there was no previous handler, the address of the default handler is stored in the hook variable. Whether or not FaultProc is a hook procedure, the ESI register contains the address of the previous fault handler (zero if there was no previous handler). The return value in ESI exists solely for backwards compatibility with Windows 3.1.

FaultNo

Fault number for which to install the fault handler. The fault number cannot be 02h, and must not be greater than 4Fh.

FaultProc

Points to the fault handler to install, which should be a hook procedure in order to be compatible with future versions of Windows. For more information about the handler, see below.

A virtual device can install a fault handler while processing the Sys_Critical_Init message or at a later time. When a fault occurs, fault handlers installed after the Sys_Critical_Init message receive control first, the VMM fault handlers receive control next, and fault handlers installed during the Sys_Critical_Init message receive control last. (Of course, dynamically-loaded VxDs have no choice but to install the fault handler after Sys_Critical_Init, since they haven't yet been loaded at the time the Sys_Critical_Init message is broadcast.

The system disables interrupts, and calls the fault handler as follows:

mov     ebx, VM                 ; current VM handle
mov     ebp, OFFSET32 crs       ; points to a Client_Reg_Struc
call    [FaultProc]

The VM parameter is a handle identifying the current virtual machine, and the crs parameter points to a Client_Reg_Struc structure containing the register values for the current virtual machine.

If the fault procedure does not process the fault, it should pass the fault to the previous fault handler as stored into the hook variable, making sure that all registers are preserved (not just the registers containing input parameters).

The default fault handler calls the fault vector installed by the protected-mode application. (Protected-mode fault hooks gain control before the application sees the fault.)

If the fault handler processes the fault, the handler should return without chaining by executing a near ret instruction (not an iret instruction).

The fault handler can modify the EAX, EBX, ECX, EDX, ESI, and EDI registers.

Do not use this service to install a fault handler for the Non-Maskable Interrupt (NMI). Instead, a virtual device must use the Get_NMI_Handler_Addr and Set_NMI_Handler_Addr services.

Do not use this service to install handlers for hardware interrupts. Instead, a virtual device must use virtual PIC device services.

See also Hook_V86_Fault, Hook_VMM_Fault