double fault when opening root directory

In my driver entry function I attempt to open the root
directory of a DVD drive (L"\DosDevices\D:\").

This results in the following double fault shown
below.

I am in the process of removing other potentially
conflicting software, checking for updates, etc…

My question is, is it appropriate to do a ZwCreateFile
on the root directory of a file system in my driver
entry function?

Thanks,

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a
trap of a kind
that the kernel isn’t allowed to have/catch (bound
trap) or that
is always instant death (double fault). The first
number in the
bugcheck params is the number of the trap (8 = double
fault, etc)
Consult an Intel x86 family manual to learn more about
what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then
kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where
the trap was taken
(on x86, this will be the ebp that goes with
the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 – (.tss 28)
eax=0000000e ebx=813f1008 ecx=8178b9d0 edx=813f1008
esi=817b2840 edi=813f116c
eip=f9a06746 esp=f9e69fec ebp=f9e6a000 iopl=0
nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010292
ACPI!ACPIDispatchIrp+0x6:
f9a06746 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804ea221 to f9a06746

STACK_TEXT:
f9e6a000 804ea221 8178b9d0 813f1008 81629da0
ACPI!ACPIDispatchIrp+0x6
f9e6a010 f97e9cee 8178b9d0 81627db8 f9e6a99c
nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available.
Following frames may be wrong.
f9e6a020 f97ef6dd 81627d00 813f1008 81629da0
Cdr4_xp+0x2cee
f9e6a99c 804ea221 81627d00 813f1008 813f1190
Cdr4_xp+0x86dd
f9e6a9ac f9a9ee6a 815f87b8 81634aa8 00000000
nt!IopfCallDriver+0x31
f9e6aa24 f9b31442 815f87b8 813f1174 813f1008
CLASSPNP!ClassDeviceControl+0x848
f9e6aaac f9a9e403 815f87b8 00000501 8168b310
cdrom!CdRomDeviceControlDispatch+0x4bf
f9e6aac4 804ea221 815f87b8 813f1008 81629508
CLASSPNP!ClassDeviceControlDispatch+0x45
f9e6aad4 f9b3da33 f9e6ab20 f9b3eb87 814fd020
nt!IopfCallDriver+0x31
f9e6aadc f9b3eb87 814fd020 813f1008 f9aa3326
redbook!RedBookSendToNextDriver+0x33
f9e6ab20 804ea221 814fd020 813f1008 8168b310
redbook!RedBookDeviceControl+0x53e
f9e6ab30 f9d18ae2 813f1008 f9d16071 8168b258
nt!IopfCallDriver+0x31
f9e6ab60 804ea221 8168b258 813f1008 816279a8
Cdralw2k+0x3ae2
f9e6ab70 f97aa5ff 804f430a 816279a8 00000000
nt!IopfCallDriver+0x31
f9e6abd4 804ea221 814fb018 813f1008 81629da0
pwd_2k+0x5ff
f9e6abe4 f97e75c3 8059ba2f 8104d800 00000000
nt!IopfCallDriver+0x31
f9e6ac44 f97e8a4c 814fb018 f9e6ac98 81629da0
Cdr4_xp+0x5c3
f9e6acac f97ebabc 815090e0 81627d00 81629da0
Cdr4_xp+0x1a4c
f9e6b628 804ea221 81509028 816cb138 816e3748
Cdr4_xp+0x4abc
f9e6b638 f80c7b9e 00000001 00000000 00040000
nt!IopfCallDriver+0x31
f9e6b660 f80c92ab 00000044 8141b030 8141b030
cdudf_xp+0x3b9e
f9e6b738 ffffffff 00000008 00000000 0000001f
cdudf_xp+0x52ab
804f1ff1 01ff45c6 23f205c6 e8018065 ffffff93
0xffffffff
0b75c085 00000000 00000000 00000000 00000000 0x1ff45c6

FOLLOWUP_IP:
ACPI!ACPIDispatchIrp+6
f9a06746 53 push ebx

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ACPI!ACPIDispatchIrp+6

MODULE_NAME: ACPI

IMAGE_NAME: ACPI.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6dd69f

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_ACPI!ACPIDispatchIrp+6

Followup: MachineOwner


Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com

The most common reason for this in my experience is blowing the kernel stack
– you do seem to have just hit a page boundary from the stack trace but to
be sure type !thread and look at the stack limits for the current thread…

/simgr

-----Original Message-----
From: Randy Cook [mailto:xxxxx@yahoo.com]
Sent: Wednesday, August 11, 2004 1:01 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] double fault when opening root directory

In my driver entry function I attempt to open the root
directory of a DVD drive (L"\DosDevices\D:\").

This results in the following double fault shown
below.

I am in the process of removing other potentially
conflicting software, checking for updates, etc…

My question is, is it appropriate to do a ZwCreateFile
on the root directory of a file system in my driver
entry function?

Thanks,

kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a
trap of a kind
that the kernel isn’t allowed to have/catch (bound
trap) or that
is always instant death (double fault). The first
number in the
bugcheck params is the number of the trap (8 = double
fault, etc)
Consult an Intel x86 family manual to learn more about
what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then
kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where
the trap was taken
(on x86, this will be the ebp that goes with
the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 – (.tss 28)
eax=0000000e ebx=813f1008 ecx=8178b9d0 edx=813f1008
esi=817b2840 edi=813f116c
eip=f9a06746 esp=f9e69fec ebp=f9e6a000 iopl=0
nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010292
ACPI!ACPIDispatchIrp+0x6:
f9a06746 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804ea221 to f9a06746

STACK_TEXT:
f9e6a000 804ea221 8178b9d0 813f1008 81629da0
ACPI!ACPIDispatchIrp+0x6
f9e6a010 f97e9cee 8178b9d0 81627db8 f9e6a99c
nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available.
Following frames may be wrong.
f9e6a020 f97ef6dd 81627d00 813f1008 81629da0
Cdr4_xp+0x2cee
f9e6a99c 804ea221 81627d00 813f1008 813f1190
Cdr4_xp+0x86dd
f9e6a9ac f9a9ee6a 815f87b8 81634aa8 00000000
nt!IopfCallDriver+0x31
f9e6aa24 f9b31442 815f87b8 813f1174 813f1008
CLASSPNP!ClassDeviceControl+0x848
f9e6aaac f9a9e403 815f87b8 00000501 8168b310
cdrom!CdRomDeviceControlDispatch+0x4bf
f9e6aac4 804ea221 815f87b8 813f1008 81629508
CLASSPNP!ClassDeviceControlDispatch+0x45
f9e6aad4 f9b3da33 f9e6ab20 f9b3eb87 814fd020
nt!IopfCallDriver+0x31
f9e6aadc f9b3eb87 814fd020 813f1008 f9aa3326
redbook!RedBookSendToNextDriver+0x33
f9e6ab20 804ea221 814fd020 813f1008 8168b310
redbook!RedBookDeviceControl+0x53e
f9e6ab30 f9d18ae2 813f1008 f9d16071 8168b258
nt!IopfCallDriver+0x31
f9e6ab60 804ea221 8168b258 813f1008 816279a8
Cdralw2k+0x3ae2
f9e6ab70 f97aa5ff 804f430a 816279a8 00000000
nt!IopfCallDriver+0x31
f9e6abd4 804ea221 814fb018 813f1008 81629da0
pwd_2k+0x5ff
f9e6abe4 f97e75c3 8059ba2f 8104d800 00000000
nt!IopfCallDriver+0x31
f9e6ac44 f97e8a4c 814fb018 f9e6ac98 81629da0
Cdr4_xp+0x5c3
f9e6acac f97ebabc 815090e0 81627d00 81629da0
Cdr4_xp+0x1a4c
f9e6b628 804ea221 81509028 816cb138 816e3748
Cdr4_xp+0x4abc
f9e6b638 f80c7b9e 00000001 00000000 00040000
nt!IopfCallDriver+0x31
f9e6b660 f80c92ab 00000044 8141b030 8141b030
cdudf_xp+0x3b9e
f9e6b738 ffffffff 00000008 00000000 0000001f
cdudf_xp+0x52ab
804f1ff1 01ff45c6 23f205c6 e8018065 ffffff93
0xffffffff
0b75c085 00000000 00000000 00000000 00000000 0x1ff45c6

FOLLOWUP_IP:
ACPI!ACPIDispatchIrp+6
f9a06746 53 push ebx

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ACPI!ACPIDispatchIrp+6

MODULE_NAME: ACPI

IMAGE_NAME: ACPI.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6dd69f

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_ACPI!ACPIDispatchIrp+6

Followup: MachineOwner


Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com


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

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

Sure enough, that was it.

Thanks!

— “Graham, Simon” wrote:

> The most common reason for this in my experience is
> blowing the kernel stack
> – you do seem to have just hit a page boundary from
> the stack trace but to
> be sure type !thread and look at the stack limits
> for the current thread…
>
> /simgr
>
> -----Original Message-----
> From: Randy Cook [mailto:xxxxx@yahoo.com]
> Sent: Wednesday, August 11, 2004 1:01 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] double fault when opening root
> directory
>
> In my driver entry function I attempt to open the
> root
> directory of a DVD drive (L"\DosDevices\D:\").
>
> This results in the following double fault shown
> below.
>
> I am in the process of removing other potentially
> conflicting software, checking for updates, etc…
>
> My question is, is it appropriate to do a
> ZwCreateFile
> on the root directory of a file system in my driver
> entry function?
>
> Thanks,
>
>
> kd> !analyze -v
>
*************************************************************************
>

> *
>
> *
> * Bugcheck Analysis
>
> *
> *
>
> *
>
*************************************************************************
>

>
> UNEXPECTED_KERNEL_MODE_TRAP (7f)
> This means a trap occurred in kernel mode, and it’s
> a
> trap of a kind
> that the kernel isn’t allowed to have/catch (bound
> trap) or that
> is always instant death (double fault). The first
> number in the
> bugcheck params is the number of the trap (8 =
> double
> fault, etc)
> Consult an Intel x86 family manual to learn more
> about
> what these
> traps are. Here is a portion of those codes:
> If kv shows a taskGate
> use .tss on the part before the colon, then
> kv.
> Else if kv shows a trapframe
> use .trap on that value
> Else
> .trap on the appropriate frame will show
> where
> the trap was taken
> (on x86, this will be the ebp that goes with
> the procedure KiTrap)
> Endif
> kb will then show the corrected stack.
> Arguments:
> Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
> Arg2: 80042000
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0x7f_8
>
> TSS: 00000028 – (.tss 28)
> eax=0000000e ebx=813f1008 ecx=8178b9d0 edx=813f1008
> esi=817b2840 edi=813f116c
> eip=f9a06746 esp=f9e69fec ebp=f9e6a000 iopl=0
>
> nv up ei ng nz ac pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>
> efl=00010292
> ACPI!ACPIDispatchIrp+0x6:
> f9a06746 53 push ebx
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from 804ea221 to f9a06746
>
> STACK_TEXT:
> f9e6a000 804ea221 8178b9d0 813f1008 81629da0
> ACPI!ACPIDispatchIrp+0x6
> f9e6a010 f97e9cee 8178b9d0 81627db8 f9e6a99c
> nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available.
> Following frames may be wrong.
> f9e6a020 f97ef6dd 81627d00 813f1008 81629da0
> Cdr4_xp+0x2cee
> f9e6a99c 804ea221 81627d00 813f1008 813f1190
> Cdr4_xp+0x86dd
> f9e6a9ac f9a9ee6a 815f87b8 81634aa8 00000000
> nt!IopfCallDriver+0x31
> f9e6aa24 f9b31442 815f87b8 813f1174 813f1008
> CLASSPNP!ClassDeviceControl+0x848
> f9e6aaac f9a9e403 815f87b8 00000501 8168b310
> cdrom!CdRomDeviceControlDispatch+0x4bf
> f9e6aac4 804ea221 815f87b8 813f1008 81629508
> CLASSPNP!ClassDeviceControlDispatch+0x45
> f9e6aad4 f9b3da33 f9e6ab20 f9b3eb87 814fd020
> nt!IopfCallDriver+0x31
> f9e6aadc f9b3eb87 814fd020 813f1008 f9aa3326
> redbook!RedBookSendToNextDriver+0x33
> f9e6ab20 804ea221 814fd020 813f1008 8168b310
> redbook!RedBookDeviceControl+0x53e
> f9e6ab30 f9d18ae2 813f1008 f9d16071 8168b258
> nt!IopfCallDriver+0x31
> f9e6ab60 804ea221 8168b258 813f1008 816279a8
> Cdralw2k+0x3ae2
> f9e6ab70 f97aa5ff 804f430a 816279a8 00000000
> nt!IopfCallDriver+0x31
> f9e6abd4 804ea221 814fb018 813f1008 81629da0
> pwd_2k+0x5ff
> f9e6abe4 f97e75c3 8059ba2f 8104d800 00000000
> nt!IopfCallDriver+0x31
> f9e6ac44 f97e8a4c 814fb018 f9e6ac98 81629da0
> Cdr4_xp+0x5c3
> f9e6acac f97ebabc 815090e0 81627d00 81629da0
> Cdr4_xp+0x1a4c
> f9e6b628 804ea221 81509028 816cb138 816e3748
> Cdr4_xp+0x4abc
> f9e6b638 f80c7b9e 00000001 00000000 00040000
> nt!IopfCallDriver+0x31
> f9e6b660 f80c92ab 00000044 8141b030 8141b030
> cdudf_xp+0x3b9e
> f9e6b738 ffffffff 00000008 00000000 0000001f
> cdudf_xp+0x52ab
> 804f1ff1 01ff45c6 23f205c6 e8018065 ffffff93
> 0xffffffff
> 0b75c085 00000000 00000000 00000000 00000000
> 0x1ff45c6
>
>
> FOLLOWUP_IP:
> ACPI!ACPIDispatchIrp+6
> f9a06746 53 push ebx
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: ACPI!ACPIDispatchIrp+6
>
> MODULE_NAME: ACPI
>
> IMAGE_NAME: ACPI.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3d6dd69f
>
> STACK_COMMAND: .tss 28 ; kb
>
> BUCKET_ID: 0x7f_8_ACPI!ACPIDispatchIrp+6
>
> Followup: MachineOwner
> ---------
>
>
>
>
>
> Do you Yahoo!?
> Express yourself with Y! Messenger! Free. Download
> now.
> http://messenger.yahoo.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@stratus.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
>
=== message truncated ===

___________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Kernel stack overflow.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Randy Cook”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, August 11, 2004 9:01 PM
Subject: [ntfsd] double fault when opening root directory

> In my driver entry function I attempt to open the root
> directory of a DVD drive (L"\DosDevices\D:\").
>
> This results in the following double fault shown
> below.