HELP! - ZwWriteFile() from a hooked ZwOpenFile() always crashes

NTDEV
1

Hi

My driver is hooking ZwOpenFile(). In my hook function, except calling
the original ZwOpenFile(), I also call a logging function that uses
ZwWriteFile() to print log data to file.
For some reason, each time I call my log function from ZwOpenFile()
and ZwWriteFile() is called, I get a BSOD with
UNEXPECTED_KERNEL_MODE_TRAP (7f).

The log function uses mutexes for synchronization.
Using this log function from another hooked function (ZwCreateFile) works ok.
Attached WinDbg's dump analysis.

Thanks

*******************************************************************************
* *
* 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=0000018c ebx=8210e008 ecx=00000000 edx=e1dd2ad8 esi=ebd7c590 edi=82b24100
eip=f85a73ba esp=ebd7c000 ebp=ebd7c19c iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
Ntfs!_SEH_prolog+0x1a:
f85a73ba 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from f85a7cf6 to f85a73ba

STACK_TEXT:
ebd7c19c f85a7cf6 ebd7c590 8210e008 e1dd2ad8 Ntfs!_SEH_prolog+0x1a
ebd7c384 f85a8ae9 ebd7c590 8210e008 e1dd2ad8 Ntfs!NtfsNonCachedIo+0x20e
ebd7c580 f85a8c97 ebd7c590 8210e008 0110070a Ntfs!NtfsCommonWrite+0x1949
ebd7c6f4 804e37f7 82b24020 8210e008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
ebd7c704 f864b3ca 804e8a39 00000000 ebd7c7bc nt!IopfCallDriver+0x31
ebd7c714 804e37f7 82b89020 8210e008 ebd7c76c sr!SrWrite+0xaa
ebd7c724 ebd14074 00000000 ebd7c76c 828fb490 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be wrong.
ebd7c7bc 804ee6a6 82af7b0a ebd7c7e4 ebd7c878
SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
ebd7c898 804ee45d e249a00c e249a010 e249a010 nt!MiFlushSectionInternal+0x38b
ebd7c8d4 805079bb 00000000 e249a00c 00000001 nt!MmFlushSection+0x1e0
ebd7c8ec 804f60ee 8201d008 00000000 00000000 nt!CcMapAndCopy+0x45d
ebd7c968 804f5e75 8201d008 ba009107 ebd7c9ac nt!CcMapAndCopy+0x2fa
ebd7c9f4 f85abb66 82af7b38 ebd7cbc4 00000003 nt!CcCopyWrite+0x28e
ebd7cbe8 f85a8c97 81abd008 82ad8008 82ad8008 Ntfs!NtfsCommonWrite+0x1d2a
ebd7cc4c 804e37f7 82b24020 82ad8008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
ebd7cc5c f864b3ca 804e8a39 00000000 ebd7cd14 nt!IopfCallDriver+0x31
ebd7cc6c 804e37f7 82b89020 e2405c88 ebd7ccc4 sr!SrWrite+0xaa
ebd7cc7c ebd14074 00000000 ebd7ccc4 828fb490 nt!IopfCallDriver+0x31
ebd7cd14 805784c0 827f5ac0 82ad8008 82af7b38
SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
ebd7cdc8 804de7ec 80000160 00000000 00000000 nt!NtWriteFile+0x602
ebd7cdc8 804ddc35 80000160 00000000 00000000 nt!KiFastCallEntry+0xf8
ebd7ce64 b9fff72f 80000160 00000000 00000000 nt!ZwWriteFile+0x11
ebd7cedc b9ffe58b ba007f00 ebd7d71c 00000000 dg!LogToFile+0x7f [@ 5311]
ebd7d6fc 804de7ec ebd7d7d8 00100080 ebd7d7b8 dg!NewZwOpenFile+0xab [@ 4256]
ebd7d6fc 804dcfdd ebd7d7d8 00100080 ebd7d7b8 nt!KiFastCallEntry+0xf8
ebd7d78c ebadb2ca ebd7d7d8 00100080 ebd7d7b8 nt!ZwOpenFile+0x11
ebd7d7dc ebadb963 ebd7d800 ebd7d808 ebd7d814 SPBBCDrv+0x32ca
ebd7d81c ebaea53a e15a2ac0 e1fd9450 00000002 SPBBCDrv+0x3963
ebd7d858 ebaf4645 ebd7d930 00000005 00000006 SPBBCDrv+0x1253a
ebd7d888 ebaf4376 ebd7d980 e1cec418 00000000 SPBBCDrv+0x1c645
ebd7d8c0 ebae5e5d 00000000 ebd7d980 e11f24f0 SPBBCDrv+0x1c376
ebd7d974 ebae3dcb e1c92410 ebd7d8ec ebd7d960 SPBBCDrv+0xde5d
ebd7d994 ebae62d1 ebd7d9f4 829a89e0 e1c92410 SPBBCDrv+0xbdcb
ebd7d9bc ebae8a86 00d7d9f4 829944c0 e1333c98 SPBBCDrv+0xe2d1
ebd7d9cc ebaebb6d ebd7d9f4 e17d7640 829944c0 SPBBCDrv+0x10a86
ebd7d9e4 ebaeb0d7 ebd7d9f4 e1019a30 ebb28220 SPBBCDrv+0x13b6d
ebd7da24 ebd19788 829944c0 e17d7648 ebd1bad6 SPBBCDrv+0x130d7
ebd7da30 ebd1bad6 e17d7648 e1a63ed8 e17d7640 SYMEVENT!EventObjectDestroy+0x138
ebd7da4c ebd1bc7d e17d7640 ebd7daa0 e1a63efc SYMEVENT!EventObjectCreate+0x1b36
ebd7da5c ebd12f19 ebd7daa0 e1a63efc ebd7daa0 SYMEVENT!EventObjectCreate+0x1cdd
ebd7da6c ebd1a8e8 ebd7daa0 81e73018 ebd7daa0
SYMEVENT!SYMEvent_GetVMDataPtr+0x7579
ebd7dabc 804e37f7 827f5ac0 81e73008 81e73008 SYMEVENT!EventObjectCreate+0x948
ebd7dacc 8057069a 82b0ee18 8240ec14 ebd7dc74 nt!IopfCallDriver+0x31
ebd7dbac 8056316c 82b0ee30 00000000 8240eb70 nt!IopParseDevice+0xa58
ebd7dc34 8056729a 00000000 ebd7dc74 00000240 nt!ObpLookupObjectName+0x56a
ebd7dc88 80570b73 00000000 00000000 01001b00 nt!ObOpenObjectByName+0xeb
ebd7dd04 80570c42 ebd7e7dc 00000020 ebd7e77c nt!IopCreateFile+0x407
ebd7dd60 80570d0a ebd7e7dc 00000020 ebd7e77c nt!IoCreateFile+0x8e
ebd7dda0 b9ffe575 ebd7e7dc 00000020 ebd7e77c nt!NtOpenFile+0x27
ebd7e5d4 804de7ec ebd7e7dc 00000020 ebd7e77c dg!NewZwOpenFile+0x95 [@ 4235]

FOLLOWUP_IP:
SYMEVENT!SYMEvent_GetVMDataPtr+86d4
ebd14074 894618 mov [esi+0x18],eax

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: SYMEVENT!SYMEvent_GetVMDataPtr+86d4

MODULE_NAME: SYMEVENT

IMAGE_NAME: SYMEVENT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 423f8ec8

STACK_COMMAND: .tss 28 ; kb

FAILURE_BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4

BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4

Followup: MachineOwner

2

Stack overflow?

“Omer B” wrote in message news:xxxxx@ntdev…
Hi

My driver is hooking ZwOpenFile(). In my hook function, except calling
the original ZwOpenFile(), I also call a logging function that uses
ZwWriteFile() to print log data to file.
For some reason, each time I call my log function from ZwOpenFile()
and ZwWriteFile() is called, I get a BSOD with
UNEXPECTED_KERNEL_MODE_TRAP (7f).

The log function uses mutexes for synchronization.
Using this log function from another hooked function (ZwCreateFile) works
ok.
Attached WinDbg’s dump analysis.

Thanks
================================================================

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=0000018c ebx=8210e008 ecx=00000000 edx=e1dd2ad8 esi=ebd7c590
edi=82b24100
eip=f85a73ba esp=ebd7c000 ebp=ebd7c19c iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
Ntfs!_SEH_prolog+0x1a:
f85a73ba 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from f85a7cf6 to f85a73ba

STACK_TEXT:
ebd7c19c f85a7cf6 ebd7c590 8210e008 e1dd2ad8 Ntfs!_SEH_prolog+0x1a
ebd7c384 f85a8ae9 ebd7c590 8210e008 e1dd2ad8 Ntfs!NtfsNonCachedIo+0x20e
ebd7c580 f85a8c97 ebd7c590 8210e008 0110070a Ntfs!NtfsCommonWrite+0x1949
ebd7c6f4 804e37f7 82b24020 8210e008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
ebd7c704 f864b3ca 804e8a39 00000000 ebd7c7bc nt!IopfCallDriver+0x31
ebd7c714 804e37f7 82b89020 8210e008 ebd7c76c sr!SrWrite+0xaa
ebd7c724 ebd14074 00000000 ebd7c76c 828fb490 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
ebd7c7bc 804ee6a6 82af7b0a ebd7c7e4 ebd7c878
SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
ebd7c898 804ee45d e249a00c e249a010 e249a010 nt!MiFlushSectionInternal+0x38b
ebd7c8d4 805079bb 00000000 e249a00c 00000001 nt!MmFlushSection+0x1e0
ebd7c8ec 804f60ee 8201d008 00000000 00000000 nt!CcMapAndCopy+0x45d
ebd7c968 804f5e75 8201d008 ba009107 ebd7c9ac nt!CcMapAndCopy+0x2fa
ebd7c9f4 f85abb66 82af7b38 ebd7cbc4 00000003 nt!CcCopyWrite+0x28e
ebd7cbe8 f85a8c97 81abd008 82ad8008 82ad8008 Ntfs!NtfsCommonWrite+0x1d2a
ebd7cc4c 804e37f7 82b24020 82ad8008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
ebd7cc5c f864b3ca 804e8a39 00000000 ebd7cd14 nt!IopfCallDriver+0x31
ebd7cc6c 804e37f7 82b89020 e2405c88 ebd7ccc4 sr!SrWrite+0xaa
ebd7cc7c ebd14074 00000000 ebd7ccc4 828fb490 nt!IopfCallDriver+0x31
ebd7cd14 805784c0 827f5ac0 82ad8008 82af7b38
SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
ebd7cdc8 804de7ec 80000160 00000000 00000000 nt!NtWriteFile+0x602
ebd7cdc8 804ddc35 80000160 00000000 00000000 nt!KiFastCallEntry+0xf8
ebd7ce64 b9fff72f 80000160 00000000 00000000 nt!ZwWriteFile+0x11
ebd7cedc b9ffe58b ba007f00 ebd7d71c 00000000 dg!LogToFile+0x7f [@ 5311]
ebd7d6fc 804de7ec ebd7d7d8 00100080 ebd7d7b8 dg!NewZwOpenFile+0xab [@ 4256]
ebd7d6fc 804dcfdd ebd7d7d8 00100080 ebd7d7b8 nt!KiFastCallEntry+0xf8
ebd7d78c ebadb2ca ebd7d7d8 00100080 ebd7d7b8 nt!ZwOpenFile+0x11
ebd7d7dc ebadb963 ebd7d800 ebd7d808 ebd7d814 SPBBCDrv+0x32ca
ebd7d81c ebaea53a e15a2ac0 e1fd9450 00000002 SPBBCDrv+0x3963
ebd7d858 ebaf4645 ebd7d930 00000005 00000006 SPBBCDrv+0x1253a
ebd7d888 ebaf4376 ebd7d980 e1cec418 00000000 SPBBCDrv+0x1c645
ebd7d8c0 ebae5e5d 00000000 ebd7d980 e11f24f0 SPBBCDrv+0x1c376
ebd7d974 ebae3dcb e1c92410 ebd7d8ec ebd7d960 SPBBCDrv+0xde5d
ebd7d994 ebae62d1 ebd7d9f4 829a89e0 e1c92410 SPBBCDrv+0xbdcb
ebd7d9bc ebae8a86 00d7d9f4 829944c0 e1333c98 SPBBCDrv+0xe2d1
ebd7d9cc ebaebb6d ebd7d9f4 e17d7640 829944c0 SPBBCDrv+0x10a86
ebd7d9e4 ebaeb0d7 ebd7d9f4 e1019a30 ebb28220 SPBBCDrv+0x13b6d
ebd7da24 ebd19788 829944c0 e17d7648 ebd1bad6 SPBBCDrv+0x130d7
ebd7da30 ebd1bad6 e17d7648 e1a63ed8 e17d7640
SYMEVENT!EventObjectDestroy+0x138
ebd7da4c ebd1bc7d e17d7640 ebd7daa0 e1a63efc
SYMEVENT!EventObjectCreate+0x1b36
ebd7da5c ebd12f19 ebd7daa0 e1a63efc ebd7daa0
SYMEVENT!EventObjectCreate+0x1cdd
ebd7da6c ebd1a8e8 ebd7daa0 81e73018 ebd7daa0
SYMEVENT!SYMEvent_GetVMDataPtr+0x7579
ebd7dabc 804e37f7 827f5ac0 81e73008 81e73008
SYMEVENT!EventObjectCreate+0x948
ebd7dacc 8057069a 82b0ee18 8240ec14 ebd7dc74 nt!IopfCallDriver+0x31
ebd7dbac 8056316c 82b0ee30 00000000 8240eb70 nt!IopParseDevice+0xa58
ebd7dc34 8056729a 00000000 ebd7dc74 00000240 nt!ObpLookupObjectName+0x56a
ebd7dc88 80570b73 00000000 00000000 01001b00 nt!ObOpenObjectByName+0xeb
ebd7dd04 80570c42 ebd7e7dc 00000020 ebd7e77c nt!IopCreateFile+0x407
ebd7dd60 80570d0a ebd7e7dc 00000020 ebd7e77c nt!IoCreateFile+0x8e
ebd7dda0 b9ffe575 ebd7e7dc 00000020 ebd7e77c nt!NtOpenFile+0x27
ebd7e5d4 804de7ec ebd7e7dc 00000020 ebd7e77c dg!NewZwOpenFile+0x95 [@ 4235]

FOLLOWUP_IP:
SYMEVENT!SYMEvent_GetVMDataPtr+86d4
ebd14074 894618 mov [esi+0x18],eax

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: SYMEVENT!SYMEvent_GetVMDataPtr+86d4

MODULE_NAME: SYMEVENT

IMAGE_NAME: SYMEVENT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 423f8ec8

STACK_COMMAND: .tss 28 ; kb

FAILURE_BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4

BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4

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

3

Don’t sure… And i don’t see any reason for it to happen.
I think the BSOD is in the first call to ZwWriteFile.

On 8/4/05, Lyndon J Clarke wrote:
> Stack overflow?
>
> “Omer B” wrote in message news:xxxxx@ntdev…
> Hi
>
> My driver is hooking ZwOpenFile(). In my hook function, except calling
> the original ZwOpenFile(), I also call a logging function that uses
> ZwWriteFile() to print log data to file.
> For some reason, each time I call my log function from ZwOpenFile()
> and ZwWriteFile() is called, I get a BSOD with
> UNEXPECTED_KERNEL_MODE_TRAP (7f).
>
> The log function uses mutexes for synchronization.
> Using this log function from another hooked function (ZwCreateFile) works
> ok.
> Attached WinDbg’s dump analysis.
>
> Thanks
> ================================================================
>
> *****
>
>
> * 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=0000018c ebx=8210e008 ecx=00000000 edx=e1dd2ad8 esi=ebd7c590
> edi=82b24100
> eip=f85a73ba esp=ebd7c000 ebp=ebd7c19c iopl=0 nv up ei ng nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> Ntfs!_SEH_prolog+0x1a:
> f85a73ba 53 push ebx
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from f85a7cf6 to f85a73ba
>
> STACK_TEXT:
> ebd7c19c f85a7cf6 ebd7c590 8210e008 e1dd2ad8 Ntfs!_SEH_prolog+0x1a
> ebd7c384 f85a8ae9 ebd7c590 8210e008 e1dd2ad8 Ntfs!NtfsNonCachedIo+0x20e
> ebd7c580 f85a8c97 ebd7c590 8210e008 0110070a Ntfs!NtfsCommonWrite+0x1949
> ebd7c6f4 804e37f7 82b24020 8210e008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
> ebd7c704 f864b3ca 804e8a39 00000000 ebd7c7bc nt!IopfCallDriver+0x31
> ebd7c714 804e37f7 82b89020 8210e008 ebd7c76c sr!SrWrite+0xaa
> ebd7c724 ebd14074 00000000 ebd7c76c 828fb490 nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> ebd7c7bc 804ee6a6 82af7b0a ebd7c7e4 ebd7c878
> SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
> ebd7c898 804ee45d e249a00c e249a010 e249a010 nt!MiFlushSectionInternal+0x38b
> ebd7c8d4 805079bb 00000000 e249a00c 00000001 nt!MmFlushSection+0x1e0
> ebd7c8ec 804f60ee 8201d008 00000000 00000000 nt!CcMapAndCopy+0x45d
> ebd7c968 804f5e75 8201d008 ba009107 ebd7c9ac nt!CcMapAndCopy+0x2fa
> ebd7c9f4 f85abb66 82af7b38 ebd7cbc4 00000003 nt!CcCopyWrite+0x28e
> ebd7cbe8 f85a8c97 81abd008 82ad8008 82ad8008 Ntfs!NtfsCommonWrite+0x1d2a
> ebd7cc4c 804e37f7 82b24020 82ad8008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
> ebd7cc5c f864b3ca 804e8a39 00000000 ebd7cd14 nt!IopfCallDriver+0x31
> ebd7cc6c 804e37f7 82b89020 e2405c88 ebd7ccc4 sr!SrWrite+0xaa
> ebd7cc7c ebd14074 00000000 ebd7ccc4 828fb490 nt!IopfCallDriver+0x31
> ebd7cd14 805784c0 827f5ac0 82ad8008 82af7b38
> SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
> ebd7cdc8 804de7ec 80000160 00000000 00000000 nt!NtWriteFile+0x602
> ebd7cdc8 804ddc35 80000160 00000000 00000000 nt!KiFastCallEntry+0xf8
> ebd7ce64 b9fff72f 80000160 00000000 00000000 nt!ZwWriteFile+0x11
> ebd7cedc b9ffe58b ba007f00 ebd7d71c 00000000 dg!LogToFile+0x7f [@ 5311]
> ebd7d6fc 804de7ec ebd7d7d8 00100080 ebd7d7b8 dg!NewZwOpenFile+0xab [@ 4256]
> ebd7d6fc 804dcfdd ebd7d7d8 00100080 ebd7d7b8 nt!KiFastCallEntry+0xf8
> ebd7d78c ebadb2ca ebd7d7d8 00100080 ebd7d7b8 nt!ZwOpenFile+0x11
> ebd7d7dc ebadb963 ebd7d800 ebd7d808 ebd7d814 SPBBCDrv+0x32ca
> ebd7d81c ebaea53a e15a2ac0 e1fd9450 00000002 SPBBCDrv+0x3963
> ebd7d858 ebaf4645 ebd7d930 00000005 00000006 SPBBCDrv+0x1253a
> ebd7d888 ebaf4376 ebd7d980 e1cec418 00000000 SPBBCDrv+0x1c645
> ebd7d8c0 ebae5e5d 00000000 ebd7d980 e11f24f0 SPBBCDrv+0x1c376
> ebd7d974 ebae3dcb e1c92410 ebd7d8ec ebd7d960 SPBBCDrv+0xde5d
> ebd7d994 ebae62d1 ebd7d9f4 829a89e0 e1c92410 SPBBCDrv+0xbdcb
> ebd7d9bc ebae8a86 00d7d9f4 829944c0 e1333c98 SPBBCDrv+0xe2d1
> ebd7d9cc ebaebb6d ebd7d9f4 e17d7640 829944c0 SPBBCDrv+0x10a86
> ebd7d9e4 ebaeb0d7 ebd7d9f4 e1019a30 ebb28220 SPBBCDrv+0x13b6d
> ebd7da24 ebd19788 829944c0 e17d7648 ebd1bad6 SPBBCDrv+0x130d7
> ebd7da30 ebd1bad6 e17d7648 e1a63ed8 e17d7640
> SYMEVENT!EventObjectDestroy+0x138
> ebd7da4c ebd1bc7d e17d7640 ebd7daa0 e1a63efc
> SYMEVENT!EventObjectCreate+0x1b36
> ebd7da5c ebd12f19 ebd7daa0 e1a63efc ebd7daa0
> SYMEVENT!EventObjectCreate+0x1cdd
> ebd7da6c ebd1a8e8 ebd7daa0 81e73018 ebd7daa0
> SYMEVENT!SYMEvent_GetVMDataPtr+0x7579
> ebd7dabc 804e37f7 827f5ac0 81e73008 81e73008
> SYMEVENT!EventObjectCreate+0x948
> ebd7dacc 8057069a 82b0ee18 8240ec14 ebd7dc74 nt!IopfCallDriver+0x31
> ebd7dbac 8056316c 82b0ee30 00000000 8240eb70 nt!IopParseDevice+0xa58
> ebd7dc34 8056729a 00000000 ebd7dc74 00000240 nt!ObpLookupObjectName+0x56a
> ebd7dc88 80570b73 00000000 00000000 01001b00 nt!ObOpenObjectByName+0xeb
> ebd7dd04 80570c42 ebd7e7dc 00000020 ebd7e77c nt!IopCreateFile+0x407
> ebd7dd60 80570d0a ebd7e7dc 00000020 ebd7e77c nt!IoCreateFile+0x8e
> ebd7dda0 b9ffe575 ebd7e7dc 00000020 ebd7e77c nt!NtOpenFile+0x27
> ebd7e5d4 804de7ec ebd7e7dc 00000020 ebd7e77c dg!NewZwOpenFile+0x95 [@ 4235]
>
>
> FOLLOWUP_IP:
> SYMEVENT!SYMEvent_GetVMDataPtr+86d4
> ebd14074 894618 mov [esi+0x18],eax
>
> SYMBOL_STACK_INDEX: 7
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> MODULE_NAME: SYMEVENT
>
> IMAGE_NAME: SYMEVENT.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 423f8ec8
>
> STACK_COMMAND: .tss 28 ; kb
>
> FAILURE_BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

Of course you’re sure. Can you think of any other reason why “push ebx”
would cause a page fault? The ONLY memory reference is to the stack,
and thus that MUST be the cause of the fault; the double fault occurs
when the CPU tries to push the fault information onto the (now invalid)
stack. That triggers the double fault (parameter # 1 of the
UNEXPECTED_KMODE_TRAP bug check code).

When I see 0x7f (0x8, …) I always assume “stack overflow”. You say “I
just do a write to a file”. But you set the file up for write-through,
which of course means that it goes into the cache and THEN gets flushed
back out to the file system. AND you have several extraneous products
installed, each of which uses yet more stack space. Before you even GET
to issue the write operation there’s 3K worth of stack consumed - 25% of
the entire stack. Now, there’s only 676 bytes used in what I assume is
your driver, but IRP_MJ_CREATE is a well-known stack consumptive process
and throwing the write-through into the mix is proving to be too much.

But I continued counting… from the point where the driver issues the
ZwWriteFile (why reenter? Is there something wrong with building and
sending an IRP?) to the point where the IRP_MJ_WRITE gets to NTFS
there’s another 2.5k of stack consumed. By the time the second
IRP_MJ_WRITE gets to NTFS the remaining stack is down to 1780 bytes.

The implementation here doesn’t look like it is appropriate to the
kernel environment. This kind of thing would no doubt work in user mode
without problems, but in kernel mode stack is a truly scarce resource.
Possible solutions:

  • Log to a separate thread.
  • Do non-cached I/O.
  • Use IRPs instead of Zw calls (which create greater re-entrancy)
  • Make sure your own code does not consume “too much” stack space.

Bottom line: you’ve exhausted stack. You need to go back and find a
different way of achieving the same thing without overflowing the stack.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
Sent: Thursday, August 04, 2005 6:58 AM
To: ntdev redirect
Subject: Re: [ntdev] HELP! - ZwWriteFile() from a hooked ZwOpenFile()
always crashes

Don’t sure… And i don’t see any reason for it to happen.
I think the BSOD is in the first call to ZwWriteFile.

On 8/4/05, Lyndon J Clarke wrote:
> Stack overflow?
>
> “Omer B” wrote in message news:xxxxx@ntdev…
> Hi
>
> My driver is hooking ZwOpenFile(). In my hook function, except calling
> the original ZwOpenFile(), I also call a logging function that uses
> ZwWriteFile() to print log data to file.
> For some reason, each time I call my log function from ZwOpenFile()
> and ZwWriteFile() is called, I get a BSOD with
> UNEXPECTED_KERNEL_MODE_TRAP (7f).
>
> The log function uses mutexes for synchronization.
> Using this log function from another hooked function (ZwCreateFile)
works
> ok.
> Attached WinDbg’s dump analysis.
>
> Thanks
> ================================================================
>
>
*****************************************************************
> *
> *
> * 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=0000018c ebx=8210e008 ecx=00000000 edx=e1dd2ad8 esi=ebd7c590
> edi=82b24100
> eip=f85a73ba esp=ebd7c000 ebp=ebd7c19c iopl=0 nv up ei ng nz
na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> Ntfs!_SEH_prolog+0x1a:
> f85a73ba 53 push ebx
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from f85a7cf6 to f85a73ba
>
> STACK_TEXT:
> ebd7c19c f85a7cf6 ebd7c590 8210e008 e1dd2ad8 Ntfs!_SEH_prolog+0x1a
> ebd7c384 f85a8ae9 ebd7c590 8210e008 e1dd2ad8
Ntfs!NtfsNonCachedIo+0x20e
> ebd7c580 f85a8c97 ebd7c590 8210e008 0110070a
Ntfs!NtfsCommonWrite+0x1949
> ebd7c6f4 804e37f7 82b24020 8210e008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
> ebd7c704 f864b3ca 804e8a39 00000000 ebd7c7bc nt!IopfCallDriver+0x31
> ebd7c714 804e37f7 82b89020 8210e008 ebd7c76c sr!SrWrite+0xaa
> ebd7c724 ebd14074 00000000 ebd7c76c 828fb490 nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available. Following frames may
be
> wrong.
> ebd7c7bc 804ee6a6 82af7b0a ebd7c7e4 ebd7c878
> SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
> ebd7c898 804ee45d e249a00c e249a010 e249a010
nt!MiFlushSectionInternal+0x38b
> ebd7c8d4 805079bb 00000000 e249a00c 00000001 nt!MmFlushSection+0x1e0
> ebd7c8ec 804f60ee 8201d008 00000000 00000000 nt!CcMapAndCopy+0x45d
> ebd7c968 804f5e75 8201d008 ba009107 ebd7c9ac nt!CcMapAndCopy+0x2fa
> ebd7c9f4 f85abb66 82af7b38 ebd7cbc4 00000003 nt!CcCopyWrite+0x28e
> ebd7cbe8 f85a8c97 81abd008 82ad8008 82ad8008
Ntfs!NtfsCommonWrite+0x1d2a
> ebd7cc4c 804e37f7 82b24020 82ad8008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
> ebd7cc5c f864b3ca 804e8a39 00000000 ebd7cd14 nt!IopfCallDriver+0x31
> ebd7cc6c 804e37f7 82b89020 e2405c88 ebd7ccc4 sr!SrWrite+0xaa
> ebd7cc7c ebd14074 00000000 ebd7ccc4 828fb490 nt!IopfCallDriver+0x31
> ebd7cd14 805784c0 827f5ac0 82ad8008 82af7b38
> SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
> ebd7cdc8 804de7ec 80000160 00000000 00000000 nt!NtWriteFile+0x602
> ebd7cdc8 804ddc35 80000160 00000000 00000000 nt!KiFastCallEntry+0xf8
> ebd7ce64 b9fff72f 80000160 00000000 00000000 nt!ZwWriteFile+0x11
> ebd7cedc b9ffe58b ba007f00 ebd7d71c 00000000 dg!LogToFile+0x7f [@
5311]
> ebd7d6fc 804de7ec ebd7d7d8 00100080 ebd7d7b8 dg!NewZwOpenFile+0xab [@
4256]
> ebd7d6fc 804dcfdd ebd7d7d8 00100080 ebd7d7b8 nt!KiFastCallEntry+0xf8
> ebd7d78c ebadb2ca ebd7d7d8 00100080 ebd7d7b8 nt!ZwOpenFile+0x11
> ebd7d7dc ebadb963 ebd7d800 ebd7d808 ebd7d814 SPBBCDrv+0x32ca
> ebd7d81c ebaea53a e15a2ac0 e1fd9450 00000002 SPBBCDrv+0x3963
> ebd7d858 ebaf4645 ebd7d930 00000005 00000006 SPBBCDrv+0x1253a
> ebd7d888 ebaf4376 ebd7d980 e1cec418 00000000 SPBBCDrv+0x1c645
> ebd7d8c0 ebae5e5d 00000000 ebd7d980 e11f24f0 SPBBCDrv+0x1c376
> ebd7d974 ebae3dcb e1c92410 ebd7d8ec ebd7d960 SPBBCDrv+0xde5d
> ebd7d994 ebae62d1 ebd7d9f4 829a89e0 e1c92410 SPBBCDrv+0xbdcb
> ebd7d9bc ebae8a86 00d7d9f4 829944c0 e1333c98 SPBBCDrv+0xe2d1
> ebd7d9cc ebaebb6d ebd7d9f4 e17d7640 829944c0 SPBBCDrv+0x10a86
> ebd7d9e4 ebaeb0d7 ebd7d9f4 e1019a30 ebb28220 SPBBCDrv+0x13b6d
> ebd7da24 ebd19788 829944c0 e17d7648 ebd1bad6 SPBBCDrv+0x130d7
> ebd7da30 ebd1bad6 e17d7648 e1a63ed8 e17d7640
> SYMEVENT!EventObjectDestroy+0x138
> ebd7da4c ebd1bc7d e17d7640 ebd7daa0 e1a63efc
> SYMEVENT!EventObjectCreate+0x1b36
> ebd7da5c ebd12f19 ebd7daa0 e1a63efc ebd7daa0
> SYMEVENT!EventObjectCreate+0x1cdd
> ebd7da6c ebd1a8e8 ebd7daa0 81e73018 ebd7daa0
> SYMEVENT!SYMEvent_GetVMDataPtr+0x7579
> ebd7dabc 804e37f7 827f5ac0 81e73008 81e73008
> SYMEVENT!EventObjectCreate+0x948
> ebd7dacc 8057069a 82b0ee18 8240ec14 ebd7dc74 nt!IopfCallDriver+0x31
> ebd7dbac 8056316c 82b0ee30 00000000 8240eb70 nt!IopParseDevice+0xa58
> ebd7dc34 8056729a 00000000 ebd7dc74 00000240
nt!ObpLookupObjectName+0x56a
> ebd7dc88 80570b73 00000000 00000000 01001b00
nt!ObOpenObjectByName+0xeb
> ebd7dd04 80570c42 ebd7e7dc 00000020 ebd7e77c nt!IopCreateFile+0x407
> ebd7dd60 80570d0a ebd7e7dc 00000020 ebd7e77c nt!IoCreateFile+0x8e
> ebd7dda0 b9ffe575 ebd7e7dc 00000020 ebd7e77c nt!NtOpenFile+0x27
> ebd7e5d4 804de7ec ebd7e7dc 00000020 ebd7e77c dg!NewZwOpenFile+0x95 [@
4235]
>
>
> FOLLOWUP_IP:
> SYMEVENT!SYMEvent_GetVMDataPtr+86d4
> ebd14074 894618 mov [esi+0x18],eax
>
> SYMBOL_STACK_INDEX: 7
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> MODULE_NAME: SYMEVENT
>
> IMAGE_NAME: SYMEVENT.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 423f8ec8
>
> STACK_COMMAND: .tss 28 ; kb
>
> FAILURE_BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Omer

I put a question mark, yet, my response was not intended to be a question.
Well anyway, never mind about your stack overflow, the real problem, is that
you are hooking, and this is the real problem you need to correct. I am
afraid the advice is back to the drawing board for you, but to help you on
your way, you might find that you can acheive your ambitions with a file
system filter driver.

Good luck
Lyndon

“Omer B” wrote in message news:xxxxx@ntdev…
Don’t sure… And i don’t see any reason for it to happen.
I think the BSOD is in the first call to ZwWriteFile.

On 8/4/05, Lyndon J Clarke wrote:
> Stack overflow?
>
> “Omer B” wrote in message news:xxxxx@ntdev…
> Hi
>
> My driver is hooking ZwOpenFile(). In my hook function, except calling
> the original ZwOpenFile(), I also call a logging function that uses
> ZwWriteFile() to print log data to file.
> For some reason, each time I call my log function from ZwOpenFile()
> and ZwWriteFile() is called, I get a BSOD with
> UNEXPECTED_KERNEL_MODE_TRAP (7f).
>
> The log function uses mutexes for synchronization.
> Using this log function from another hooked function (ZwCreateFile) works
> ok.
> Attached WinDbg’s dump analysis.
>
> Thanks
> ================================================================
>
> *****
>
>
> * 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=0000018c ebx=8210e008 ecx=00000000 edx=e1dd2ad8 esi=ebd7c590
> edi=82b24100
> eip=f85a73ba esp=ebd7c000 ebp=ebd7c19c iopl=0 nv up ei ng nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> Ntfs!_SEH_prolog+0x1a:
> f85a73ba 53 push ebx
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from f85a7cf6 to f85a73ba
>
> STACK_TEXT:
> ebd7c19c f85a7cf6 ebd7c590 8210e008 e1dd2ad8 Ntfs!_SEH_prolog+0x1a
> ebd7c384 f85a8ae9 ebd7c590 8210e008 e1dd2ad8 Ntfs!NtfsNonCachedIo+0x20e
> ebd7c580 f85a8c97 ebd7c590 8210e008 0110070a Ntfs!NtfsCommonWrite+0x1949
> ebd7c6f4 804e37f7 82b24020 8210e008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
> ebd7c704 f864b3ca 804e8a39 00000000 ebd7c7bc nt!IopfCallDriver+0x31
> ebd7c714 804e37f7 82b89020 8210e008 ebd7c76c sr!SrWrite+0xaa
> ebd7c724 ebd14074 00000000 ebd7c76c 828fb490 nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> ebd7c7bc 804ee6a6 82af7b0a ebd7c7e4 ebd7c878
> SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
> ebd7c898 804ee45d e249a00c e249a010 e249a010
> nt!MiFlushSectionInternal+0x38b
> ebd7c8d4 805079bb 00000000 e249a00c 00000001 nt!MmFlushSection+0x1e0
> ebd7c8ec 804f60ee 8201d008 00000000 00000000 nt!CcMapAndCopy+0x45d
> ebd7c968 804f5e75 8201d008 ba009107 ebd7c9ac nt!CcMapAndCopy+0x2fa
> ebd7c9f4 f85abb66 82af7b38 ebd7cbc4 00000003 nt!CcCopyWrite+0x28e
> ebd7cbe8 f85a8c97 81abd008 82ad8008 82ad8008 Ntfs!NtfsCommonWrite+0x1d2a
> ebd7cc4c 804e37f7 82b24020 82ad8008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
> ebd7cc5c f864b3ca 804e8a39 00000000 ebd7cd14 nt!IopfCallDriver+0x31
> ebd7cc6c 804e37f7 82b89020 e2405c88 ebd7ccc4 sr!SrWrite+0xaa
> ebd7cc7c ebd14074 00000000 ebd7ccc4 828fb490 nt!IopfCallDriver+0x31
> ebd7cd14 805784c0 827f5ac0 82ad8008 82af7b38
> SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
> ebd7cdc8 804de7ec 80000160 00000000 00000000 nt!NtWriteFile+0x602
> ebd7cdc8 804ddc35 80000160 00000000 00000000 nt!KiFastCallEntry+0xf8
> ebd7ce64 b9fff72f 80000160 00000000 00000000 nt!ZwWriteFile+0x11
> ebd7cedc b9ffe58b ba007f00 ebd7d71c 00000000 dg!LogToFile+0x7f [@ 5311]
> ebd7d6fc 804de7ec ebd7d7d8 00100080 ebd7d7b8 dg!NewZwOpenFile+0xab [@
> 4256]
> ebd7d6fc 804dcfdd ebd7d7d8 00100080 ebd7d7b8 nt!KiFastCallEntry+0xf8
> ebd7d78c ebadb2ca ebd7d7d8 00100080 ebd7d7b8 nt!ZwOpenFile+0x11
> ebd7d7dc ebadb963 ebd7d800 ebd7d808 ebd7d814 SPBBCDrv+0x32ca
> ebd7d81c ebaea53a e15a2ac0 e1fd9450 00000002 SPBBCDrv+0x3963
> ebd7d858 ebaf4645 ebd7d930 00000005 00000006 SPBBCDrv+0x1253a
> ebd7d888 ebaf4376 ebd7d980 e1cec418 00000000 SPBBCDrv+0x1c645
> ebd7d8c0 ebae5e5d 00000000 ebd7d980 e11f24f0 SPBBCDrv+0x1c376
> ebd7d974 ebae3dcb e1c92410 ebd7d8ec ebd7d960 SPBBCDrv+0xde5d
> ebd7d994 ebae62d1 ebd7d9f4 829a89e0 e1c92410 SPBBCDrv+0xbdcb
> ebd7d9bc ebae8a86 00d7d9f4 829944c0 e1333c98 SPBBCDrv+0xe2d1
> ebd7d9cc ebaebb6d ebd7d9f4 e17d7640 829944c0 SPBBCDrv+0x10a86
> ebd7d9e4 ebaeb0d7 ebd7d9f4 e1019a30 ebb28220 SPBBCDrv+0x13b6d
> ebd7da24 ebd19788 829944c0 e17d7648 ebd1bad6 SPBBCDrv+0x130d7
> ebd7da30 ebd1bad6 e17d7648 e1a63ed8 e17d7640
> SYMEVENT!EventObjectDestroy+0x138
> ebd7da4c ebd1bc7d e17d7640 ebd7daa0 e1a63efc
> SYMEVENT!EventObjectCreate+0x1b36
> ebd7da5c ebd12f19 ebd7daa0 e1a63efc ebd7daa0
> SYMEVENT!EventObjectCreate+0x1cdd
> ebd7da6c ebd1a8e8 ebd7daa0 81e73018 ebd7daa0
> SYMEVENT!SYMEvent_GetVMDataPtr+0x7579
> ebd7dabc 804e37f7 827f5ac0 81e73008 81e73008
> SYMEVENT!EventObjectCreate+0x948
> ebd7dacc 8057069a 82b0ee18 8240ec14 ebd7dc74 nt!IopfCallDriver+0x31
> ebd7dbac 8056316c 82b0ee30 00000000 8240eb70 nt!IopParseDevice+0xa58
> ebd7dc34 8056729a 00000000 ebd7dc74 00000240 nt!ObpLookupObjectName+0x56a
> ebd7dc88 80570b73 00000000 00000000 01001b00 nt!ObOpenObjectByName+0xeb
> ebd7dd04 80570c42 ebd7e7dc 00000020 ebd7e77c nt!IopCreateFile+0x407
> ebd7dd60 80570d0a ebd7e7dc 00000020 ebd7e77c nt!IoCreateFile+0x8e
> ebd7dda0 b9ffe575 ebd7e7dc 00000020 ebd7e77c nt!NtOpenFile+0x27
> ebd7e5d4 804de7ec ebd7e7dc 00000020 ebd7e77c dg!NewZwOpenFile+0x95 [@
> 4235]
>
>
> FOLLOWUP_IP:
> SYMEVENT!SYMEvent_GetVMDataPtr+86d4
> ebd14074 894618 mov [esi+0x18],eax
>
> SYMBOL_STACK_INDEX: 7
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> MODULE_NAME: SYMEVENT
>
> IMAGE_NAME: SYMEVENT.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 423f8ec8
>
> STACK_COMMAND: .tss 28 ; kb
>
> FAILURE_BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

6

Kernel stack overflow.

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

----- Original Message -----
From: “Omer B”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 04, 2005 2:19 PM
Subject: [ntdev] HELP! - ZwWriteFile() from a hooked ZwOpenFile() always
crashes

Hi

My driver is hooking ZwOpenFile(). In my hook function, except calling
the original ZwOpenFile(), I also call a logging function that uses
ZwWriteFile() to print log data to file.
For some reason, each time I call my log function from ZwOpenFile()
and ZwWriteFile() is called, I get a BSOD with
UNEXPECTED_KERNEL_MODE_TRAP (7f).

The log function uses mutexes for synchronization.
Using this log function from another hooked function (ZwCreateFile) works ok.
Attached WinDbg’s dump analysis.

Thanks
================================================================
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=0000018c ebx=8210e008 ecx=00000000 edx=e1dd2ad8 esi=ebd7c590 edi=82b24100
eip=f85a73ba esp=ebd7c000 ebp=ebd7c19c iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
Ntfs!_SEH_prolog+0x1a:
f85a73ba 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from f85a7cf6 to f85a73ba

STACK_TEXT:
ebd7c19c f85a7cf6 ebd7c590 8210e008 e1dd2ad8 Ntfs!_SEH_prolog+0x1a
ebd7c384 f85a8ae9 ebd7c590 8210e008 e1dd2ad8 Ntfs!NtfsNonCachedIo+0x20e
ebd7c580 f85a8c97 ebd7c590 8210e008 0110070a Ntfs!NtfsCommonWrite+0x1949
ebd7c6f4 804e37f7 82b24020 8210e008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
ebd7c704 f864b3ca 804e8a39 00000000 ebd7c7bc nt!IopfCallDriver+0x31
ebd7c714 804e37f7 82b89020 8210e008 ebd7c76c sr!SrWrite+0xaa
ebd7c724 ebd14074 00000000 ebd7c76c 828fb490 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be wrong.
ebd7c7bc 804ee6a6 82af7b0a ebd7c7e4 ebd7c878
SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
ebd7c898 804ee45d e249a00c e249a010 e249a010 nt!MiFlushSectionInternal+0x38b
ebd7c8d4 805079bb 00000000 e249a00c 00000001 nt!MmFlushSection+0x1e0
ebd7c8ec 804f60ee 8201d008 00000000 00000000 nt!CcMapAndCopy+0x45d
ebd7c968 804f5e75 8201d008 ba009107 ebd7c9ac nt!CcMapAndCopy+0x2fa
ebd7c9f4 f85abb66 82af7b38 ebd7cbc4 00000003 nt!CcCopyWrite+0x28e
ebd7cbe8 f85a8c97 81abd008 82ad8008 82ad8008 Ntfs!NtfsCommonWrite+0x1d2a
ebd7cc4c 804e37f7 82b24020 82ad8008 82b88d10 Ntfs!NtfsFsdWrite+0xf3
ebd7cc5c f864b3ca 804e8a39 00000000 ebd7cd14 nt!IopfCallDriver+0x31
ebd7cc6c 804e37f7 82b89020 e2405c88 ebd7ccc4 sr!SrWrite+0xaa
ebd7cc7c ebd14074 00000000 ebd7ccc4 828fb490 nt!IopfCallDriver+0x31
ebd7cd14 805784c0 827f5ac0 82ad8008 82af7b38
SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4
ebd7cdc8 804de7ec 80000160 00000000 00000000 nt!NtWriteFile+0x602
ebd7cdc8 804ddc35 80000160 00000000 00000000 nt!KiFastCallEntry+0xf8
ebd7ce64 b9fff72f 80000160 00000000 00000000 nt!ZwWriteFile+0x11
ebd7cedc b9ffe58b ba007f00 ebd7d71c 00000000 dg!LogToFile+0x7f [@ 5311]
ebd7d6fc 804de7ec ebd7d7d8 00100080 ebd7d7b8 dg!NewZwOpenFile+0xab [@ 4256]
ebd7d6fc 804dcfdd ebd7d7d8 00100080 ebd7d7b8 nt!KiFastCallEntry+0xf8
ebd7d78c ebadb2ca ebd7d7d8 00100080 ebd7d7b8 nt!ZwOpenFile+0x11
ebd7d7dc ebadb963 ebd7d800 ebd7d808 ebd7d814 SPBBCDrv+0x32ca
ebd7d81c ebaea53a e15a2ac0 e1fd9450 00000002 SPBBCDrv+0x3963
ebd7d858 ebaf4645 ebd7d930 00000005 00000006 SPBBCDrv+0x1253a
ebd7d888 ebaf4376 ebd7d980 e1cec418 00000000 SPBBCDrv+0x1c645
ebd7d8c0 ebae5e5d 00000000 ebd7d980 e11f24f0 SPBBCDrv+0x1c376
ebd7d974 ebae3dcb e1c92410 ebd7d8ec ebd7d960 SPBBCDrv+0xde5d
ebd7d994 ebae62d1 ebd7d9f4 829a89e0 e1c92410 SPBBCDrv+0xbdcb
ebd7d9bc ebae8a86 00d7d9f4 829944c0 e1333c98 SPBBCDrv+0xe2d1
ebd7d9cc ebaebb6d ebd7d9f4 e17d7640 829944c0 SPBBCDrv+0x10a86
ebd7d9e4 ebaeb0d7 ebd7d9f4 e1019a30 ebb28220 SPBBCDrv+0x13b6d
ebd7da24 ebd19788 829944c0 e17d7648 ebd1bad6 SPBBCDrv+0x130d7
ebd7da30 ebd1bad6 e17d7648 e1a63ed8 e17d7640 SYMEVENT!EventObjectDestroy+0x138
ebd7da4c ebd1bc7d e17d7640 ebd7daa0 e1a63efc SYMEVENT!EventObjectCreate+0x1b36
ebd7da5c ebd12f19 ebd7daa0 e1a63efc ebd7daa0 SYMEVENT!EventObjectCreate+0x1cdd
ebd7da6c ebd1a8e8 ebd7daa0 81e73018 ebd7daa0
SYMEVENT!SYMEvent_GetVMDataPtr+0x7579
ebd7dabc 804e37f7 827f5ac0 81e73008 81e73008 SYMEVENT!EventObjectCreate+0x948
ebd7dacc 8057069a 82b0ee18 8240ec14 ebd7dc74 nt!IopfCallDriver+0x31
ebd7dbac 8056316c 82b0ee30 00000000 8240eb70 nt!IopParseDevice+0xa58
ebd7dc34 8056729a 00000000 ebd7dc74 00000240 nt!ObpLookupObjectName+0x56a
ebd7dc88 80570b73 00000000 00000000 01001b00 nt!ObOpenObjectByName+0xeb
ebd7dd04 80570c42 ebd7e7dc 00000020 ebd7e77c nt!IopCreateFile+0x407
ebd7dd60 80570d0a ebd7e7dc 00000020 ebd7e77c nt!IoCreateFile+0x8e
ebd7dda0 b9ffe575 ebd7e7dc 00000020 ebd7e77c nt!NtOpenFile+0x27
ebd7e5d4 804de7ec ebd7e7dc 00000020 ebd7e77c dg!NewZwOpenFile+0x95 [@ 4235]

FOLLOWUP_IP:
SYMEVENT!SYMEvent_GetVMDataPtr+86d4
ebd14074 894618 mov [esi+0x18],eax

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: SYMEVENT!SYMEvent_GetVMDataPtr+86d4

MODULE_NAME: SYMEVENT

IMAGE_NAME: SYMEVENT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 423f8ec8

STACK_COMMAND: .tss 28 ; kb

FAILURE_BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4

BUCKET_ID: 0x7f_8_SYMEVENT!SYMEvent_GetVMDataPtr+86d4

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

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com