Problem with Pending IRP

NTFSD
1

Hi,

I am developing a file system filter driver for Windows XP, in which we need
to pend some READ IRPs and then complete them after we do some processing.

For this I am marking the IRP as pending in the read request of the file and
then complete it in another function. But the system is crashin once I call
IoMarkIrpPedning().

Could anyone tell why this is happening. Bugcheck analysis is below :

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 44, {81f1e008, 1b90, 0, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Module load completed but symbols could not be loaded for
ntdll.dll
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_IRP ***
*** ***
*************************************************************************

Followup: MachineOwner

nt!DbgBreakPointWithStatus+0x4:
8050d064 cc int 3
kd>
Implicit thread is now 818f8da8
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 81f1e008, Address of the IRP
Arg2: 00001b90
Arg3: 00000000
Arg4: 00000000

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_IRP ***
*** ***
*************************************************************************

MODULE_NAME: nt

FAULTING_MODULE: 804d0000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7de38f

IRP_ADDRESS: 81f1e008

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 80522dea to 8050d064

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
eee28290 80522dea 00000003 819185f8 81f1e008 nt!DbgBreakPointWithStatus+0x4
eee28658 804fc1bb 00000044 81f1e008 00001b90
nt!KeDeregisterBugCheckCallback+0x52d
eee28678 80513206 00000044 81f1e008 00001b90 nt!KeBugCheckEx+0x19
eee286a0 804ed17d 81f1e008 00000103 806b643c nt!ExRaiseStatus+0x2fd9
eee286f0 80571c40 81f1e048 eee2872c eee28738 nt!KeInsertQueueApc+0x20f
eee28718 8057c4be 81d70f10 00000000 819185f8 nt!NtWaitForSingleObject+0x345
eee287c0 804d4e91 0000024c 00000000 00000000 nt!NtReadFile+0x26f
eee287ec 818d36f8 00000008 0000000e 00000000 nt!KeInitializeInterrupt+0xa7c
818d3700 00000100 e347b010 eed7697d e2ce5868 0x818d36f8

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Any information is helpful.

Thanks,
Kedar.

2

Pls repost the bug check with the correct symbols loaded. Are you returning
STATUS_PENDING after marking the IRP as pending from the dispatch routine ?
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Tuesday, May 10, 2005 4:20 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem with Pending IRP

Hi,

I am developing a file system filter driver for Windows XP, in which we need
to pend some READ IRPs and then complete them after we do some processing.

For this I am marking the IRP as pending in the read request of the file and
then complete it in another function. But the system is crashin once I call
IoMarkIrpPedning().

Could anyone tell why this is happening. Bugcheck analysis is below :

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 44, {81f1e008, 1b90, 0, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Module load completed but symbols could not be loaded for
ntdll.dll
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_IRP ***
*** ***
*************************************************************************

Followup: MachineOwner

nt!DbgBreakPointWithStatus+0x4:
8050d064 cc int 3
kd>
Implicit thread is now 818f8da8
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers in
the system actually did this is difficult, generally because the trails of
the first driver have been covered by the second. However, the driver stack
for the current request can be found by examining the DeviceObject fields in
each of the stack locations.
Arguments:
Arg1: 81f1e008, Address of the IRP
Arg2: 00001b90
Arg3: 00000000
Arg4: 00000000

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_IRP ***
*** ***
*************************************************************************

MODULE_NAME: nt

FAULTING_MODULE: 804d0000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7de38f

IRP_ADDRESS: 81f1e008

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 80522dea to 8050d064

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
eee28290 80522dea 00000003 819185f8 81f1e008 nt!DbgBreakPointWithStatus+0x4
eee28658 804fc1bb 00000044 81f1e008 00001b90
nt!KeDeregisterBugCheckCallback+0x52d
eee28678 80513206 00000044 81f1e008 00001b90 nt!KeBugCheckEx+0x19 eee286a0
804ed17d 81f1e008 00000103 806b643c nt!ExRaiseStatus+0x2fd9 eee286f0
80571c40 81f1e048 eee2872c eee28738 nt!KeInsertQueueApc+0x20f
eee28718 8057c4be 81d70f10 00000000 819185f8 nt!NtWaitForSingleObject+0x345
eee287c0 804d4e91 0000024c 00000000 00000000 nt!NtReadFile+0x26f eee287ec
818d36f8 00000008 0000000e 00000000 nt!KeInitializeInterrupt+0xa7c 818d3700
00000100 e347b010 eed7697d e2ce5868 0x818d36f8

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Any information is helpful.

Thanks,
Kedar.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

3

Hello Kedar,

We had a similar problem in a driver (not filter driver). In that case, the
IRP was being marked as pending in the Dispatch routine and the completion
was indicated in a DpcForIsr routine. The Dispatch routine queued the
actual I/O operation and the interrupt indicated when the I/O completed.
Running the ISR, therefore, indicated completion.

Our mistake was that IoMarkIrpPending was done after queuing the I/O
operation. Now, if the Dispatch routine was pre-empted after queuing the
I/O but before marking the IRP pending, it is possible for the interrupt to
come in and complete the IRP first. Then, when the Dispatch routine is
awakened, it tries to mark an already completed IRP as pending! Sure
enough, the system crashed. Perhaps you have a similar problem. Basically,
if the completion and marking as pending are in different threads of
execution, you need to be really careful.

Incidentally, we are new to Windows system programming and we don’t know how
to generate the kind of bugcheck dump that you generated. Can you give me
any pointers on how to do that? If MSDN documentation covers it, a pointer
to that would be adequate.

Thanks,

Monish

----- Original Message -----
From: “kedar”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, May 10, 2005 4:19 PM
Subject: [ntfsd] Problem with Pending IRP

> Hi,
>
> I am developing a file system filter driver for Windows XP, in which we
> need to pend some READ IRPs and then complete them after we do some
> processing.
>
> For this I am marking the IRP as pending in the read request of the file
> and then complete it in another function. But the system is crashin once I
> call IoMarkIrpPedning().
>

… deleted …

4

When you are going to mark an IRP pending that itself means that the IRP
will be completed in some other thread. IRPs which are marked as pending are
always (unless it will be completed from the DPC which is executing in the
context of the same thread) completed in some other thread.

There are couple of excellent articles on OSR’s site, that describe how IRP
completion is handled by the IoManager and what are the rules that each
driver writer must follow for properly pending the IRPs and completion
routines.
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Monish Shah
Sent: Tuesday, May 10, 2005 6:00 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with Pending IRP

Hello Kedar,

We had a similar problem in a driver (not filter driver). In that case, the
IRP was being marked as pending in the Dispatch routine and the completion
was indicated in a DpcForIsr routine. The Dispatch routine queued the
actual I/O operation and the interrupt indicated when the I/O completed.
Running the ISR, therefore, indicated completion.

Our mistake was that IoMarkIrpPending was done after queuing the I/O
operation. Now, if the Dispatch routine was pre-empted after queuing the
I/O but before marking the IRP pending, it is possible for the interrupt to
come in and complete the IRP first. Then, when the Dispatch routine is
awakened, it tries to mark an already completed IRP as pending! Sure
enough, the system crashed. Perhaps you have a similar problem. Basically,
if the completion and marking as pending are in different threads of
execution, you need to be really careful.

Incidentally, we are new to Windows system programming and we don’t know how
to generate the kind of bugcheck dump that you generated. Can you give me
any pointers on how to do that? If MSDN documentation covers it, a pointer
to that would be adequate.

Thanks,

Monish

----- Original Message -----
From: “kedar”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, May 10, 2005 4:19 PM
Subject: [ntfsd] Problem with Pending IRP

> Hi,
>
> I am developing a file system filter driver for Windows XP, in which we
> need to pend some READ IRPs and then complete them after we do some
> processing.
>
> For this I am marking the IRP as pending in the read request of the file
> and then complete it in another function. But the system is crashin once I

> call IoMarkIrpPedning().
>

… deleted …

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Kedar,

I would bet you are queuing the Irp to your worker before you are marking
the irp pending.

Mark the irp pending before you queue it to your worker thread.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Tuesday, May 10, 2005 4:50 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem with Pending IRP

Hi,

I am developing a file system filter driver for Windows XP, in which we need

to pend some READ IRPs and then complete them after we do some processing.

For this I am marking the IRP as pending in the read request of the file and

then complete it in another function. But the system is crashin once I call
IoMarkIrpPedning().

Could anyone tell why this is happening. Bugcheck analysis is below :

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 44, {81f1e008, 1b90, 0, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Module load completed but symbols could not be loaded for
ntdll.dll
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_IRP ***
*** ***
*************************************************************************

Followup: MachineOwner

nt!DbgBreakPointWithStatus+0x4:
8050d064 cc int 3
kd>
Implicit thread is now 818f8da8
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 81f1e008, Address of the IRP
Arg2: 00001b90
Arg3: 00000000
Arg4: 00000000

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_IRP ***
*** ***
*************************************************************************

MODULE_NAME: nt

FAULTING_MODULE: 804d0000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7de38f

IRP_ADDRESS: 81f1e008

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 80522dea to 8050d064

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
eee28290 80522dea 00000003 819185f8 81f1e008 nt!DbgBreakPointWithStatus+0x4
eee28658 804fc1bb 00000044 81f1e008 00001b90
nt!KeDeregisterBugCheckCallback+0x52d
eee28678 80513206 00000044 81f1e008 00001b90 nt!KeBugCheckEx+0x19
eee286a0 804ed17d 81f1e008 00000103 806b643c nt!ExRaiseStatus+0x2fd9
eee286f0 80571c40 81f1e048 eee2872c eee28738 nt!KeInsertQueueApc+0x20f
eee28718 8057c4be 81d70f10 00000000 819185f8 nt!NtWaitForSingleObject+0x345
eee287c0 804d4e91 0000024c 00000000 00000000 nt!NtReadFile+0x26f
eee287ec 818d36f8 00000008 0000000e 00000000 nt!KeInitializeInterrupt+0xa7c
818d3700 00000100 e347b010 eed7697d e2ce5868 0x818d36f8

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Any information is helpful.

Thanks,
Kedar.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Monish,

There are several methods for forcing a crash dump, look at the .crash
command in the kernel debugger documentation. Once you have a crash dump,
you can use the perform analysis on the dump using WinDbg. The command which
Kedar used, !analyze -v, is a command in windbg to perform some quick
analysis on the reason for the crash, it walks stacks trying to ascertain
the culprit of the crash.

This command is documented in the WinDbg documentation.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Monish Shah
Sent: Tuesday, May 10, 2005 6:30 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with Pending IRP

Hello Kedar,

We had a similar problem in a driver (not filter driver). In that case, the

IRP was being marked as pending in the Dispatch routine and the completion
was indicated in a DpcForIsr routine. The Dispatch routine queued the
actual I/O operation and the interrupt indicated when the I/O completed.
Running the ISR, therefore, indicated completion.

Our mistake was that IoMarkIrpPending was done after queuing the I/O
operation. Now, if the Dispatch routine was pre-empted after queuing the
I/O but before marking the IRP pending, it is possible for the interrupt to
come in and complete the IRP first. Then, when the Dispatch routine is
awakened, it tries to mark an already completed IRP as pending! Sure
enough, the system crashed. Perhaps you have a similar problem. Basically,

if the completion and marking as pending are in different threads of
execution, you need to be really careful.

Incidentally, we are new to Windows system programming and we don’t know how

to generate the kind of bugcheck dump that you generated. Can you give me
any pointers on how to do that? If MSDN documentation covers it, a pointer
to that would be adequate.

Thanks,

Monish

----- Original Message -----
From: “kedar”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, May 10, 2005 4:19 PM
Subject: [ntfsd] Problem with Pending IRP

> Hi,
>
> I am developing a file system filter driver for Windows XP, in which we
> need to pend some READ IRPs and then complete them after we do some
> processing.
>
> For this I am marking the IRP as pending in the read request of the file
> and then complete it in another function. But the system is crashin once I

> call IoMarkIrpPedning().
>

… deleted …

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Hi Pete,

Yes. you are right I will correct it and test it.

Thanks for the information.

Kedar.
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> Kedar,
>
> I would bet you are queuing the Irp to your worker before you are marking
> the irp pending.
>
> Mark the irp pending before you queue it to your worker thread.
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
> Sent: Tuesday, May 10, 2005 4:50 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Problem with Pending IRP
>
> Hi,
>
> I am developing a file system filter driver for Windows XP, in which we
> need
>
> to pend some READ IRPs and then complete them after we do some processing.
>
> For this I am marking the IRP as pending in the read request of the file
> and
>
> then complete it in another function. But the system is crashin once I
> call
> IoMarkIrpPedning().
>
> Could anyone tell why this is happening. Bugcheck analysis is below :
>
>
>
>
> *************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *************************************************************************
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 44, {81f1e008, 1b90, 0, 0}
>
> **Kernel symbols are WRONG. Please fix symbols to do analysis.
>
> ERROR: Module load completed but symbols could not be loaded for
> ntdll.dll
>
>
>
> Your debugger is not using the correct symbols
>
> In order for this command to work properly, your symbol path
> must point to .pdb files that have full type information.
>
> Certain .pdb files (such as the public OS symbols) do not
> contain the required information. Contact the group that
> provided you with these symbols if you need this command to
> work.
>
> Type referenced: nt!_IRP
>
>
>
> Followup: MachineOwner
> ---------
>
> nt!DbgBreakPointWithStatus+0x4:
> 8050d064 cc int 3
> kd>
> Implicit thread is now 818f8da8
> kd> !analyze -v
> *************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *****
>
>
> MULTIPLE_IRP_COMPLETE_REQUESTS (44)
> A driver has requested that an IRP be completed (IoCompleteRequest()), but
> the packet has already been completed. This is a tough bug to find
> because
> the easiest case, a driver actually attempted to complete its own packet
> twice, is generally not what happened. Rather, two separate drivers each
> believe that they own the packet, and each attempts to complete it. The
> first actually works, and the second fails. Tracking down which drivers
> in the system actually did this is difficult, generally because the trails
> of the first driver have been covered by the second. However, the driver
> stack for the current request can be found by examining the DeviceObject
> fields in each of the stack locations.
> Arguments:
> Arg1: 81f1e008, Address of the IRP
> Arg2: 00001b90
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
> Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
> ******
> ******
> Your debugger is not using the correct symbols
> ******
> In order for this command to work properly, your symbol path
> must point to .pdb files that have full type information.
> ******
> Certain .pdb files (such as the public OS symbols) do not
> contain the required information. Contact the group that
> provided you with these symbols if you need this command to
> work.
> ******
> Type referenced: nt!_IRP
> ******
> *************************************************************************
>
> MODULE_NAME: nt
>
> FAULTING_MODULE: 804d0000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3b7de38f
>
> IRP_ADDRESS: 81f1e008
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x44
>
> LAST_CONTROL_TRANSFER: from 80522dea to 8050d064
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> eee28290 80522dea 00000003 819185f8 81f1e008
> nt!DbgBreakPointWithStatus+0x4
> eee28658 804fc1bb 00000044 81f1e008 00001b90
> nt!KeDeregisterBugCheckCallback+0x52d
> eee28678 80513206 00000044 81f1e008 00001b90 nt!KeBugCheckEx+0x19
> eee286a0 804ed17d 81f1e008 00000103 806b643c nt!ExRaiseStatus+0x2fd9
> eee286f0 80571c40 81f1e048 eee2872c eee28738 nt!KeInsertQueueApc+0x20f
> eee28718 8057c4be 81d70f10 00000000 819185f8
> nt!NtWaitForSingleObject+0x345
> eee287c0 804d4e91 0000024c 00000000 00000000 nt!NtReadFile+0x26f
> eee287ec 818d36f8 00000008 0000000e 00000000
> nt!KeInitializeInterrupt+0xa7c
> 818d3700 00000100 e347b010 eed7697d e2ce5868 0x818d36f8
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_NAME: MachineOwner
>
> BUCKET_ID: WRONG_SYMBOLS
>
> Followup: MachineOwner
> ---------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>