Please help me to analyze BugCheck 48
Please help me to analyze BugCheck 48
Could you help me to find which driver causes the problem?
I have Terminal Server based on Windows Server 2008 SP running on Hyper-V virtual machine. Last Friday the machine restarted itself during working days. I found memory.dmp file and analyzed it using Windows Debugger.
BugCheck 48, {fffffa801ec2ec60, fffffa60033169c8, 0, 0}
CANCEL_STATE_IN_COMPLETED_IRP (4
This bugcheck indicates that an I/O Request Packet (IRP) that is to be
cancelled, has a cancel routine specified in it -- meaning that the packet
is in a state in which the packet can be cancelled -- however, the packet
no longer belongs to a driver, as it has entered I/O completion. This is
either a driver bug, or more than one driver is accessing the same packet,
which is not likely and much more difficult to find. The cancel routine
parameter will provide a clue as to which driver or stack is the culprit.
Arguments:
Arg1: fffffa801ec2ec60, Pointer to the IRP
Arg2: fffffa60033169c8, Cancel routine set by the driver.
Arg3: 0000000000000000
Arg4: 0000000000000000
So it looks problem is in driver (in Hyper-v machine?) but how to find which driver? Could you help me find the answer please? Does Microsoft publish drivers’ updates for Hyper-V?
Best Regards
Could you help me to find which driver causes the problem?
I have Terminal Server based on Windows Server 2008 SP running on Hyper-V virtual machine. Last Friday the machine restarted itself during working days. I found memory.dmp file and analyzed it using Windows Debugger.
BugCheck 48, {fffffa801ec2ec60, fffffa60033169c8, 0, 0}
CANCEL_STATE_IN_COMPLETED_IRP (4
This bugcheck indicates that an I/O Request Packet (IRP) that is to be
cancelled, has a cancel routine specified in it -- meaning that the packet
is in a state in which the packet can be cancelled -- however, the packet
no longer belongs to a driver, as it has entered I/O completion. This is
either a driver bug, or more than one driver is accessing the same packet,
which is not likely and much more difficult to find. The cancel routine
parameter will provide a clue as to which driver or stack is the culprit.
Arguments:
Arg1: fffffa801ec2ec60, Pointer to the IRP
Arg2: fffffa60033169c8, Cancel routine set by the driver.
Arg3: 0000000000000000
Arg4: 0000000000000000
So it looks problem is in driver (in Hyper-v machine?) but how to find which driver? Could you help me find the answer please? Does Microsoft publish drivers’ updates for Hyper-V?
Best Regards