Does anyone have knowledge or know where to go to figure out this
Windows error message: VXD VMM (01) + 00009398 called From 0028:
C1548598 A in VXD V server 01+00008d7A. or Fatal Exception: OP at 3386 00000271.

This error has begun to happen on a 3 to 4 times a day basis using A5v4 230. We had gone to a beta version—to overcome heap lock failure reboots, but that version expired and there are no more versions that will work adequately in production. Now, besides the heap lock failures –which we had thought were eliminated, these are happening on our server for no apparent cause or reason.

We think that these errors are causing the server reboots without us doing it—ghosting reboots

Our Cold Fusion team believes that these are normally Virtual Device error messages.—poorly or incorrectly written or linked DLL’s , blocked threads, or bad I/0 calls or ansynchronous interrupt problems ..

Now I have no idea if it is an A5 problem—it appears to be. It is on our A5 server with huge resources.

Some examples from our Microsoft development materials:

"Cursor VxD State VMOUSE calls the cursor VxD's SAVERESTORESTATE function whenever an application uses Interrupt 33h, Functions 15h (Get State Storage Requirements), 16h (Save Mouse Driver State), and 17h (Restore Mouse Driver State). An application that uses the mouse can use functions 15h and 16h to save the state of the c Closing a VxD ursor VxD before temporarily transfering control to another application that also uses the mouse. When the first application regains control, it uses function 17h to restore the VxD's state.

or another example:

When you have finished using a VxD, you can close the associated device handle by using the CloseHandle function, or you can let the operating system close the handle when the application terminates. The following example closes a VxD. CloseHandle(hDevice);Closing a VxD does not necessarily remove the VxD from memory. If you open a dynamically loadable VxD using the LE_FLAG_DELETE_ON_CLOSE value, CloseHandle also removes the VxD if no other valid handles are present in the system. The system maintains a reference count for dynamically loadable VxDs, incrementing the count each time the VxD is opened and decrementing when the VxD is closed. CloseHandle checks this count and removes the VxD from memory when the count reaches zero. The system does not keep a reference count for static VxDs; it does not remove these VxDs when their corresponding handles are closed. In rare cases, you may need to use the DeleteFile function to remove a dynamically loadable VxD from memory. For example, you use DeleteFile if another application has loaded the VxD and you just want to unload it. You also use DeleteFile if you have successfully loaded a VxD by using CreateFile, but the VxD does not support the device IOCTL interface. In such cases, CreateFile loads the VxD but provides no handle to close and remove the VxD. The following example removes the VxD named SAMPLE from memory.
DeleteFile("\.SAMPLE"); VMOUSE calls a cursor VxD's RESETCURSORDRIVER function to reset the VxD. Typically, a cursor VxD sets all variables that control the position and appearance to default values.

or another

include vmm.inc
mov edi, ThreadHandle
mov eax, Create_Thread
VMMCall System_Control

Notifies a virtual device that the system is creating a new thread. Virtual devices typically create and initialize any structures needed to support the new thread. The virtual device may use all general registers and flags.
·The virtual device returns with carry clear to allow the thread to be created, or with carry set to prevent it from being created.
ThreadHandle
Handle of the thread being created. The thread being created is not the current thread.
If the virtual device sets the carry flag to prevent creation the thread, it should free any system resource it may have allocated to support the thread.

Interrupt simulation is not permitted in the new thread during this message. Note that this message is not sent when a new virtual machine is created, even though each virtual machine also comes with a thread. Therefore, if you need to do something whenever a new thread is created, even if it is the thread of a virtual machine, you need to perform the operation on the VM_Create message as well.

See Also
or this:

Crit_Reboot_Notify
include vmm.inc

mov eax, Crit_Reboot_Notify
VMMCall System_Control

Notifies a virtual device that the system is about to restart. Virtual devices typically prepare for restarting by cleaning up data or resetting devices. The system disables interrupts before it sends this message. The virtual device may use all general registers and flags.
·This message cannot be failed. The virtual device must return carry clear. The virtual device must not enable interrupts, nor is simulated interrupt activity allowed. See the description of the Device_Reboot_Notify message for additional information.

See Also
Crit_Reboot_Notify2, Device_Reboot_Notify Notifies a virtual device that the specified non-initial thread is about to be destroyed. This is a virtual device's last chance to free resources associated with the thread before the thread goes away. The virtual device may modify all general registers and flags. This message cannot be failed. The virtual device must return carry clear.

ThreadHandle
Handle of the thread.
Interrupt simulation is not permitted in the thread during this message.
This message is sent only to virtual devices marked 4.0, and it is sent in reverse initialization order. When a virtual machine is destroyed, no Destroy_Thread message is sent. Use the Destroy_VM message instead.


Device_Init
include vmm.inc

mov ebx, SysVMHandle
mov esi, OFFSET32 CommandTail
mov eax, Device_Init
VMMCall System_Control

Directs the virtual device to initialize itself. The virtual device typically allocates memory for a device-specific section in the control block, allocates other memory areas, hooks interrupts and I/O ports, and specifies instance data. The virtual device may use all general registers and flags.

· The virtual device returns carry clear if it initialized successfully. If the virtual device returns carry set, the system considers the device as having failed to initialize and removes it from the list of VxDs loaded in the system. Before returning carry set, a virtual device must release all resources it had claimed during previous initialization phases.

SysVMHandle
Handle of the system virtual machine.
CommandTail
Address of the command tail retrieved from the program segment prefix (PSP) of VMM32.VXD. The first byte in the command tail specifies the length in bytes of the tail.
The virtual device should allocate a device-specific section in the control block of the system virtual machine and then initialize the section.
The virtual device can call the Simulate_Int and Exec_Int services in the system virtual machine.
For dynamically loaded VxDs, the EBX register does not contain a VM handle.
See Also
Init_Complete, Sys_Critical_Init

Device_Reboot_Notify
include vmm.inc

mov eax, Device_Reboot_Notify
VMMCall System_Control

Notifies the virtual device that the system is about to restart. Interrupts remain enabled while virtual devices process this message. The virtual device may modify all general registers and flags.
This message cannot be failed. The virtual device must return carry clear. When the system is about to be rebooted abnormally, virtual devices will first receive the Device_Reboot_Notify message (and possibly also the Device_Reboot_Notify2 message), at which time interrupts are enabled and simulated interrupt activity is allowed (although not encouraged). Next, virtual devices receive the Crit_Reboot_Notify message (and possibly also the Crit_Reboot_Notify2 message) with interrupts disabled, during which time interrupts must not be enabled by the virtual device, and at which time simulated interrupt activity is not allowed. Finally, virtual devices receive the Reboot_Processor message, which all devices except the virtual keyboard device should ignore.
See Also
Crit_Reboot_Notify, Device_Reboot_Notify2, Reboot_Processor


Any ideas out there?