Using RtlInitUnicodeString result in BSOD

OSR_Community_User · November 2, 2005, 9:59pm

My KernelMode Driver hook ZwQueryDirectoryFile routine,it’s usually work
fine,but when i plug and unplug usb mouse about 800 times result in BSOD.I
analyse the bugcheck,it show me that my driver call RtlInitUnicodeString
result in accessing memory violation.

NTSTATUS MyNtQueryDirectoryFile(
IN HANDLE hFile,
IN HANDLE hEvent OPTIONAL,
IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
IN PVOID IoApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK pIoStatusBlock,
OUT PVOID FileInformationBuffer,
IN ULONG FileInformationBufferLength,
IN FILE_INFORMATION_CLASS FileInfoClass,
IN BOOLEAN bReturnOnlyOneEntry,
IN PUNICODE_STRING PathMask OPTIONAL,
IN BOOLEAN bRestartQuery
)
{
…
…
…

rc = ((NTQUERYDIRECTORYFILE)(OldNtQueryDirectoryFile))(
hFile,
hEvent,
IoApcRoutine,
IoApcContext,
pIoStatusBlock,
FileInformationBuffer,
FileInformationBufferLength,
FileInfoClass,
bReturnOnlyOneEntry,
PathMask,
bRestartQuery);

if(NT_SUCCESS(rc))
{
PDirEntry p = NULL;
PDirEntry pLast = NULL;
BOOL bLastOne = FALSE;
int found = 0;
p = (PDirEntry)FileInformationBuffer;
pLast = NULL;

if(FileInfoClass == FileBothDirectoryInformation)
{
PFILE_BOTH_DIR_INFORMATION pFileInfo = NULL;
PFILE_BOTH_DIR_INFORMATION pLastFileInfo = NULL;
BOOL bLastOne = FALSE;

pFileInfo
= (PFILE_BOTH_DIR_INFORMATION)FileInformationBuffer;
pLastFileInfo = NULL;

do
{
bLastOne = !( pFileInfo->NextEntryOffset );
//memset(uniFileName.Buffer,0,uniFileName.Length);
RtlInitUnicodeString( &uniFileName,
pFileInfo->FileName ); // result in BSOD every once in a while
…
…
…
}
…
…
}
…
…
}

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
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: c0000005, The exception code that was not handled
Arg2: 8052e77f, The address that the exception occurred at
Arg3: aa8c23f8, Trap Frame
Arg4: 00000000

Debugging Details:

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

FAULTING_IP:
nt!RtlInitUnicodeString+1b
8052e77f f266af repne scasw

TRAP_FRAME: aa8c23f8 – (.trap ffffffffaa8c23f8)
ErrCode = 00000000
eax=00000000 ebx=f9a0a720 ecx=ffffffee edx=aa8c24ac esi=00c6e7a8
edi=0016b000
eip=8052e77f esp=aa8c246c ebp=aa8c2d30 iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!RtlInitUnicodeString+0x1b:
8052e77f f266af repne scasw es:0016b000
=???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 8053c4f4 to 8052e77f

STACK_TEXT:
aa8c24bc 8053c4f4 00000000 00000000 00000000 nt!RtlInitUnicodeString+0x1b
aa8c2d30 8054160c 00000528 00000000 00000000 nt!_flsbuf+0xa3
aa8c2d30 7c92eb94 00000528 00000000 00000000 nt!KiFastCallEntry+0xfc
00c6e770 7c92df6a 7c80f26f 00000528 00000000 ntdll!KiFastSystemCallRet
00c6e774 7c80f26f 00000528 00000000 00000000 ntdll!ZwQueryDirectoryFile+0xc
00c6e7f0 760b7362 000c3978 00c6e87c 00000000 kernel32!FindNextFileW+0xaa
00c6ead0 760b758f 000c4898 00031d00 00092fa8
setupapi!InfCacheSearchDirectory+0x470
00c6eb04 760a72d9 000c4898 00031d00 00092fa8
setupapi!InfCacheSearchPath+0x52
00c6eba4 76083e4e 00000000 00000005 76082349
setupapi!EnumDrvInfsInDirPathList+0x262
00c6f3b4 7e1f01d9 000b64a0 00c6fcf4 00000002
setupapi!SetupDiBuildDriverInfoList+0x9a7
00c6ff1c 7e1e9a76 00d412e0 7e1fa1dc 00c6ff64
umpnpmgr!InstallDeviceServerSide+0x144
00c6ffb4 7c80b50b 00000000 7c9363a8 00c2feb8
umpnpmgr!ThreadProc_DeviceInstall+0x449
00c6ffec 00000000 7e1e5dbf 00000000 00000000 kernel32!BaseThreadStart+0x37

FOLLOWUP_IP:
nt!_flsbuf+a3
8053c4f4 43 inc ebx

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!_flsbuf+a3

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e

STACK_COMMAND: .trap ffffffffaa8c23f8 ; kb

FAILURE_BUCKET_ID: 0x8E_nt!_flsbuf+a3

BUCKET_ID: 0x8E_nt!_flsbuf+a3

Followup: MachineOwner

Best Regards

Ken Wang

OSR_Community_User · November 3, 2005, 1:11am

Well, not speaking about that hooking shouldn’t be used,
you are using RtlInitUnicodeString wrong.

It requires zero terminated strings, but the string
in FILE_BOTH_DIRECTORY_INFORMATION
is not zero terminated. Instead of this, its length
is stored in the structure.

L.

OSR_Community_User · November 3, 2005, 3:23am

Sorry, there are no reliable means of hooking.

I hope that your hooking software is not preinstalled on Lenovo laptops. If
it is - then I would choose Asus or Acer instead

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

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Thursday, November 03, 2005 5:28 AM
Subject: [ntfsd] Using RtlInitUnicodeString result in BSOD

> My KernelMode Driver hook ZwQueryDirectoryFile routine,it’s usually work
> fine,but when i plug and unplug usb mouse about 800 times result in BSOD.I
> analyse the bugcheck,it show me that my driver call RtlInitUnicodeString
> result in accessing memory violation.
>
>
> NTSTATUS MyNtQueryDirectoryFile(
> IN HANDLE hFile,
> IN HANDLE hEvent OPTIONAL,
> IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
> IN PVOID IoApcContext OPTIONAL,
> OUT PIO_STATUS_BLOCK pIoStatusBlock,
> OUT PVOID FileInformationBuffer,
> IN ULONG FileInformationBufferLength,
> IN FILE_INFORMATION_CLASS FileInfoClass,
> IN BOOLEAN bReturnOnlyOneEntry,
> IN PUNICODE_STRING PathMask OPTIONAL,
> IN BOOLEAN bRestartQuery
> )
> {
> …
> …
> …
>
> rc = ((NTQUERYDIRECTORYFILE)(OldNtQueryDirectoryFile))(
> hFile,
> hEvent,
> IoApcRoutine,
> IoApcContext,
> pIoStatusBlock,
> FileInformationBuffer,
> FileInformationBufferLength,
> FileInfoClass,
> bReturnOnlyOneEntry,
> PathMask,
> bRestartQuery);
>
> if(NT_SUCCESS(rc))
> {
> PDirEntry p = NULL;
> PDirEntry pLast = NULL;
> BOOL bLastOne = FALSE;
> int found = 0;
> p = (PDirEntry)FileInformationBuffer;
> pLast = NULL;
>
>
> if(FileInfoClass == FileBothDirectoryInformation)
> {
> PFILE_BOTH_DIR_INFORMATION pFileInfo = NULL;
> PFILE_BOTH_DIR_INFORMATION pLastFileInfo = NULL;
> BOOL bLastOne = FALSE;
>
> pFileInfo
> = (PFILE_BOTH_DIR_INFORMATION)FileInformationBuffer;
> pLastFileInfo = NULL;
>
> do
> {
> bLastOne = !( pFileInfo->NextEntryOffset );
> //memset(uniFileName.Buffer,0,uniFileName.Length);
> RtlInitUnicodeString( &uniFileName,
> pFileInfo->FileName ); // result in BSOD every once in a while
> …
> …
> …
> }
> …
> …
> }
> …
> …
> }
>
>
>
>
*****
>
>
> * Bugcheck Analysis
>
>
>
>

>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
> 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: c0000005, The exception code that was not handled
> Arg2: 8052e77f, The address that the exception occurred at
> Arg3: aa8c23f8, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>
> FAULTING_IP:
> nt!RtlInitUnicodeString+1b
> 8052e77f f266af repne scasw
>
> TRAP_FRAME: aa8c23f8 – (.trap ffffffffaa8c23f8)
> ErrCode = 00000000
> eax=00000000 ebx=f9a0a720 ecx=ffffffee edx=aa8c24ac esi=00c6e7a8
> edi=0016b000
> eip=8052e77f esp=aa8c246c ebp=aa8c2d30 iopl=0 nv up ei pl zr na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!RtlInitUnicodeString+0x1b:
> 8052e77f f266af repne scasw es:0016b000
> =???
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 8053c4f4 to 8052e77f
>
> STACK_TEXT:
> aa8c24bc 8053c4f4 00000000 00000000 00000000 nt!RtlInitUnicodeString+0x1b
> aa8c2d30 8054160c 00000528 00000000 00000000 nt!_flsbuf+0xa3
> aa8c2d30 7c92eb94 00000528 00000000 00000000 nt!KiFastCallEntry+0xfc
> 00c6e770 7c92df6a 7c80f26f 00000528 00000000 ntdll!KiFastSystemCallRet
> 00c6e774 7c80f26f 00000528 00000000 00000000 ntdll!ZwQueryDirectoryFile+0xc
> 00c6e7f0 760b7362 000c3978 00c6e87c 00000000 kernel32!FindNextFileW+0xaa
> 00c6ead0 760b758f 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchDirectory+0x470
> 00c6eb04 760a72d9 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchPath+0x52
> 00c6eba4 76083e4e 00000000 00000005 76082349
> setupapi!EnumDrvInfsInDirPathList+0x262
> 00c6f3b4 7e1f01d9 000b64a0 00c6fcf4 00000002
> setupapi!SetupDiBuildDriverInfoList+0x9a7
> 00c6ff1c 7e1e9a76 00d412e0 7e1fa1dc 00c6ff64
> umpnpmgr!InstallDeviceServerSide+0x144
> 00c6ffb4 7c80b50b 00000000 7c9363a8 00c2feb8
> umpnpmgr!ThreadProc_DeviceInstall+0x449
> 00c6ffec 00000000 7e1e5dbf 00000000 00000000 kernel32!BaseThreadStart+0x37
>
>
> FOLLOWUP_IP:
> nt!_flsbuf+a3
> 8053c4f4 43 inc ebx
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!_flsbuf+a3
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
>
> STACK_COMMAND: .trap ffffffffaa8c23f8 ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> Followup: MachineOwner
>
>
> Best Regards
>
>
> Ken Wang
>
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Lyndon_J_Clarke-2 · November 3, 2005, 5:43am

Hmm … here we go again … please why do you want to hook
ZwQueryDirectoryFile?

wrote in message news:xxxxx@ntfsd…
> My KernelMode Driver hook ZwQueryDirectoryFile routine,it’s usually work
> fine,but when i plug and unplug usb mouse about 800 times result in BSOD.I
> analyse the bugcheck,it show me that my driver call RtlInitUnicodeString
> result in accessing memory violation.
>
>
> NTSTATUS MyNtQueryDirectoryFile(
> IN HANDLE hFile,
> IN HANDLE hEvent OPTIONAL,
> IN PIO_APC_ROUTINE IoApcRoutine OPTIONAL,
> IN PVOID IoApcContext OPTIONAL,
> OUT PIO_STATUS_BLOCK pIoStatusBlock,
> OUT PVOID FileInformationBuffer,
> IN ULONG FileInformationBufferLength,
> IN FILE_INFORMATION_CLASS FileInfoClass,
> IN BOOLEAN bReturnOnlyOneEntry,
> IN PUNICODE_STRING PathMask OPTIONAL,
> IN BOOLEAN bRestartQuery
> )
> {
> …
> …
> …
>
> rc = ((NTQUERYDIRECTORYFILE)(OldNtQueryDirectoryFile))(
> hFile,
> hEvent,
> IoApcRoutine,
> IoApcContext,
> pIoStatusBlock,
> FileInformationBuffer,
> FileInformationBufferLength,
> FileInfoClass,
> bReturnOnlyOneEntry,
> PathMask,
> bRestartQuery);
>
> if(NT_SUCCESS(rc))
> {
> PDirEntry p = NULL;
> PDirEntry pLast = NULL;
> BOOL bLastOne = FALSE;
> int found = 0;
> p = (PDirEntry)FileInformationBuffer;
> pLast = NULL;
>
>
> if(FileInfoClass == FileBothDirectoryInformation)
> {
> PFILE_BOTH_DIR_INFORMATION pFileInfo = NULL;
> PFILE_BOTH_DIR_INFORMATION pLastFileInfo = NULL;
> BOOL bLastOne = FALSE;
>
> pFileInfo
> = (PFILE_BOTH_DIR_INFORMATION)FileInformationBuffer;
> pLastFileInfo = NULL;
>
> do
> {
> bLastOne = !( pFileInfo->NextEntryOffset );
> //memset(uniFileName.Buffer,0,uniFileName.Length);
> RtlInitUnicodeString( &uniFileName,
> pFileInfo->FileName ); // result in BSOD every once in a while
> …
> …
> …
> }
> …
> …
> }
> …
> …
> }
>
>
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
> 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: c0000005, The exception code that was not handled
> Arg2: 8052e77f, The address that the exception occurred at
> Arg3: aa8c23f8, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>
> FAULTING_IP:
> nt!RtlInitUnicodeString+1b
> 8052e77f f266af repne scasw
>
> TRAP_FRAME: aa8c23f8 – (.trap ffffffffaa8c23f8)
> ErrCode = 00000000
> eax=00000000 ebx=f9a0a720 ecx=ffffffee edx=aa8c24ac esi=00c6e7a8
> edi=0016b000
> eip=8052e77f esp=aa8c246c ebp=aa8c2d30 iopl=0 nv up ei pl zr na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!RtlInitUnicodeString+0x1b:
> 8052e77f f266af repne scasw es:0016b000
> =???
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 8053c4f4 to 8052e77f
>
> STACK_TEXT:
> aa8c24bc 8053c4f4 00000000 00000000 00000000 nt!RtlInitUnicodeString+0x1b
> aa8c2d30 8054160c 00000528 00000000 00000000 nt!_flsbuf+0xa3
> aa8c2d30 7c92eb94 00000528 00000000 00000000 nt!KiFastCallEntry+0xfc
> 00c6e770 7c92df6a 7c80f26f 00000528 00000000 ntdll!KiFastSystemCallRet
> 00c6e774 7c80f26f 00000528 00000000 00000000
> ntdll!ZwQueryDirectoryFile+0xc
> 00c6e7f0 760b7362 000c3978 00c6e87c 00000000 kernel32!FindNextFileW+0xaa
> 00c6ead0 760b758f 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchDirectory+0x470
> 00c6eb04 760a72d9 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchPath+0x52
> 00c6eba4 76083e4e 00000000 00000005 76082349
> setupapi!EnumDrvInfsInDirPathList+0x262
> 00c6f3b4 7e1f01d9 000b64a0 00c6fcf4 00000002
> setupapi!SetupDiBuildDriverInfoList+0x9a7
> 00c6ff1c 7e1e9a76 00d412e0 7e1fa1dc 00c6ff64
> umpnpmgr!InstallDeviceServerSide+0x144
> 00c6ffb4 7c80b50b 00000000 7c9363a8 00c2feb8
> umpnpmgr!ThreadProc_DeviceInstall+0x449
> 00c6ffec 00000000 7e1e5dbf 00000000 00000000 kernel32!BaseThreadStart+0x37
>
>
> FOLLOWUP_IP:
> nt!_flsbuf+a3
> 8053c4f4 43 inc ebx
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!_flsbuf+a3
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
>
> STACK_COMMAND: .trap ffffffffaa8c23f8 ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> Followup: MachineOwner
>
>
> Best Regards
>
>
> Ken Wang
>
>
>
>
>
>