ZwCreateFile causes UNEXPECTED_KERNEL_MODE_TRAP when PC starts with Ndis WDM device inserted

Hi all

If I boot the PC with the Ndis WDM device inserted, I get the following
BSOD when ZwCreateFile is called from MiniportInitialise. When the
device is inserted after the PC has booted there is no problem. Here is
the code.

RtlInitUnicodeString(&ObjectName,
L"\\SystemRoot\\system32\\drivers\\GTNDIS.cfg");

InitializeObjectAttributes(&ObjectAttributes,
&ObjectName,
OBJ_CASE_INSENSITIVE,
NULL,
NULL);

Status = ZwCreateFile( &hfile,
FILE_READ_DATA | SYNCHRONIZE | DELETE,
&ObjectAttributes,
&IoStatusBlock,
NULL, FILE_ATTRIBUTE_NORMAL,
0,
FILE_OPEN,
FILE_DELETE_ON_CLOSE | FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0);

Here is the trace:

*******************************************************************************
*
*
* 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=89d162b0 ebx=89d162b0 ecx=00000001 edx=00000000 esi=89cb2100
edi=bad01700
eip=ba626b0f esp=bad01000 ebp=bad01004 iopl=0 nv up ei pl zr na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Ntfs!NtfsMcbLookupArrayIndex+0xc:
ba626b0f 56 push esi
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from ba626a50 to ba626b0f

STACK_TEXT:
bad01004 ba626a50 89d162b0 00000006 00000000
Ntfs!NtfsMcbLookupArrayIndex+0xc
bad01030 ba626bbb 89d162b0 00000006 00000000
Ntfs!NtfsLookupNtfsMcbEntry+0x23
bad0113c ba62707c bad01700 89d16218 00000006
Ntfs!NtfsLookupAllocation+0x5b
bad0130c ba626cf6 bad01700 8ac64e70 89d16218
Ntfs!NtfsPrepareBuffers+0x270
bad014f4 ba62803b bad01700 8ac64e70 89d16218 Ntfs!NtfsNonCachedIo+0x20e
bad016f0 ba627c97 bad01700 8ac64e70 0110070a
Ntfs!NtfsCommonWrite+0x1824
bad01864 804eddf9 89cb2020 8ac64e70 806d02e8 Ntfs!NtfsFsdWrite+0xf3
bad01874 8064b5a8 8ac64e70 89d1a040 89d15530 nt!IopfCallDriver+0x31
bad01898 ba6ca3ca 89d15478 89d15400 bad018dc nt!IovCallDriver+0xa0
bad018a8 804eddf9 89d15478 8ac64e70 806d02e8 sr!SrWrite+0xaa
bad018b8 8064b5a8 89cb0a28 00003000 89d15478 nt!IopfCallDriver+0x31
bad018dc 804ef0d5 e17af8f8 00001000 e1507658 nt!IovCallDriver+0xa0
bad018f0 ba647e86 89cb0a08 89da6428 bad01994
nt!IoSynchronousPageWrite+0xaf
bad019bc ba647f50 e1507658 e17af8f8 e1507658 Ntfs!LfsFlushLfcb+0x429
bad019e0 ba64da1f e1507658 e17af8f8 e157a230 Ntfs!LfsFlushLbcb+0x81
bad01a08 ba646a8e e1507658 0993b51c 00000000
Ntfs!LfsFlushToLsnPriv+0xf3
bad01a48 ba658341 e157a230 0993b51c 00000000 Ntfs!LfsFlushToLsn+0x8e
bad01a7c ba650110 899e7a98 e1650be0 e1650ca8
Ntfs!NtfsCommitCurrentTransaction+0x215
bad01a90 ba65169f 899e7a98 899e7a98 e1650ca8
Ntfs!NtfsCheckpointCurrentTransaction+0x21
bad01b64 ba650e2f 899e7a98 89b9e608 8abaee90
Ntfs!NtfsSetEndOfFileInfo+0x5ea
bad01bd4 ba629ad8 899e7a98 8abaee90 89cb2020
Ntfs!NtfsCommonSetInformation+0x477
bad01c3c 804eddf9 89cb2020 8abaee90 806d02e8
Ntfs!NtfsFsdSetInformation+0xa3
bad01c4c 8064b5a8 8abaefd8 8abaeea0 8abaee90 nt!IopfCallDriver+0x31
bad01c70 8056f689 bad01d38 bad01dc4 8056f11a nt!IovCallDriver+0xa0
bad01d1c 8053c808 8000034c bad01e50 bad01e20
nt!NtSetInformationFile+0x56f
bad01d1c 804fe405 8000034c bad01e50 bad01e20 nt!KiFastCallEntry+0xf8
bad01da8 ba6ce1e4 8000034c bad01e50 bad01e20
nt!ZwSetInformationFile+0x11
bad01e5c ba6ce502 80000310 89cb2020 e1760c08 sr!SrCopyStream+0x22e
bad01fd8 ba6ce87b 89d15530 89c16f90 e1750754 sr!SrBackupFile+0x2b0
bad02040 ba6d05a9 89d15530 00010010 89c16f90 sr!SrBackupFileAndLog+0x4b
bad02068 ba6d12c8 89d15530 00010010 89c16f90 sr!SrHandleFileChange+0x59
bad020b4 ba6cfa22 89d15530 00010010 89c16f90 sr!SrHandleEvent+0x194
bad02118 804eddf9 00000000 00000001 806d02e8 sr!SrCreate+0x2fc
bad02128 8064b5a8 89e8ce80 89e8ce70 89c16f90 nt!IopfCallDriver+0x31
bad0214c 805773bc 89d128e8 89cc819c bad022f4 nt!IovCallDriver+0xa0
bad0222c 805b365e 89d12900 00000000 89cc80f8 nt!IopParseDevice+0xa58
bad022b4 805afb3f 00000000 bad022f4 00000040
nt!ObpLookupObjectName+0x56a
bad02308 8056a133 00000000 00000000 d0245400 nt!ObOpenObjectByName+0xeb
bad02384 8056aaaa bad03408 00110001 bad033e8 nt!IopCreateFile+0x407
bad023e0 8056d17c bad03408 00110001 bad033e8 nt!IoCreateFile+0x8e
bad02420 8053c808 bad03408 00110001 bad033e8 nt!NtCreateFile+0x30
bad02420 804fd569 bad03408 00110001 bad033e8 nt!KiFastCallEntry+0xf8
bad024c4 a9d23c57 bad03408 00110001 bad033e8 nt!ZwCreateFile+0x11
bad0340c a9d24ffc 899b2000 899cfad0 ba5fad0c
Gtm51Irp!ReadRegistryParamsFromFileFunc+0x61
[c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 2392]
bad035f0 a9d1e967 899b2000 bad038ec 00000000
Gtm51Irp!ParseRegistryParameters+0x1de
[c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 119]
bad03710 ba603dea bad0374c bad03754 ba5ff200
Gtm51Irp!GPRSZCSInitialize+0x4c5
[c:\work\driver\source\projects\cobra\gtndisirp\main.c @ 493]
bad038c8 ba6039cc 89b92950 bad038ec bad03994
NDIS!ndisMInitializeAdapter+0x3b7
bad0399c ba6038ba 89b92950 00000000 89cc3be8
NDIS!ndisInitializeAdapter+0xb9
bad039d0 ba604d99 899cf9d0 89b5e040 8ac5cd00
NDIS!ndisPnPStartDevice+0xd6
bad03a00 804eddf9 899cf9d0 8ac5cdb8 806d02e8 NDIS!ndisPnPDispatch+0x306


FOLLOWUP_IP:
Gtm51Irp!ReadRegistryParamsFromFileFunc+61
[c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 2392]
a9d23c57 85c0 test eax,eax

SYMBOL_STACK_INDEX: 2b

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Gtm51Irp!ReadRegistryParamsFromFileFunc+61

MODULE_NAME: Gtm51Irp

IMAGE_NAME: Gtm51Irp.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 443b655c

STACK_COMMAND: .tss 28 ; kb

FAILURE_BUCKET_ID: 0x7f_8_Gtm51Irp!ReadRegistryParamsFromFileFunc+61

BUCKET_ID: 0x7f_8_Gtm51Irp!ReadRegistryParamsFromFileFunc+61

Followup: MachineOwner
---------


Is this expected? If so, is there a way of waiting untill the system
is sufficiently up to support this call?

Thanks in advence for any input on this.

fat_boy
Tue Apr 11 06:06:21 CDT 2006

Oh, by the way, there is no antivirus SW running.

And additionally, if I dont open the file for delete, I dont get the
BSOD.

So what I have had to do is call a workitem routine at the end of
miniportinitialise to do the deletion.

pavel_a
Tue Apr 11 09:46:03 CDT 2006

What if you add OBJ_KERNEL_HANDLE and OBJ_OPENIF ?

--PA

"fat_boy" wrote:
> Hi all
>
> If I boot the PC with the Ndis WDM device inserted, I get the following
> BSOD when ZwCreateFile is called from MiniportInitialise. When the
> device is inserted after the PC has booted there is no problem. Here is
> the code.
>
> RtlInitUnicodeString(&ObjectName,
> L"\\SystemRoot\\system32\\drivers\\GTNDIS.cfg");
>
> InitializeObjectAttributes(&ObjectAttributes,
> &ObjectName,
> OBJ_CASE_INSENSITIVE,
> NULL,
> NULL);
>
> Status = ZwCreateFile( &hfile,
> FILE_READ_DATA | SYNCHRONIZE | DELETE,
> &ObjectAttributes,
> &IoStatusBlock,
> NULL, FILE_ATTRIBUTE_NORMAL,
> 0,
> FILE_OPEN,
> FILE_DELETE_ON_CLOSE | FILE_SYNCHRONOUS_IO_NONALERT,
> NULL,
> 0);
>
> Here is the trace:
>
> *******************************************************************************
> *
> *
> * 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=89d162b0 ebx=89d162b0 ecx=00000001 edx=00000000 esi=89cb2100
> edi=bad01700
> eip=ba626b0f esp=bad01000 ebp=bad01004 iopl=0 nv up ei pl zr na
> po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> Ntfs!NtfsMcbLookupArrayIndex+0xc:
> ba626b0f 56 push esi
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from ba626a50 to ba626b0f
>
> STACK_TEXT:
> bad01004 ba626a50 89d162b0 00000006 00000000
> Ntfs!NtfsMcbLookupArrayIndex+0xc
> bad01030 ba626bbb 89d162b0 00000006 00000000
> Ntfs!NtfsLookupNtfsMcbEntry+0x23
> bad0113c ba62707c bad01700 89d16218 00000006
> Ntfs!NtfsLookupAllocation+0x5b
> bad0130c ba626cf6 bad01700 8ac64e70 89d16218
> Ntfs!NtfsPrepareBuffers+0x270
> bad014f4 ba62803b bad01700 8ac64e70 89d16218 Ntfs!NtfsNonCachedIo+0x20e
> bad016f0 ba627c97 bad01700 8ac64e70 0110070a
> Ntfs!NtfsCommonWrite+0x1824
> bad01864 804eddf9 89cb2020 8ac64e70 806d02e8 Ntfs!NtfsFsdWrite+0xf3
> bad01874 8064b5a8 8ac64e70 89d1a040 89d15530 nt!IopfCallDriver+0x31
> bad01898 ba6ca3ca 89d15478 89d15400 bad018dc nt!IovCallDriver+0xa0
> bad018a8 804eddf9 89d15478 8ac64e70 806d02e8 sr!SrWrite+0xaa
> bad018b8 8064b5a8 89cb0a28 00003000 89d15478 nt!IopfCallDriver+0x31
> bad018dc 804ef0d5 e17af8f8 00001000 e1507658 nt!IovCallDriver+0xa0
> bad018f0 ba647e86 89cb0a08 89da6428 bad01994
> nt!IoSynchronousPageWrite+0xaf
> bad019bc ba647f50 e1507658 e17af8f8 e1507658 Ntfs!LfsFlushLfcb+0x429
> bad019e0 ba64da1f e1507658 e17af8f8 e157a230 Ntfs!LfsFlushLbcb+0x81
> bad01a08 ba646a8e e1507658 0993b51c 00000000
> Ntfs!LfsFlushToLsnPriv+0xf3
> bad01a48 ba658341 e157a230 0993b51c 00000000 Ntfs!LfsFlushToLsn+0x8e
> bad01a7c ba650110 899e7a98 e1650be0 e1650ca8
> Ntfs!NtfsCommitCurrentTransaction+0x215
> bad01a90 ba65169f 899e7a98 899e7a98 e1650ca8
> Ntfs!NtfsCheckpointCurrentTransaction+0x21
> bad01b64 ba650e2f 899e7a98 89b9e608 8abaee90
> Ntfs!NtfsSetEndOfFileInfo+0x5ea
> bad01bd4 ba629ad8 899e7a98 8abaee90 89cb2020
> Ntfs!NtfsCommonSetInformation+0x477
> bad01c3c 804eddf9 89cb2020 8abaee90 806d02e8
> Ntfs!NtfsFsdSetInformation+0xa3
> bad01c4c 8064b5a8 8abaefd8 8abaeea0 8abaee90 nt!IopfCallDriver+0x31
> bad01c70 8056f689 bad01d38 bad01dc4 8056f11a nt!IovCallDriver+0xa0
> bad01d1c 8053c808 8000034c bad01e50 bad01e20
> nt!NtSetInformationFile+0x56f
> bad01d1c 804fe405 8000034c bad01e50 bad01e20 nt!KiFastCallEntry+0xf8
> bad01da8 ba6ce1e4 8000034c bad01e50 bad01e20
> nt!ZwSetInformationFile+0x11
> bad01e5c ba6ce502 80000310 89cb2020 e1760c08 sr!SrCopyStream+0x22e
> bad01fd8 ba6ce87b 89d15530 89c16f90 e1750754 sr!SrBackupFile+0x2b0
> bad02040 ba6d05a9 89d15530 00010010 89c16f90 sr!SrBackupFileAndLog+0x4b
> bad02068 ba6d12c8 89d15530 00010010 89c16f90 sr!SrHandleFileChange+0x59
> bad020b4 ba6cfa22 89d15530 00010010 89c16f90 sr!SrHandleEvent+0x194
> bad02118 804eddf9 00000000 00000001 806d02e8 sr!SrCreate+0x2fc
> bad02128 8064b5a8 89e8ce80 89e8ce70 89c16f90 nt!IopfCallDriver+0x31
> bad0214c 805773bc 89d128e8 89cc819c bad022f4 nt!IovCallDriver+0xa0
> bad0222c 805b365e 89d12900 00000000 89cc80f8 nt!IopParseDevice+0xa58
> bad022b4 805afb3f 00000000 bad022f4 00000040
> nt!ObpLookupObjectName+0x56a
> bad02308 8056a133 00000000 00000000 d0245400 nt!ObOpenObjectByName+0xeb
> bad02384 8056aaaa bad03408 00110001 bad033e8 nt!IopCreateFile+0x407
> bad023e0 8056d17c bad03408 00110001 bad033e8 nt!IoCreateFile+0x8e
> bad02420 8053c808 bad03408 00110001 bad033e8 nt!NtCreateFile+0x30
> bad02420 804fd569 bad03408 00110001 bad033e8 nt!KiFastCallEntry+0xf8
> bad024c4 a9d23c57 bad03408 00110001 bad033e8 nt!ZwCreateFile+0x11
> bad0340c a9d24ffc 899b2000 899cfad0 ba5fad0c
> Gtm51Irp!ReadRegistryParamsFromFileFunc+0x61
> [c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 2392]
> bad035f0 a9d1e967 899b2000 bad038ec 00000000
> Gtm51Irp!ParseRegistryParameters+0x1de
> [c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 119]
> bad03710 ba603dea bad0374c bad03754 ba5ff200
> Gtm51Irp!GPRSZCSInitialize+0x4c5
> [c:\work\driver\source\projects\cobra\gtndisirp\main.c @ 493]
> bad038c8 ba6039cc 89b92950 bad038ec bad03994
> NDIS!ndisMInitializeAdapter+0x3b7
> bad0399c ba6038ba 89b92950 00000000 89cc3be8
> NDIS!ndisInitializeAdapter+0xb9
> bad039d0 ba604d99 899cf9d0 89b5e040 8ac5cd00
> NDIS!ndisPnPStartDevice+0xd6
> bad03a00 804eddf9 899cf9d0 8ac5cdb8 806d02e8 NDIS!ndisPnPDispatch+0x306
>
>
> FOLLOWUP_IP:
> Gtm51Irp!ReadRegistryParamsFromFileFunc+61
> [c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 2392]
> a9d23c57 85c0 test eax,eax
>
> SYMBOL_STACK_INDEX: 2b
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>
> MODULE_NAME: Gtm51Irp
>
> IMAGE_NAME: Gtm51Irp.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 443b655c
>
> STACK_COMMAND: .tss 28 ; kb
>
> FAILURE_BUCKET_ID: 0x7f_8_Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>
> BUCKET_ID: 0x7f_8_Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>
> Followup: MachineOwner
> ---------
>
>
> Is this expected? If so, is there a way of waiting untill the system
> is sufficiently up to support this call?
>
> Thanks in advence for any input on this.
>
>

fat_boy
Wed Apr 12 02:32:22 CDT 2006

I think this is one of those typical stack overflows when booting and
accessing a file. I saw a number of old posts in this group regarding
this, they seemed to center around antivirus software eating up stack.

It seems that opening for a delete just uses that biy more stack
somewhere.

What I have also done is minimise the stack usage in the functions that
lead up to the ZwCreateFile call too.

Anyway, it works now.

Mark
Wed Apr 12 06:33:45 CDT 2006

On Tue, 11 Apr 2006 07:46:03 -0700, Pavel A. <pavel_a@NOwritemeNO.com>
wrote:

>What if you add OBJ_KERNEL_HANDLE and OBJ_OPENIF ?
>
>--PA
>
>"fat_boy" wrote:
>> Hi all
>>
>> If I boot the PC with the Ndis WDM device inserted, I get the following
>> BSOD when ZwCreateFile is called from MiniportInitialise. When the
>> device is inserted after the PC has booted there is no problem. Here is
>> the code.
>>
>> RtlInitUnicodeString(&ObjectName,
>> L"\\SystemRoot\\system32\\drivers\\GTNDIS.cfg");
>>

The configuration data ought to be in the registry. Drivers of almost
any sort have business opening files. There are of course exceptions,
but I highly suspect this isn't one of them.

To avoid the stack overflow you can farm the file open out to a worker
thread, which will have its own nice clean stack.


>> InitializeObjectAttributes(&ObjectAttributes,
>> &ObjectName,
>> OBJ_CASE_INSENSITIVE,
>> NULL,
>> NULL);
>>
>> Status = ZwCreateFile( &hfile,
>> FILE_READ_DATA | SYNCHRONIZE | DELETE,
>> &ObjectAttributes,
>> &IoStatusBlock,
>> NULL, FILE_ATTRIBUTE_NORMAL,
>> 0,
>> FILE_OPEN,
>> FILE_DELETE_ON_CLOSE | FILE_SYNCHRONOUS_IO_NONALERT,
>> NULL,
>> 0);
>>
>> Here is the trace:
>>
>> *******************************************************************************
>> *
>> *
>> * 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=89d162b0 ebx=89d162b0 ecx=00000001 edx=00000000 esi=89cb2100
>> edi=bad01700
>> eip=ba626b0f esp=bad01000 ebp=bad01004 iopl=0 nv up ei pl zr na
>> po nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>> efl=00010246
>> Ntfs!NtfsMcbLookupArrayIndex+0xc:
>> ba626b0f 56 push esi
>> Resetting default scope
>>
>> DEFAULT_BUCKET_ID: DRIVER_FAULT
>>
>> LAST_CONTROL_TRANSFER: from ba626a50 to ba626b0f
>>
>> STACK_TEXT:
>> bad01004 ba626a50 89d162b0 00000006 00000000
>> Ntfs!NtfsMcbLookupArrayIndex+0xc
>> bad01030 ba626bbb 89d162b0 00000006 00000000
>> Ntfs!NtfsLookupNtfsMcbEntry+0x23
>> bad0113c ba62707c bad01700 89d16218 00000006
>> Ntfs!NtfsLookupAllocation+0x5b
>> bad0130c ba626cf6 bad01700 8ac64e70 89d16218
>> Ntfs!NtfsPrepareBuffers+0x270
>> bad014f4 ba62803b bad01700 8ac64e70 89d16218 Ntfs!NtfsNonCachedIo+0x20e
>> bad016f0 ba627c97 bad01700 8ac64e70 0110070a
>> Ntfs!NtfsCommonWrite+0x1824
>> bad01864 804eddf9 89cb2020 8ac64e70 806d02e8 Ntfs!NtfsFsdWrite+0xf3
>> bad01874 8064b5a8 8ac64e70 89d1a040 89d15530 nt!IopfCallDriver+0x31
>> bad01898 ba6ca3ca 89d15478 89d15400 bad018dc nt!IovCallDriver+0xa0
>> bad018a8 804eddf9 89d15478 8ac64e70 806d02e8 sr!SrWrite+0xaa
>> bad018b8 8064b5a8 89cb0a28 00003000 89d15478 nt!IopfCallDriver+0x31
>> bad018dc 804ef0d5 e17af8f8 00001000 e1507658 nt!IovCallDriver+0xa0
>> bad018f0 ba647e86 89cb0a08 89da6428 bad01994
>> nt!IoSynchronousPageWrite+0xaf
>> bad019bc ba647f50 e1507658 e17af8f8 e1507658 Ntfs!LfsFlushLfcb+0x429
>> bad019e0 ba64da1f e1507658 e17af8f8 e157a230 Ntfs!LfsFlushLbcb+0x81
>> bad01a08 ba646a8e e1507658 0993b51c 00000000
>> Ntfs!LfsFlushToLsnPriv+0xf3
>> bad01a48 ba658341 e157a230 0993b51c 00000000 Ntfs!LfsFlushToLsn+0x8e
>> bad01a7c ba650110 899e7a98 e1650be0 e1650ca8
>> Ntfs!NtfsCommitCurrentTransaction+0x215
>> bad01a90 ba65169f 899e7a98 899e7a98 e1650ca8
>> Ntfs!NtfsCheckpointCurrentTransaction+0x21
>> bad01b64 ba650e2f 899e7a98 89b9e608 8abaee90
>> Ntfs!NtfsSetEndOfFileInfo+0x5ea
>> bad01bd4 ba629ad8 899e7a98 8abaee90 89cb2020
>> Ntfs!NtfsCommonSetInformation+0x477
>> bad01c3c 804eddf9 89cb2020 8abaee90 806d02e8
>> Ntfs!NtfsFsdSetInformation+0xa3
>> bad01c4c 8064b5a8 8abaefd8 8abaeea0 8abaee90 nt!IopfCallDriver+0x31
>> bad01c70 8056f689 bad01d38 bad01dc4 8056f11a nt!IovCallDriver+0xa0
>> bad01d1c 8053c808 8000034c bad01e50 bad01e20
>> nt!NtSetInformationFile+0x56f
>> bad01d1c 804fe405 8000034c bad01e50 bad01e20 nt!KiFastCallEntry+0xf8
>> bad01da8 ba6ce1e4 8000034c bad01e50 bad01e20
>> nt!ZwSetInformationFile+0x11
>> bad01e5c ba6ce502 80000310 89cb2020 e1760c08 sr!SrCopyStream+0x22e
>> bad01fd8 ba6ce87b 89d15530 89c16f90 e1750754 sr!SrBackupFile+0x2b0
>> bad02040 ba6d05a9 89d15530 00010010 89c16f90 sr!SrBackupFileAndLog+0x4b
>> bad02068 ba6d12c8 89d15530 00010010 89c16f90 sr!SrHandleFileChange+0x59
>> bad020b4 ba6cfa22 89d15530 00010010 89c16f90 sr!SrHandleEvent+0x194
>> bad02118 804eddf9 00000000 00000001 806d02e8 sr!SrCreate+0x2fc
>> bad02128 8064b5a8 89e8ce80 89e8ce70 89c16f90 nt!IopfCallDriver+0x31
>> bad0214c 805773bc 89d128e8 89cc819c bad022f4 nt!IovCallDriver+0xa0
>> bad0222c 805b365e 89d12900 00000000 89cc80f8 nt!IopParseDevice+0xa58
>> bad022b4 805afb3f 00000000 bad022f4 00000040
>> nt!ObpLookupObjectName+0x56a
>> bad02308 8056a133 00000000 00000000 d0245400 nt!ObOpenObjectByName+0xeb
>> bad02384 8056aaaa bad03408 00110001 bad033e8 nt!IopCreateFile+0x407
>> bad023e0 8056d17c bad03408 00110001 bad033e8 nt!IoCreateFile+0x8e
>> bad02420 8053c808 bad03408 00110001 bad033e8 nt!NtCreateFile+0x30
>> bad02420 804fd569 bad03408 00110001 bad033e8 nt!KiFastCallEntry+0xf8
>> bad024c4 a9d23c57 bad03408 00110001 bad033e8 nt!ZwCreateFile+0x11
>> bad0340c a9d24ffc 899b2000 899cfad0 ba5fad0c
>> Gtm51Irp!ReadRegistryParamsFromFileFunc+0x61
>> [c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 2392]
>> bad035f0 a9d1e967 899b2000 bad038ec 00000000
>> Gtm51Irp!ParseRegistryParameters+0x1de
>> [c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 119]
>> bad03710 ba603dea bad0374c bad03754 ba5ff200
>> Gtm51Irp!GPRSZCSInitialize+0x4c5
>> [c:\work\driver\source\projects\cobra\gtndisirp\main.c @ 493]
>> bad038c8 ba6039cc 89b92950 bad038ec bad03994
>> NDIS!ndisMInitializeAdapter+0x3b7
>> bad0399c ba6038ba 89b92950 00000000 89cc3be8
>> NDIS!ndisInitializeAdapter+0xb9
>> bad039d0 ba604d99 899cf9d0 89b5e040 8ac5cd00
>> NDIS!ndisPnPStartDevice+0xd6
>> bad03a00 804eddf9 899cf9d0 8ac5cdb8 806d02e8 NDIS!ndisPnPDispatch+0x306
>>
>>
>> FOLLOWUP_IP:
>> Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>> [c:\work\driver\source\projects\cobra\gtndisirp\readparams.c @ 2392]
>> a9d23c57 85c0 test eax,eax
>>
>> SYMBOL_STACK_INDEX: 2b
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> SYMBOL_NAME: Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>>
>> MODULE_NAME: Gtm51Irp
>>
>> IMAGE_NAME: Gtm51Irp.sys
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 443b655c
>>
>> STACK_COMMAND: .tss 28 ; kb
>>
>> FAILURE_BUCKET_ID: 0x7f_8_Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>>
>> BUCKET_ID: 0x7f_8_Gtm51Irp!ReadRegistryParamsFromFileFunc+61
>>
>> Followup: MachineOwner
>> ---------
>>
>>
>> Is this expected? If so, is there a way of waiting untill the system
>> is sufficiently up to support this call?
>>
>> Thanks in advence for any input on this.
>>
>>


=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Maxim
Wed Apr 12 17:04:36 CDT 2006

> If I boot the PC with the Ndis WDM device inserted, I get the following
> BSOD when ZwCreateFile is called from MiniportInitialise. When the

Kernel stack overflow

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

fat_boy
Thu Apr 13 07:21:04 CDT 2006

Yes, it is an ugly solution, but it is forced on me by tha fact that
the Ndis driver can only call NdisOpenConfiguration() during
MiniportINitialise. So, when the cpl applet sets new driver data, it
has no way of writing it to its configuration area, except at next
load, hence storing the new data temporarially in a file.

But, drivers also often download firmware to their devices, and this is
often in a file.

fat_boy
Thu Apr 13 07:21:53 CDT 2006

Yep, plain and simple.

Doing the open for delete later, and reducing stack usage fixed it.