IRQL_NOT_LESS_OR_EQUAL Problem

NTDEV
1

Hey guys,

Inaugural post here. I’m doing something very similar to:
http://www.osronline.com/showthread.cfm?link=244071
In my driver I have registered a Load Image notification callback with
PsSetLoadImageNotifyRoutine. Within the callback I am trying to get the fully qualified name to do a file read on the specified image. I am trying to get the name by doing a ObQueryNameString on the file object in the IMAGE_INFO_EX. ObQueryNameString returns the proper name, however I am getting an IRQL_NOT_LESS_OR_EQUAL at some time AFTER returning from the callback. If I comment out the call to ObQueryNameString there is no problem.

I did take a look at http://www.osronline.com/showThread.cfm?link=186317
but the solution didn’t seem as clean as this one (if it works). I also have a hunch that I am somehow sidestepping the problem.

Bug Check info follows, lmk if code would be helpful. Any thoughts?

Thanks for the help.
Drew

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

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff80002befebf, 2, 0, fffff80002905f62}

Probably caused by : ntkrnlmp.exe ( nt!RtlDispatchException+122 )

Followup: MachineOwner

nt!DbgBreakPointWithStatus:
fffff800`028d0f60 cc int 3
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff80002befebf, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002905f62, address which referenced memory

Debugging Details:

READ_ADDRESS: fffff80002befebf

CURRENT_IRQL: 2

FAULTING_IP:
nt!RtlDispatchException+122
fffff800`02905f62 410fb60c24 movzx ecx,byte ptr [r12]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: explorer.exe

TRAP_FRAME: fffff88005780860 – (.trap 0xfffff88005780860)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8002fd90b0 rbx=0000000000000000 rcx=fffffa8002e4792b
rdx=0000000004860000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c1b2d5 rsp=fffff880057809f0 rbp=fffff88005780ca0
r8=fffff80002a51e80 r9=0000000000000100 r10=0000000000000080
r11=0000000000027a40 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe cy
nt! ?? ::NNGAKEGL::string'+0x2a839: fffff80002c1b2d5 e8aaf8c6ff call nt!KiCheckForKernelApcDelivery (fffff800`0288ab84)
Resetting default scope

EXCEPTION_RECORD: fffff880057802e8 – (.exr 0xfffff880057802e8)
ExceptionAddress: fffff800028dd4d8 (nt!KiTryUnwaitThread+0x0000000000000028)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

LAST_CONTROL_TRANSFER: from fffff800029ce6d2 to fffff800028d0f60

STACK_TEXT:
fffff8800577e9e8 fffff800029ce6d2 : fffff80002befebf fffffa8002fd9060 0000000000000065 fffff80002917314 : nt!DbgBreakPointWithStatus
fffff8800577e9f0 fffff800029cf4be : 0000000000000003 0000000000000000 fffff80002913ee0 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffff8800577ea50 fffff800028d9004 : fffff8800577f248 fffffa80030b5a80 0000000000ffc000 fffff800029566a2 : nt!KeBugCheck2+0x71e
fffff8800577f120 fffff800028d8469 : 000000000000000a fffff80002befebf 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
fffff8800577f160 fffff800028d70e0 : fffff8800577f298 00000000000002bf 0000000000000000 0000000000000100 : nt!KiBugCheckDispatch+0x69
fffff8800577f2a0 fffff80002905f62 : fffff80002befebf fffff8800577f478 fffff880057802e8 fffff80002867000 : nt!KiPageFault+0x260
fffff8800577f430 fffff800029131b5 : fffff880057802e8 fffff8800577fb40 fffff88000000000 fffffa8002e47900 : nt!RtlDispatchException+0x122
fffff8800577fb10 fffff800028d8542 : fffff880057802e8 cfe8cd8b49fff79a fffff88005780390 0000000000000000 : nt!KiDispatchException+0x135
fffff880057801b0 fffff800028d6e4a : 0000000000000000 0000000000000000 0000000000000200 fffff98007063000 : nt!KiExceptionDispatch+0xc2
fffff88005780390 fffff800028dd4d8 : 0000000000000000 fffff98007062c60 fffffa8002e47920 fffff80002d7d5ec : nt!KiGeneralProtectionFault+0x10a
fffff88005780520 fffff80002953244 : fffff9800796cc60 0000000000000000 0000000000000000 fffffa8002e47920 : nt!KiTryUnwaitThread+0x28
fffff88005780580 fffff800028b592f : 8b4400001f93e990 fffff6fc000160d9 fffff80002a64400 fffff80000000000 : nt! ?? ::FNODOBFM::string'+0x3cb00 fffff88005780650 fffff8000288aba9 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDeliverApc+0x1d7 fffff880057806d0 fffff800028f4424 : 0000000000000000 0000000000000008 ffffffffffffffff 0000000000000080 : nt!KiCheckForKernelApcDelivery+0x25 fffff88005780700 fffff800028d6fee : 0000000000000008 fffffa8002fd9060 fffffa8002fd9000 0000000000000000 : nt!MmAccessFault+0x1844 fffff88005780860 fffff80002c1b2d5 : fffffa8002e5a920 fffffa8002e5cb30 fffff88005780b50 fffff88005780b48 : nt!KiPageFault+0x16e fffff880057809f0 fffff80002befebf : fffff80000000001 fffffa8002e5cb30 fffff88005780b50 0000000000000000 : nt! ?? ::NNGAKEGL::string’+0x2a839
fffff88005780ae0 fffff800028d8153 : 0000000000000b48 fffffa8002fd9060 000000000609dad8 0000000000000b01 : nt!NtMapViewOfSection+0x2be
fffff88005780bb0 00000000773c013a : 000007fefd5e22b1 0000000000000000 000007fefd5ea512 000000000609dbf8 : nt!KiSystemServiceCopyEnd+0x13
000000000609dab8 000007fefd5e22b1 : 0000000000000000 000007fefd5ea512 000000000609dbf8 0000000000000000 : ntdll!ZwMapViewOfSection+0xa
000000000609dac0 000007fefe21c56b : 0000000000000000 0000000000000018 00000000040009e0 0000000000000b3c : KERNELBASE!MapViewOfFile+0x8d
000000000609db40 000007fefe21c3c3 : 0000000000000000 0000000000000000 0000000000000002 000007fefe630a00 : SHELL32!MapFileSegment+0x82
000000000609db80 000007fefe21c2b7 : 0000000004014100 0000000000000000 0000000000000000 0000000000000000 : SHELL32!GetExeTypeFromExeFile+0x11f
000000000609dc50 000007fefe2f9955 : 0ba00000000000fb 0000000000000000 0000000000000000 0000000000000000 : SHELL32!GetExeType+0x7d
000000000609dc80 000007fefe21dd43 : 0000000004083f00 0000000000000000 0000000004083f00 0000000004083f00 : SHELL32!IsCurrentProcessConsole+0x48
000000000609ded0 000007fefe21dc7b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : SHELL32!CExecuteApplication::_CreateProcess+0xa1
000000000609df70 000007fefe21db97 : 0000000000000001 0000000000000001 0000000000000000 0000000003f05840 : SHELL32!CExecuteApplication::_TryCreateProcess+0x126
000000000609dfd0 000007fefe21cd5e : 0000000003eb6a48 0000000004083f10 0000000000000000 0000000003f05840 : SHELL32!CExecuteApplication::_DoApplication+0x198
000000000609e030 000007fefe232350 : 0000000000000001 0000000000000000 0000000000000000 0000000003f05840 : SHELL32!CExecuteApplication::Execute+0x3e
000000000609e060 000007fefe23221f : 0000000003eb6a48 0000000000000000 0000000000000000 000000000609e230 : SHELL32!CExecuteAssociation::_DoCommand+0xb0
000000000609e0b0 000007fefe2340d8 : 0000000003f05850 0000000000000000 0000000000000000 000000000609e230 : SHELL32!CExecuteAssociation::Execute+0xbf
000000000609e110 000007fefe2342df : 0000000003eb6a30 000000000609e230 000000000000004e 000000007728c296 : SHELL32!CRegDataDrivenCommand::_Invoke+0x10d
000000000609e1a0 000007fefe234217 : 0000000000000000 0000000000000000 000000000609e530 0000000000000000 : SHELL32!CRegistryVerbsContextMenu::_Execute+0x77
000000000609e200 000007fefe2339ee : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : SHELL32!CRegistryVerbsContextMenu::InvokeCommand+0x102
000000000609e4f0 000007fefe233886 : 0000000000000000 000007fefe251eda 0000000000000000 0000000000030160 : SHELL32!HDXA_LetHandlerProcessCommandEx+0x144
000000000609e600 000007fefe208aad : 000000000609ecd0 00000000029e2ee0 000000000609ecd0 0000000000000000 : SHELL32!CDefFolderMenu::InvokeCommand+0x254
000000000609e970 000007fefe208909 : 0033004200320030 0039003000330030 00000000029e2ee0 00000000029e2ee0 : SHELL32!CShellLink::_InvokeDirect+0x204
000000000609ec90 000007fefe2087ff : 000000007725a808 00000000771703a3 00000000029e2f18 0000000000000000 : SHELL32!CShellLink::_ResolveAndInvoke+0x1de
000000000609ee30 000007fefe2339ee : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : SHELL32!CShellLink::InvokeCommand+0xe3
000000000609ef00 000007fefe233886 : 0000000000000000 0000000000000000 0000000000000000 00000000ffffffff : SHELL32!HDXA_LetHandlerProcessCommandEx+0x144
000000000609f010 000007fefe0be1b6 : 000000000000001f 000007fefe0b5027 0000000000000001 0000000000000000 : SHELL32!CDefFolderMenu::InvokeCommand+0x254
000000000609f380 000007fefe0be020 : 0000000000030160 0000000004001460 0000000000000000 0000000000000000 : SHLWAPI!SHInvokeCommandOnContextMenu2+0x1c8
000000000609f5a0 00000000ff1aac16 : 0000000000000000 0000000004001460 0000000000030160 000007fefddb81bd : SHLWAPI!SHInvokeCommandWithFlagsAndSite+0xa0
000000000609f630 00000000ff1a80f2 : 0000000000000000 0000000003f59cc0 00000000004892f6 0000000000000000 : Explorer!CTaskBand::CLauncherTask::_Launch+0x19a
000000000609f6c0 000007fefe0ac8ea : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : Explorer!CTaskBand::CLauncherTask::s_ThreadProc+0x12
000000000609f6f0 000000007716f56d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : SHLWAPI!WrapperThreadProc+0x19b
000000000609f7f0 00000000773a3281 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
000000000609f820 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!RtlDispatchException+122
fffff800`02905f62 410fb60c24 movzx ecx,byte ptr [r12]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: nt!RtlDispatchException+122

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600

FAILURE_BUCKET_ID: X64_0xA_VRF_nt!RtlDispatchException+122

BUCKET_ID: X64_0xA_VRF_nt!RtlDispatchException+122

Followup: MachineOwner

2

Looks like a memory corruption. Post your code and maybe someone will see
something.

Also, does your driver pass Driver Verifier?

-scott
OSR

wrote in message news:xxxxx@ntdev…

Hey guys,

Inaugural post here. I’m doing something very similar to:
http://www.osronline.com/showthread.cfm?link=244071
In my driver I have registered a Load Image notification callback with
PsSetLoadImageNotifyRoutine. Within the callback I am trying to get the
fully qualified name to do a file read on the specified image. I am trying
to get the name by doing a ObQueryNameString on the file object in the
IMAGE_INFO_EX. ObQueryNameString returns the proper name, however I am
getting an IRQL_NOT_LESS_OR_EQUAL at some time AFTER returning from the
callback. If I comment out the call to ObQueryNameString there is no
problem.

I did take a look at http://www.osronline.com/showThread.cfm?link=186317
but the solution didn’t seem as clean as this one (if it works). I also have
a hunch that I am somehow sidestepping the problem.

Bug Check info follows, lmk if code would be helpful. Any thoughts?

Thanks for the help.
Drew

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

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff80002befebf, 2, 0, fffff80002905f62}

Probably caused by : ntkrnlmp.exe ( nt!RtlDispatchException+122 )

Followup: MachineOwner

nt!DbgBreakPointWithStatus:
fffff800`028d0f60 cc int 3
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff80002befebf, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
chips which support this level of status)
Arg4: fffff80002905f62, address which referenced memory

Debugging Details:

READ_ADDRESS: fffff80002befebf

CURRENT_IRQL: 2

FAULTING_IP:
nt!RtlDispatchException+122
fffff800`02905f62 410fb60c24 movzx ecx,byte ptr [r12]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: explorer.exe

TRAP_FRAME: fffff88005780860 – (.trap 0xfffff88005780860)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8002fd90b0 rbx=0000000000000000 rcx=fffffa8002e4792b
rdx=0000000004860000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c1b2d5 rsp=fffff880057809f0 rbp=fffff88005780ca0
r8=fffff80002a51e80 r9=0000000000000100 r10=0000000000000080
r11=0000000000027a40 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe cy
nt! ?? ::NNGAKEGL::string'+0x2a839: fffff80002c1b2d5 e8aaf8c6ff call nt!KiCheckForKernelApcDelivery
(fffff800`0288ab84)
Resetting default scope

EXCEPTION_RECORD: fffff880057802e8 – (.exr 0xfffff880057802e8)
ExceptionAddress: fffff800028dd4d8 (nt!KiTryUnwaitThread+0x0000000000000028)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

LAST_CONTROL_TRANSFER: from fffff800029ce6d2 to fffff800028d0f60

STACK_TEXT:
fffff8800577e9e8 fffff800029ce6d2 : fffff80002befebf fffffa8002fd9060
0000000000000065 fffff80002917314 : nt!DbgBreakPointWithStatus
fffff8800577e9f0 fffff800029cf4be : 0000000000000003 0000000000000000
fffff80002913ee0 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffff8800577ea50 fffff800028d9004 : fffff8800577f248 fffffa80030b5a80
0000000000ffc000 fffff800029566a2 : nt!KeBugCheck2+0x71e
fffff8800577f120 fffff800028d8469 : 000000000000000a fffff80002befebf
0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
fffff8800577f160 fffff800028d70e0 : fffff8800577f298 00000000000002bf
0000000000000000 0000000000000100 : nt!KiBugCheckDispatch+0x69
fffff8800577f2a0 fffff80002905f62 : fffff80002befebf fffff8800577f478
fffff880057802e8 fffff80002867000 : nt!KiPageFault+0x260
fffff8800577f430 fffff800029131b5 : fffff880057802e8 fffff8800577fb40
fffff88000000000 fffffa8002e47900 : nt!RtlDispatchException+0x122
fffff8800577fb10 fffff800028d8542 : fffff880057802e8 cfe8cd8b49fff79a
fffff88005780390 0000000000000000 : nt!KiDispatchException+0x135
fffff880057801b0 fffff800028d6e4a : 0000000000000000 0000000000000000
0000000000000200 fffff98007063000 : nt!KiExceptionDispatch+0xc2
fffff88005780390 fffff800028dd4d8 : 0000000000000000 fffff98007062c60
fffffa8002e47920 fffff80002d7d5ec : nt!KiGeneralProtectionFault+0x10a
fffff88005780520 fffff80002953244 : fffff9800796cc60 0000000000000000
0000000000000000 fffffa8002e47920 : nt!KiTryUnwaitThread+0x28
fffff88005780580 fffff800028b592f : 8b4400001f93e990 fffff6fc000160d9
fffff80002a64400 fffff80000000000 : nt! ?? ::FNODOBFM::string'+0x3cb00 fffff88005780650 fffff8000288aba9 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDeliverApc+0x1d7 fffff880057806d0 fffff800028f4424 : 0000000000000000 0000000000000008 ffffffffffffffff 0000000000000080 : nt!KiCheckForKernelApcDelivery+0x25 fffff88005780700 fffff800028d6fee : 0000000000000008 fffffa8002fd9060 fffffa8002fd9000 0000000000000000 : nt!MmAccessFault+0x1844 fffff88005780860 fffff80002c1b2d5 : fffffa8002e5a920 fffffa8002e5cb30 fffff88005780b50 fffff88005780b48 : nt!KiPageFault+0x16e fffff880057809f0 fffff80002befebf : fffff80000000001 fffffa8002e5cb30 fffff88005780b50 0000000000000000 : nt! ?? ::NNGAKEGL::string’+0x2a839
fffff88005780ae0 fffff800028d8153 : 0000000000000b48 fffffa8002fd9060
000000000609dad8 0000000000000b01 : nt!NtMapViewOfSection+0x2be
fffff88005780bb0 00000000773c013a : 000007fefd5e22b1 0000000000000000
000007fefd5ea512 000000000609dbf8 : nt!KiSystemServiceCopyEnd+0x13
000000000609dab8 000007fefd5e22b1 : 0000000000000000 000007fefd5ea512
000000000609dbf8 0000000000000000 : ntdll!ZwMapViewOfSection+0xa
000000000609dac0 000007fefe21c56b : 0000000000000000 0000000000000018
00000000040009e0 0000000000000b3c : KERNELBASE!MapViewOfFile+0x8d
000000000609db40 000007fefe21c3c3 : 0000000000000000 0000000000000000
0000000000000002 000007fefe630a00 : SHELL32!MapFileSegment+0x82
000000000609db80 000007fefe21c2b7 : 0000000004014100 0000000000000000
0000000000000000 0000000000000000 : SHELL32!GetExeTypeFromExeFile+0x11f
000000000609dc50 000007fefe2f9955 : 0ba00000000000fb 0000000000000000
0000000000000000 0000000000000000 : SHELL32!GetExeType+0x7d
000000000609dc80 000007fefe21dd43 : 0000000004083f00 0000000000000000
0000000004083f00 0000000004083f00 : SHELL32!IsCurrentProcessConsole+0x48
000000000609ded0 000007fefe21dc7b : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 :
SHELL32!CExecuteApplication::_CreateProcess+0xa1
000000000609df70 000007fefe21db97 : 0000000000000001 0000000000000001
0000000000000000 0000000003f05840 :
SHELL32!CExecuteApplication::_TryCreateProcess+0x126
000000000609dfd0 000007fefe21cd5e : 0000000003eb6a48 0000000004083f10
0000000000000000 0000000003f05840 :
SHELL32!CExecuteApplication::_DoApplication+0x198
000000000609e030 000007fefe232350 : 0000000000000001 0000000000000000
0000000000000000 0000000003f05840 :
SHELL32!CExecuteApplication::Execute+0x3e
000000000609e060 000007fefe23221f : 0000000003eb6a48 0000000000000000
0000000000000000 000000000609e230 :
SHELL32!CExecuteAssociation::_DoCommand+0xb0
000000000609e0b0 000007fefe2340d8 : 0000000003f05850 0000000000000000
0000000000000000 000000000609e230 :
SHELL32!CExecuteAssociation::Execute+0xbf
000000000609e110 000007fefe2342df : 0000000003eb6a30 000000000609e230
000000000000004e 000000007728c296 :
SHELL32!CRegDataDrivenCommand::_Invoke+0x10d
000000000609e1a0 000007fefe234217 : 0000000000000000 0000000000000000
000000000609e530 0000000000000000 :
SHELL32!CRegistryVerbsContextMenu::_Execute+0x77
000000000609e200 000007fefe2339ee : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 :
SHELL32!CRegistryVerbsContextMenu::InvokeCommand+0x102
000000000609e4f0 000007fefe233886 : 0000000000000000 000007fefe251eda
0000000000000000 0000000000030160 :
SHELL32!HDXA_LetHandlerProcessCommandEx+0x144
000000000609e600 000007fefe208aad : 000000000609ecd0 00000000029e2ee0
000000000609ecd0 0000000000000000 :
SHELL32!CDefFolderMenu::InvokeCommand+0x254
000000000609e970 000007fefe208909 : 0033004200320030 0039003000330030
00000000029e2ee0 00000000029e2ee0 :
SHELL32!CShellLink::_InvokeDirect+0x204
000000000609ec90 000007fefe2087ff : 000000007725a808 00000000771703a3
00000000029e2f18 0000000000000000 :
SHELL32!CShellLink::_ResolveAndInvoke+0x1de
000000000609ee30 000007fefe2339ee : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : SHELL32!CShellLink::InvokeCommand+0xe3
000000000609ef00 000007fefe233886 : 0000000000000000 0000000000000000
0000000000000000 00000000ffffffff :
SHELL32!HDXA_LetHandlerProcessCommandEx+0x144
000000000609f010 000007fefe0be1b6 : 000000000000001f 000007fefe0b5027
0000000000000001 0000000000000000 :
SHELL32!CDefFolderMenu::InvokeCommand+0x254
000000000609f380 000007fefe0be020 : 0000000000030160 0000000004001460
0000000000000000 0000000000000000 :
SHLWAPI!SHInvokeCommandOnContextMenu2+0x1c8
000000000609f5a0 00000000ff1aac16 : 0000000000000000 0000000004001460
0000000000030160 000007fefddb81bd :
SHLWAPI!SHInvokeCommandWithFlagsAndSite+0xa0
000000000609f630 00000000ff1a80f2 : 0000000000000000 0000000003f59cc0
00000000004892f6 0000000000000000 :
Explorer!CTaskBand::CLauncherTask::_Launch+0x19a
000000000609f6c0 000007fefe0ac8ea : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 :
Explorer!CTaskBand::CLauncherTask::s_ThreadProc+0x12
000000000609f6f0 000000007716f56d : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : SHLWAPI!WrapperThreadProc+0x19b
000000000609f7f0 00000000773a3281 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
000000000609f820 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!RtlDispatchException+122
fffff800`02905f62 410fb60c24 movzx ecx,byte ptr [r12]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: nt!RtlDispatchException+122

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600

FAILURE_BUCKET_ID: X64_0xA_VRF_nt!RtlDispatchException+122

BUCKET_ID: X64_0xA_VRF_nt!RtlDispatchException+122

Followup: MachineOwner

3

I’ve been running it with driver verifier and it isn’t reporting anything afoot (if that’s what you mean).

if (ImageInfo->ExtendedInfoPresent)
{
UNICODE_STRING *fullImagePath;
IMAGE_INFO_EX *ImageInfoEx = CONTAINING_RECORD(ImageInfo, IMAGE_INFO_EX, ImageInfo);
unsigned long return_length;
OBJECT_NAME_INFORMATION *objNameInfo = NULL;

ObQueryNameString(ImageInfoEx->FileObject, NULL, 0, &return_length);
objNameInfo = ExAllocatePoolWithTag(NonPagedPool, return_length, PROCESS_POOL_TAG);

if (objNameInfo)
{
ObQueryNameString(ImageInfoEx->FileObject, objNameInfo, return_length, &return_length);
fullImagePath = (UNICODE_STRING *)objNameInfo;
KdPrint((“Full image path is: %wZ\n”, fullImagePath));
ExFreePool(fullImagePath);
}
}

4

Does second ObQueryNameString succeed?

Try to pass an address of bare UNICODE_STRING into the first call. The function may not support NULL for that argument.

5

  1. The second always succeeds, I left out the error checking code.

  2. I think you are on to something. If I pass a zeroed out struct in the first call, it crashes in the normal way, but if I remove the first call and instead pass a preallocated buffer to the second call I don’t get the bugcheck. Seems that it is doing something that isn’t kosher with that pointer.

Drew

6

> I’ve been running it with driver verifier and it isn’t reporting anything

afoot (if that’s what you mean).

if (ImageInfo->ExtendedInfoPresent)
{
UNICODE_STRING *fullImagePath;
IMAGE_INFO_EX *ImageInfoEx = CONTAINING_RECORD(ImageInfo, IMAGE_INFO_EX,
ImageInfo);
unsigned long return_length;
OBJECT_NAME_INFORMATION *objNameInfo = NULL;

ObQueryNameString(ImageInfoEx->FileObject, NULL, 0, &return_length);

What if this fails? You are not checking to see if the
objNameInfo->Name.Length has been set to 0.

objNameInfo = ExAllocatePoolWithTag(NonPagedPool, return_length,
PROCESS_POOL_TAG);

if (objNameInfo)
{
ObQueryNameString(ImageInfoEx->FileObject, objNameInfo, return_length,
&return_length);
fullImagePath = (UNICODE_STRING *)objNameInfo;

Why do you need a variable and a cast here? objeNameInfo->Name will
handle it without the gratuitous casting or unnecessary variable. Is
there some reason to have done this very peculiar thing?

KdPrint((“Full image path is: %wZ\n”, fullImagePath));
ExFreePool(fullImagePath);

Do you know if you actually own the UNICODE_STRING contents? If you are
freeing it, and someone else owns it, you are in trouble. Given that the
address you allocated was stored in objNameInfo, why is it that you
presume that fullImagePath == objNameInfo? If they ARE equal, this should
be thought of as an accident, and depending on this to always be truly is
very dangers.

Note that if this is an offset into the structure, that is, if the
ObjQueryNameString wants a structure of the form

OOOOsssssssssssssssssssss

Where the string contents ssssss are appended to the basic
OBJECT_NAME_INFORMATION structure OOO, then freeing the string is insane.
You actually don’t own the string buffer; the OBJECT_NAME_INFORMATION
structure owns the string contents, and you must free that, and only that.
See above contents about why you are freeing something completely
different from what you allocated (and if they are not completely
different, which you determine by the debugger, that is just a transient
accident and not something you are allowed to depend on)

}
}

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

> What if this fails? You are not checking to see if the objNameInfo->Name.Length has been set to 0.

I check the return NT_STATUS.

Why do you need a variable and a cast here? objNameInfo->Name will handle it without the gratuitous casting or unnecessary variable. Is there some reason to have done this very peculiar thing?

You are right, I *should* be doing objNameInfo->Name. But I did the cast to make it obvious that I was expecting the Name field of objNameInfo to be the first field in the struct (which I agree is terribly poor style) because I free it in the calling function (again poor style). The proper way to do this would be to return objNameInfo->Name and have a dedicated free function that uses the CONTAINING_RECORD macro on the Name field to free the objNameInfo struct.

Also see my previous post regarding the “fix” I found.

Drew

8

The first call you make has to be with a valid OBJECT_NAME_INFORMATION
structure on the stack. This will then “overflow” and the returned length
with tell you the size of the buffer.

Something like this (abbreviated version of some existing code I have):

NTSTATUS status;
ULONG objectNameLen;
POBJECT_NAME_INFORMATION tempNameInfo;
OBJECT_NAME_INFORMATION nameInfoStack;

status = ObQueryNameString(Object,
&nameInfoStack,
sizeof(nameInfoStack),
&objectNameLen);

// Returned status value has changed since WIn2k RTM,
// check for both
if ((status != STATUS_BUFFER_OVERFLOW) &&
(status != STATUS_INFO_LENGTH_MISMATCH)) {

return status;

}

tempNameInfo =
(POBJECT_NAME_INFORMATION)ExAllocatePoolWithTag(PagedPool,
objectNameLen,
QUERY_OBJECT_TAG);

if (!tempNameInfo) {
return STATUS_INSUFFICIENT_RESOURCES;
}

status = ObQueryNameString(Object,
tempNameInfo,
objectNameLen,
&objectNameLen);

-scott
OSR

wrote in message news:xxxxx@ntdev…

  1. The second always succeeds, I left out the error checking code.

  2. I think you are on to something. If I pass a zeroed out struct in the
    first call, it crashes in the normal way, but if I remove the first call and
    instead pass a preallocated buffer to the second call I don’t get the
    bugcheck. Seems that it is doing something that isn’t kosher with that
    pointer.

Drew

9

>> What if this fails? You are not checking to see if the

> objNameInfo->Name.Length has been set to 0.

I check the return NT_STATUS.

> Why do you need a variable and a cast here? objNameInfo->Name will
> handle it without the gratuitous casting or unnecessary variable. Is
> there some reason to have done this very peculiar thing?

You are right, I *should* be doing objNameInfo->Name. But I did the cast
to make it obvious that I was expecting the Name field of objNameInfo to
be the first field in the struct (which I agree is terribly poor style)
because I free it in the calling function (again poor style). The proper
way to do this would be to return objNameInfo->Name and have a dedicated
free function that uses the CONTAINING_RECORD macro on the Name field to
free the objNameInfo struct.

That sounds risky also. return a pointer to the thing you allocated.
joe

Also see my previous post regarding the “fix” I found.

Drew

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer