ZwQuerySymbolicLinkObject() * 2

OSR_Community_User · December 26, 2006, 5:17am

Hi Everyone:

I have confused with a system dump for several days. The following is my dump file
's result.

The system core dump happened just after reboot. From the dump file I found
ZwQuerySymbolicLinkObject() was called two times and the system core dump
happened at the second time. I don’t known that’s what.

Loading Dump File [D:\Documents and Settings\wmma\Desktop\Mini122606-07.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: E:\2;srv*E:\DownstreamStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d9000 PsLoadedModuleList = 0x8055c420
Debug session time: Tue Dec 26 17:02:50.736 2006 (GMT+8)
System Uptime: 0 days 0:00:46.296
Loading Kernel Symbols
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000006, 805f4f65, f00b0994, 0}

*** WARNING: Unable to verify timestamp for FFCFILT.sys
Probably caused by : FFCFILT.sys ( FFCFILT!QuerySymbolicLink+13a )

Followup: MachineOwner

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000006, The exception code that was not handled
Arg2: 805f4f65, The address that the exception occurred at
Arg3: f00b0994, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - “0x%08lx”

FAULTING_IP:
nt!ObReferenceObjectByHandle+258
805f4f65 b101 mov cl,1

TRAP_FRAME: f00b1c44 – (.trap fffffffff00b1c44)
ErrCode = 00000000
eax=ffa01ddc ebx=ffa01da8 ecx=00000000 edx=00000000 esi=ffa01f70 edi=e13e1518
eip=805ef859 esp=f00b1cb8 ebp=f00b1d50 iopl=0 nv up ei ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297
nt!NtRequestWaitReplyPort+0x60e:
805ef859 c6434901 mov byte ptr [ebx+49h],1 ds:0023:ffa01df1=01
Resetting default scope

CUSTOMER_CRASH_COUNT: 7

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: IFXTCS.exe

LAST_CONTROL_TRANSFER: from 80580cda to 805f4f65

STACK_TEXT:
f00b0a1c 80580cda 00000b88 00000001 00000000 nt!ObReferenceObjectByHandle+0x258
f00b0a7c 804e07ec 80000b88 f00b0b8c 00000000 nt!NtQuerySymbolicLinkObject+0xe2
f00b0a7c 804df415 80000b88 f00b0b8c 00000000 nt!KiFastCallEntry+0xf8
f00b0b00 f9907fda 80000b88 f00b0b8c 00000000 nt!ZwQuerySymbolicLinkObject+0x11
f00b0b6c f9908123 f00b0b9c f00b0b8c 00000006 FFCFILT!QuerySymbolicLink+0x13a [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1763]
f00b0bbc f99082f1 f00b0e38 f00b0bd0 00000000 FFCFILT!VolumeDeviceNameToDosName+0xb3 [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1823]
f00b0e40 f9905923 ffa01284 f00b112c f00b1104 FFCFILT!GetOperationDataFullPath+0xa1 [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1909]
f00b110c f9494944 ffa01284 f00b112c f00b115c FFCFILT!FiltPreOperationCallback+0x243 [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\ffcfilt.c @ 804]
f00b116c f9496352 000b11b4 00000000 f00b11b4 fltMgr!FltpPerformPreCallbacks+0x2d4
f00b1180 f9496c15 f00b11b4 00000000 ffbc49b8 fltMgr!FltpPassThroughInternal+0x32
f00b119c f9496ffb f00b1101 ffb89f90 80eca918 fltMgr!FltpPassThrough+0x1df
f00b11cc 804e57f7 ffb28a18 ff9e6728 00112000 fltMgr!FltpDispatch+0xf3
f00b11dc 804f7508 00000000 80ed3560 80ed3570 nt!IopfCallDriver+0x31
f00b11f0 804f752f ffb28a18 80ed350b 80ed3578 nt!IopPageReadInternal+0xf4
f00b1210 804f7194 ffb89f90 80ed3598 80ed3578 nt!IoPageRead+0x1b
f00b1284 804edace 0625f860 805f4f65 c02017d0 nt!MiDispatchFault+0x274
f00b12d4 804e3718 00000000 805f4f65 00000000 nt!MmAccessFault+0x5bc
f00b12d4 805f4f65 00000000 805f4f65 00000000 nt!KiTrap0E+0xcc
f00b1374 80580cda 00000bb0 00000001 00000000 nt!ObReferenceObjectByHandle+0x258
f00b13d4 804e07ec 80000bb0 f00b14e4 00000000 nt!NtQuerySymbolicLinkObject+0xe2
f00b13d4 804df415 80000bb0 f00b14e4 00000000 nt!KiFastCallEntry+0xf8
f00b1458 f9907fda 80000bb0 f00b14e4 00000000 nt!ZwQuerySymbolicLinkObject+0x11
f00b14c4 f9908123 f00b14f4 f00b14e4 00000006 FFCFILT!QuerySymbolicLink+0x13a [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1763]
f00b1514 f99082f1 f00b1790 f00b1528 ffffffff FFCFILT!VolumeDeviceNameToDosName+0xb3 [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1823]
f00b1798 f9905923 ff9c9acc f00b1a84 f00b1a5c FFCFILT!GetOperationDataFullPath+0xa1 [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1909]
f00b1a64 f9494944 ff9c9acc f00b1a84 f00b1ab4 FFCFILT!FiltPreOperationCallback+0x243 [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\ffcfilt.c @ 804]
f00b1ac4 f9496352 000b1b0c 00000000 f00b1b0c fltMgr!FltpPerformPreCallbacks+0x2d4
f00b1ad8 f9496c15 f00b1b0c 00000000 ffbc49b8 fltMgr!FltpPassThroughInternal+0x32
f00b1af4 f9496ffb f00b1b01 ffb89f90 80eca918 fltMgr!FltpPassThrough+0x1df
f00b1b24 804e57f7 ffb28a18 80d83670 0010e000 fltMgr!FltpDispatch+0xf3
f00b1b34 804f7508 00000000 80f464b0 80f464c0 nt!IopfCallDriver+0x31
f00b1b48 804f752f ffb28a18 80f4640b 80f464c8 nt!IopPageReadInternal+0xf4
f00b1b68 804f7194 ffb89f90 80f464e8 80f464c8 nt!IoPageRead+0x1b
f00b1bdc 804edace 061de860 805ef859 c02017bc nt!MiDispatchFault+0x274
f00b1c2c 804e3718 00000000 805ef859 00000000 nt!MmAccessFault+0x5bc
f00b1c2c 805ef859 00000000 805ef859 00000000 nt!KiTrap0E+0xcc
f00b1d50 804e07ec 00000068 0014b280 0014b280 nt!NtRequestWaitReplyPort+0x60e
f00b1d50 7c94eb94 00000068 0014b280 0014b280 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
009afb0c 00000000 00000000 00000000 00000000 0x7c94eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
FFCFILT!QuerySymbolicLink+13a [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c @ 1763]
f9907fda ?? ???

FAULTING_SOURCE_CODE:
1759:
1760:
1761: try
1762: {

1763: status = ZwQuerySymbolicLinkObject(h, LinkTarget, NULL);
1764: ZwClose(h);
1765:
1766: }
1767: except( EXCEPTION_EXECUTE_HANDLER )
1768: {

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: FFCFILT!QuerySymbolicLink+13a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: FFCFILT

IMAGE_NAME: FFCFILT.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4590d9fd

FAILURE_BUCKET_ID: 0x8E_FFCFILT!QuerySymbolicLink+13a

BUCKET_ID: 0x8E_FFCFILT!QuerySymbolicLink+13a

Followup: MachineOwner

Slava_Imameyev · December 26, 2006, 6:28am

> I don’t known that’s what.

This is a really buggy FSD filter.
Did you bother to type .trap fffffffff00b1c44 in your debuger?
The page fault handler is called from ObReferenceObjectByHandle, in any case
this is processing of a page fault for a virtual page backed by the
pagefile( I suspect that the process’ handle table has been paged out ) and
your filter calls ZwQuerySymbolicLinkObject on that path, you really want to
receive either a BSOD or a deadlock or an infinite recursion.

–
Slava Imameyev, xxxxx@hotmail.com

wrote in message news:xxxxx@ntfsd…
> Hi Everyone:
>
> I have confused with a system dump for several days. The following is my
> dump file
> 's result.
>
> The system core dump happened just after reboot. From the dump file I
> found
> ZwQuerySymbolicLinkObject() was called two times and the system core dump
> happened at the second time. I don’t known that’s what.
>
> -----------------------------------------------------------------------------------------------------
>
> Microsoft (R) Windows Debugger Version 6.6.0007.5
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [D:\Documents and
> Settings\wmma\Desktop\Mini122606-07.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is:
> E:\2;srvE:\DownstreamStorehttp://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 2600.xpsp_sp2_gdr.050301-1519
> Kernel base = 0x804d9000 PsLoadedModuleList = 0x8055c420
> Debug session time: Tue Dec 26 17:02:50.736 2006 (GMT+8)
> System Uptime: 0 days 0:00:46.296
> Loading Kernel Symbols
> …
> Loading User Symbols
> Loading unloaded module list
> …
>
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 1000008E, {c0000006, 805f4f65, f00b0994, 0}
>
> WARNING: Unable to verify timestamp for FFCFILT.sys
> Probably caused by : FFCFILT.sys ( FFCFILT!QuerySymbolicLink+13a )
>
> Followup: MachineOwner
> ---------
>
> kd> !analyze -v
>*************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> This is a very common bugcheck. Usually the exception address pinpoints
> the driver/function that caused the problem. Always note this address
> as well as the link date of the driver/image that contains this address.
> Some common problems are exception code 0x80000003. This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. This will let us see why this breakpoint is
> happening.
> Arguments:
> Arg1: c0000006, The exception code that was not handled
> Arg2: 805f4f65, The address that the exception occurred at
> Arg3: f00b0994, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - “0x%08lx”
>
> FAULTING_IP:
> nt!ObReferenceObjectByHandle+258
> 805f4f65 b101 mov cl,1
>
> TRAP_FRAME: f00b1c44 – (.trap fffffffff00b1c44)
> ErrCode = 00000000
> eax=ffa01ddc ebx=ffa01da8 ecx=00000000 edx=00000000 esi=ffa01f70
> edi=e13e1518
> eip=805ef859 esp=f00b1cb8 ebp=f00b1d50 iopl=0 nv up ei ng nz ac pe
> cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010297
> nt!NtRequestWaitReplyPort+0x60e:
> 805ef859 c6434901 mov byte ptr [ebx+49h],1
> ds:0023:ffa01df1=01
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 7
>
> DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
>
> BUGCHECK_STR: 0x8E
>
> PROCESS_NAME: IFXTCS.exe
>
> LAST_CONTROL_TRANSFER: from 80580cda to 805f4f65
>
> STACK_TEXT:
> f00b0a1c 80580cda 00000b88 00000001 00000000
> nt!ObReferenceObjectByHandle+0x258
> f00b0a7c 804e07ec 80000b88 f00b0b8c 00000000
> nt!NtQuerySymbolicLinkObject+0xe2
> f00b0a7c 804df415 80000b88 f00b0b8c 00000000 nt!KiFastCallEntry+0xf8
> f00b0b00 f9907fda 80000b88 f00b0b8c 00000000
> nt!ZwQuerySymbolicLinkObject+0x11
> f00b0b6c f9908123 f00b0b9c f00b0b8c 00000006
> FFCFILT!QuerySymbolicLink+0x13a
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1763]
> f00b0bbc f99082f1 f00b0e38 f00b0bd0 00000000
> FFCFILT!VolumeDeviceNameToDosName+0xb3
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1823]
> f00b0e40 f9905923 ffa01284 f00b112c f00b1104
> FFCFILT!GetOperationDataFullPath+0xa1
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1909]
> f00b110c f9494944 ffa01284 f00b112c f00b115c
> FFCFILT!FiltPreOperationCallback+0x243
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\ffcfilt.c
> @ 804]
> f00b116c f9496352 000b11b4 00000000 f00b11b4
> fltMgr!FltpPerformPreCallbacks+0x2d4
> f00b1180 f9496c15 f00b11b4 00000000 ffbc49b8
> fltMgr!FltpPassThroughInternal+0x32
> f00b119c f9496ffb f00b1101 ffb89f90 80eca918 fltMgr!FltpPassThrough+0x1df
> f00b11cc 804e57f7 ffb28a18 ff9e6728 00112000 fltMgr!FltpDispatch+0xf3
> f00b11dc 804f7508 00000000 80ed3560 80ed3570 nt!IopfCallDriver+0x31
> f00b11f0 804f752f ffb28a18 80ed350b 80ed3578 nt!IopPageReadInternal+0xf4
> f00b1210 804f7194 ffb89f90 80ed3598 80ed3578 nt!IoPageRead+0x1b
> f00b1284 804edace 0625f860 805f4f65 c02017d0 nt!MiDispatchFault+0x274
> f00b12d4 804e3718 00000000 805f4f65 00000000 nt!MmAccessFault+0x5bc
> f00b12d4 805f4f65 00000000 805f4f65 00000000 nt!KiTrap0E+0xcc
> f00b1374 80580cda 00000bb0 00000001 00000000
> nt!ObReferenceObjectByHandle+0x258
> f00b13d4 804e07ec 80000bb0 f00b14e4 00000000
> nt!NtQuerySymbolicLinkObject+0xe2
> f00b13d4 804df415 80000bb0 f00b14e4 00000000 nt!KiFastCallEntry+0xf8
> f00b1458 f9907fda 80000bb0 f00b14e4 00000000
> nt!ZwQuerySymbolicLinkObject+0x11
> f00b14c4 f9908123 f00b14f4 f00b14e4 00000006
> FFCFILT!QuerySymbolicLink+0x13a
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1763]
> f00b1514 f99082f1 f00b1790 f00b1528 ffffffff
> FFCFILT!VolumeDeviceNameToDosName+0xb3
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1823]
> f00b1798 f9905923 ff9c9acc f00b1a84 f00b1a5c
> FFCFILT!GetOperationDataFullPath+0xa1
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1909]
> f00b1a64 f9494944 ff9c9acc f00b1a84 f00b1ab4
> FFCFILT!FiltPreOperationCallback+0x243
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\ffcfilt.c
> @ 804]
> f00b1ac4 f9496352 000b1b0c 00000000 f00b1b0c
> fltMgr!FltpPerformPreCallbacks+0x2d4
> f00b1ad8 f9496c15 f00b1b0c 00000000 ffbc49b8
> fltMgr!FltpPassThroughInternal+0x32
> f00b1af4 f9496ffb f00b1b01 ffb89f90 80eca918 fltMgr!FltpPassThrough+0x1df
> f00b1b24 804e57f7 ffb28a18 80d83670 0010e000 fltMgr!FltpDispatch+0xf3
> f00b1b34 804f7508 00000000 80f464b0 80f464c0 nt!IopfCallDriver+0x31
> f00b1b48 804f752f ffb28a18 80f4640b 80f464c8 nt!IopPageReadInternal+0xf4
> f00b1b68 804f7194 ffb89f90 80f464e8 80f464c8 nt!IoPageRead+0x1b
> f00b1bdc 804edace 061de860 805ef859 c02017bc nt!MiDispatchFault+0x274
> f00b1c2c 804e3718 00000000 805ef859 00000000 nt!MmAccessFault+0x5bc
> f00b1c2c 805ef859 00000000 805ef859 00000000 nt!KiTrap0E+0xcc
> f00b1d50 804e07ec 00000068 0014b280 0014b280
> nt!NtRequestWaitReplyPort+0x60e
> f00b1d50 7c94eb94 00000068 0014b280 0014b280 nt!KiFastCallEntry+0xf8
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 009afb0c 00000000 00000000 00000000 00000000 0x7c94eb94
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> FFCFILT!QuerySymbolicLink+13a
> [e:\ffc\v1.0l10\devprojects\09_mk1\src\ffcfilt\01_ffcfiltdrv\filter\mfiltlib.c
> @ 1763]
> f9907fda ?? ???
>
> FAULTING_SOURCE_CODE:
> 1759:
> 1760:
> 1761: try
> 1762: {
>> 1763: status = ZwQuerySymbolicLinkObject(h, LinkTarget, NULL);
> 1764: ZwClose(h);
> 1765:
> 1766: }
> 1767: except( EXCEPTION_EXECUTE_HANDLER )
> 1768: {
>
>
> SYMBOL_STACK_INDEX: 4
>
> SYMBOL_NAME: FFCFILT!QuerySymbolicLink+13a
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: FFCFILT
>
> IMAGE_NAME: FFCFILT.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4590d9fd
>
> FAILURE_BUCKET_ID: 0x8E_FFCFILT!QuerySymbolicLink+13a
>
> BUCKET_ID: 0x8E_FFCFILT!QuerySymbolicLink+13a
>
> Followup: MachineOwner
> ---------
>
>
>

OSR_Community_User · December 26, 2006, 6:58am

Thank you for your replay.

I typed " .trap fffffffff00b1c44 " command.

kd> .trap fffffffff0252c44
ErrCode = 00000000
eax=80e50674 ebx=80e50640 ecx=00000000 edx=00000000 esi=80e50808 edi=e13ee0e8
eip=805ef859 esp=f0252cb8 ebp=f0252d50 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!NtRequestWaitReplyPort+0x60e:
805ef859 c6434901 mov byte ptr [ebx+49h],1 ds:0023:80e50689=01

Slava_Imameyev · December 26, 2006, 7:58am

> I typed " .trap fffffffff00b1c44 " command.

Now KB, and you will see a real call stack.

–
Slava Imameyev, xxxxx@hotmail.com

wrote in message news:xxxxx@ntfsd…
> Thank you for your replay.
>
> I typed " .trap fffffffff00b1c44 " command.
>
> kd> .trap fffffffff0252c44
> ErrCode = 00000000
> eax=80e50674 ebx=80e50640 ecx=00000000 edx=00000000 esi=80e50808
> edi=e13ee0e8
> eip=805ef859 esp=f0252cb8 ebp=f0252d50 iopl=0 nv up ei pl nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010206
> nt!NtRequestWaitReplyPort+0x60e:
> 805ef859 c6434901 mov byte ptr [ebx+49h],1
> ds:0023:80e50689=01
>
>

OSR_Community_User · December 26, 2006, 8:33am

kd> KB
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
f0252d50 804e07ec 00000068 0014b280 0014b280 nt!NtRequestWaitReplyPort+0x60e
f0252d50 7c94eb94 00000068 0014b280 0014b280 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
009afb0c 00000000 00000000 00000000 00000000 0x7c94eb94

On Tue, 26 Dec 2006 15:58:00 +0300
“Slava Imameyev” wrote:

> > I typed " .trap fffffffff00b1c44 " command.
>
> Now KB, and you will see a real call stack.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
> > Thank you for your replay.
> >
> > I typed " .trap fffffffff00b1c44 " command.
> >
> > kd> .trap fffffffff0252c44
> > ErrCode = 00000000
> > eax=80e50674 ebx=80e50640 ecx=00000000 edx=00000000 esi=80e50808
> > edi=e13ee0e8
> > eip=805ef859 esp=f0252cb8 ebp=f0252d50 iopl=0 nv up ei pl nz na pe
> > nc
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > efl=00010206
> > nt!NtRequestWaitReplyPort+0x60e:
> > 805ef859 c6434901 mov byte ptr [ebx+49h],1
> > ds:0023:80e50689=01
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@psh.com.cn
> To unsubscribe send a blank email to xxxxx@lists.osr.com

-------------------------------------------------------------------
$B#1J,4V(B36$B%Z!<%8$NN>LL%9%-%c%J!<(B($B:GBg(BA3$B$^$G(B) ------------- ScanSnap$B!(B
$B#7%v9q8lL>;I4IM}%=%U%H!(BAcrobat 7.0$BF1:-$N%9%-%c%J!<(B ---- ScanSnap$B!(B
$B3Z!9J8=q4IM}%=%U%HF1:-$N%9%-%c%J!<(B --------------------- ScanSnap$B!(B

http://www.pfu.com.cn/jp/jwhatnew_scansnap.htm
http://www.pfu.com.cn/whatnew_scansnap.htm

-----------------------------------------------------
$BGO!!0NL@(B($B%P!!%$%a%$(B)
$B!!#P#F#U>e3$7W;;5!M-8B8x;J!!!(B $BBh;0E}3gIt7PM}(B
$B>e3$I,M%?.B)7OE}M-8B8x;J(B $BI{Am7PM}(B
$B>e3$;T7KJ?O)#5#5#59f#4#6Eo#5O0(B $BM9JXHV9f!‘(B200233
$B!!(BTel $B!’(B6495-0777 * 121 $B!!!(B COINS : 7987-6121
$B!!(BFax $B!‘(B6495-3773 COINS : 7987-6109
$B7HBS(B $B!’(B133-8621-0369
EMail$B!‘(xxxxx@psh.com.cn
MSN $B!’(xxxxx@cableplus.com.cn
----------------------------------------------------- *
$B>e3$I,M%?.B)7OE}M-8B8x;J$O#P#F#U>e3$7W;;5!M-8B8x;J#1#0#0!s=P;q$7$?;R2q

OSR_Community_User · December 26, 2006, 9:20am

Yes. I also found an infinite recursion from dump files.
But I don’t know that’s why.

My fitering driver keep watching on IRP_MJ_READ, IRP_MJ_WRITE…
When I received a IRP_MJ_READ, I used ZwOpenSymbolicLinkObject() and ZwQuerySymbolicLinkObject() to get the “C:” or “D:”

But Just after reboot, ZwQuerySymbolicLinkObject() was called by two times.
I guess when ZwQuerySymbolicLinkObject() was called , it put an other IRP_MJ_READ and ZwQuerySymbolicLinkObject() was called again, so IRQL was changed.

I noticed the EXCEPTION_CODE is :

EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - “0x%08lx”

//
// MessageId: STATUS_IN_PAGE_ERROR
//
// MessageText:
//
// The instruction at 0x%08lx referenced memory at 0x%08lx. The required data was not placed into memory because of an I/O error status of 0x%08lx.
//
#define STATUS_IN_PAGE_ERROR ((NTSTATUS)0xC0000006L) // winnt

OSR_Community_User · December 29, 2006, 7:09pm

why do you call those Zw* routines from IRP_MJ_READ ? …or why do you call
any complex functions from IRP_MJ_READ ?
Besides, they have to be used at PASSIVE_LEVEL

wrote in message news:xxxxx@ntfsd…
> Yes. I also found an infinite recursion from dump files.
> But I don’t know that’s why.
>
> My fitering driver keep watching on IRP_MJ_READ, IRP_MJ_WRITE…
> When I received a IRP_MJ_READ, I used ZwOpenSymbolicLinkObject() and
> ZwQuerySymbolicLinkObject() to get the “C:” or “D:”
>
> But Just after reboot, ZwQuerySymbolicLinkObject() was called by two
> times.
> I guess when ZwQuerySymbolicLinkObject() was called , it put an other
> IRP_MJ_READ and ZwQuerySymbolicLinkObject() was called again, so IRQL was
> changed.
>
> I noticed the EXCEPTION_CODE is :
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - “0x%08lx”
>
> //
> // MessageId: STATUS_IN_PAGE_ERROR
> //
> // MessageText:
> //
> // The instruction at 0x%08lx referenced memory at 0x%08lx. The required
> data was not placed into memory because of an I/O error status of 0x%08lx.
> //
> #define STATUS_IN_PAGE_ERROR ((NTSTATUS)0xC0000006L) //
> winnt
>
>

OSR_Community_User · January 1, 2007, 8:20am

Because I want to get the DOS name just as “C:”, “D:” when I received a
IRP_MJ_READ or IRP_MJ_WRITE.

If I don’t use those Zw* routines, would you tell me what routines I can use.

Thank you very much.

On Sat, 30 Dec 2006 01:08:24 +0100
“Petr Kurtin” wrote:

> why do you call those Zw* routines from IRP_MJ_READ ? …or why do you call
> any complex functions from IRP_MJ_READ ?
> Besides, they have to be used at PASSIVE_LEVEL
>
>
> wrote in message news:xxxxx@ntfsd…
> > Yes. I also found an infinite recursion from dump files.
> > But I don’t know that’s why.
> >
> > My fitering driver keep watching on IRP_MJ_READ, IRP_MJ_WRITE…
> > When I received a IRP_MJ_READ, I used ZwOpenSymbolicLinkObject() and
> > ZwQuerySymbolicLinkObject() to get the “C:” or “D:”
> >
> > But Just after reboot, ZwQuerySymbolicLinkObject() was called by two
> > times.
> > I guess when ZwQuerySymbolicLinkObject() was called , it put an other
> > IRP_MJ_READ and ZwQuerySymbolicLinkObject() was called again, so IRQL was
> > changed.
> >
> > I noticed the EXCEPTION_CODE is :
> >
> > EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - “0x%08lx”
> >
> > //
> > // MessageId: STATUS_IN_PAGE_ERROR
> > //
> > // MessageText:
> > //
> > // The instruction at 0x%08lx referenced memory at 0x%08lx. The required
> > data was not placed into memory because of an I/O error status of 0x%08lx.
> > //
> > #define STATUS_IN_PAGE_ERROR ((NTSTATUS)0xC0000006L) //
> > winnt
> >
> >
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@psh.com.cn
> To unsubscribe send a blank email to xxxxx@lists.osr.com

-------------------------------------------------------------------
ï¼‘åˆ†é–“36ãƒšãƒ¼ã‚¸ã®ä¸¡é¢ã‚¹ã‚ãƒ£ãƒŠãƒ¼(æœ€å¤§A3ã¾ã§) ------------- ScanSnapï¼
ï¼—ãƒ¶å›½èªžååˆºç®¡ç†ã‚½ãƒ•ãƒˆï¼‹Acrobat 7.0åŒæ¢±ã®ã‚¹ã‚ãƒ£ãƒŠãƒ¼ ---- ScanSnapï¼
æ¥½ã€…æ–‡æ›¸ç®¡ç†ã‚½ãƒ•ãƒˆåŒæ¢±ã®ã‚¹ã‚ãƒ£ãƒŠãƒ¼ --------------------- ScanSnapï¼

http://www.pfu.com.cn/jp/jwhatnew_scansnap.htm
http://www.pfu.com.cn/whatnew_scansnap.htm

* -----------------------------------------------------
é¦¬ã€€å‰æ˜Ž(ãƒã€€ã‚¤ãƒ¡ã‚¤)
ã€€ï¼°ï¼¦ï¼µä¸Šæµ·è¨ˆç®—æ©Ÿæœ‰é™å…¬å¸ã€€ã€€ã€€ ç¬¬ä¸‰çµ±æ‹¬éƒ¨çµŒç†
ä¸Šæµ·å¿…å„ªä¿¡æ¯ç³»çµ±æœ‰é™å…¬å¸ å‰¯ç·çµŒç†
ä¸Šæµ·å¸‚æ¡‚å¹³è·¯ï¼•ï¼•ï¼•å·ï¼”ï¼–æ£Ÿï¼•æ¥¼ éƒµä¾¿ç•ªå·ï¼š200233
ã€€Tel ï¼š6495-0777 * 121 ã€€ã€€ã€€ COINS : 7987-6121
ã€€Fax ï¼š6495-3773 COINS : 7987-6109
æºå¸¯ ï¼š133-8621-0369
EMailï¼šxxxxx@psh.com.cn
MSN ï¼šxxxxx@cableplus.com.cn
----------------------------------------------------- *
ä¸Šæµ·å¿…å„ªä¿¡æ¯ç³»çµ±æœ‰é™å…¬å¸ã¯ï¼°ï¼¦ï¼µä¸Šæµ·è¨ˆç®—æ©Ÿæœ‰é™å…¬å¸ï¼‘ï¼ï¼ï¼…å‡ºè³‡ã—ãŸåä¼šç¤¾ã§ã™ã€‚