Invalid Kernel Handle with Parameter 2 Garbage

NTDEV
1

All,

Platform: Win2k8R2, Multi core CPU

We have a volume filter which is assisted by a user mode service. This duo
has a few meta data files which are maintained by the driver and used by the
service.

This driver has been put to high stress before, where these meta data files
are created and accessed at very high frequencies and updated too.
The driver opens a file and passes on the Kernel mode handle to the user for
book keeping. When ever the user mode service needs to operate on the files,
it send the handle down to the driver. The user mode code *never* uses this
handle directly.

On win2k8R2 we are running verifier tests on the duo. We encounter a strange
crash. Verifier options enabled are:
0: kd> !verifier

Verify Level 804 … enabled options are:
Inject random low-resource API failures
Miscellaneous checks enabled

Summary of All Verifier Statistics

RaiseIrqls 0x0
AcquireSpinLocks 0x0
Synch Executions 0x0
Trims 0x0

Pool Allocations Attempted 0x1a5e
Pool Allocations Succeeded 0x1a5e
Pool Allocations Succeeded SpecialPool 0xb8
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x0 for 00000000 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x0 for 00000000 bytes

Only these two unique combinations make the crash happen. QA has tried all
other combinations, and we are sure. Even, these two when enabled
independently, doesnt make it crash.

The files are opened using the IoCreateFileSpecifyDeviceObjectHint API.
Object attributes are:

InitializeObjectAttributes(&oa,
&FileName,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
NULL,
NULL);

FileAttribs = FILE_ATTRIBUTE_NORMAL;
// set up the “share mode” we need to allow other clients to read or write
the target file, but not to delete it
ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE;
// set up the “open mode” we need for synchronous write-through un-buffered
file access to our workfiles
// NOTES: a) we do not need or want the system to cache our file data – we
want direct, immediate access to our file data on disk;
// b) our use of “no intermediate buffering” requires all read/write
ops to be SECTOR-MULTIPLE-ALIGNED in the file on disk;
// c) “no intermediate buffering” also requires a further alignment
of the data buffers used by this driver for read/write ops
CreateOptions = FILE_WRITE_THROUGH | FILE_RANDOM_ACCESS |
FILE_NO_INTERMEDIATE_BUFFERING | FILE_SYNCHRONOUS_IO_NONALERT;
BOOLEAN bFileBeingCreated = (CreateDisposition & FILE_CREATE) ||
(CreateDisposition & FILE_SUPERSEDE) ||
(CreateDisposition & FILE_OVERWRITE) ||
(CreateDisposition & FILE_OVERWRITE_IF);
if(bFileBeingCreated)
{
FileAttribs = FileAttribs|FILE_ATTRIBUTE_SYSTEM;
}

status = IoCreateFileSpecifyDeviceObjectHint(
&hFile,
DesiredAccess | SYNCHRONIZE,
&oa,
&IoStatus,
AllocationSize,
FileAttribs,
ShareAccess,
CreateDisposition,
CreateOptions,
0,
0,
CreateFileTypeNone,
NULL,
IO_IGNORE_SHARE_ACCESS_CHECK,
FsVolumeDeviceObject
);

after a while we get a blue screen saying that NtClose tried closing an
invalid Kernel handle. The handle value shown is actually an user mode
handle value (the high bit cleared) and as you can see (below) the other
parameters of the dump are gibberish. Also, the line where where it shows
the crash in the code is actually a ZwWriteFile call. Please note, that the
handle passed to ZwWriteFile through pIOParams->hFile is 0xffffffff`80000788
and ARG1 has the bits cleared.

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

INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code (server, redirector, other driver, etc.)
attempts to close a handle that is not a valid handle.
Arguments:
Arg1: 0000000000000788, The handle that NtClose was called with.
Arg2: fffff8a000001a40,
Arg3: fffff8a0014bbe20
Arg4: 0000000000000001

Debugging Details:

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x93

PROCESS_NAME: MyProc64x.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800017c3d92 to fffff800016d4490

STACK_TEXT:
fffff88004c926d8 fffff800017c3d92 : 0000000000000788 fffffa8004ffa060
0000000000000065 fffff80001718178 : nt!RtlpBreakWithStatusInstruction
fffff88004c926e0 fffff800017c4b7e : fffff8a000000003 0000000000000000
fffff800017189d0 0000000000000093 : nt!KiBugCheckDebugBreak+0x12
fffff88004c92740 fffff800016dc744 : 0000000000000000 fffff88001969b9d
0000000000000788 0000000000000000 : nt!KeBugCheck2+0x71e
fffff88004c92e10 fffff800019364db : 0000000000000093 0000000000000788
fffff8a000001a40 fffff8a0014bbe20 : nt!KeBugCheckEx+0x104
fffff88004c92e50 fffff800016db8d3 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt! ?? ::NNGAKEGL::string'+0x54c34 fffff88004c92f50 fffff800016d7e70 : fffff80001b6709e fffff88004c935e0 fffff80001b74d3d fffffa800462dc60 : nt!KiSystemServiceCopyEnd+0x13 fffff88004c93158 fffff80001b6709e : fffff88004c935e0 fffff80001b74d3d fffffa800462dc60 fffff88004c93c60 : nt!KiServiceLinkage fffff88004c93160 fffff88001969b9d : ffffffff80000788 fffffa800462dc60 fffff88004c93c60 fffffa8004903030 : nt!VfZwWriteFile+0xce fffff88004c931e0 fffff8800196505d : fffffa8004903030 fffffa8005102acc fffff88004c93870 fffff88004c93844 : MyDrv!MyDrvIO+0xead fffff88004c937f0 fffff88001965c34 : fffffa8004903030 fffffa800462dc60 fffff88004c938e0 fffff88004c938e0 : MyDrv!MyDrvIoCtl+0x6fd fffff88004c938d0 fffff80001b7f750 : fffffa8004903030 fffffa800462dc60 fffffa800462dc60 0000000000000000 : MyDrv!MyDrvDispatchDeviceControl+0x1f4@ 962] fffff88004c93970 fffff800019f6f97 : fffffa80045ee7d0 fffff88004c93c60 fffffa80045ee7d0 fffffa800462dc60 : nt!IovCallDriver+0xa0 fffff88004c939d0 fffff800019f77f6 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607 fffff88004c93b00 fffff800016db8d3 : fffffa8004f86060 0000000000000001 fffffa8004ffa060 fffff800019d3a34 : nt!NtDeviceIoControlFile+0x56 fffff88004c93b70 000000007740138a : 000007fefd5ab939 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 000000000012d528 000007fefd5ab939 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!NtDeviceIoControlFile+0xa 000000000012d530 00000000772a683f : 0000000090ff2818 000000000012ece0 0000000000000000 00000001400189cb : KERNELBASE!DeviceIoControl+0x75 000000000012d5a0 0000000140016563 : 0000000000000000 000000000012ece0 0000000000000000 000000000012ece0 : kernel32!DeviceIoControlImplementation+0x7f 000000000012d5f0 000000014000ef67 : 000000000012dee0 0000000000000000 0000000190ff2818 0000000000552250 : MyProc64x!MyProc64xDeviceIoControl+0x443 @ 274] <stack trimmed><br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP:<br>MyDrv!MyDrvIO+ead<br>fffff88001969b9d 89842488000000 mov dword ptr [rsp+88h],eax

FAULTING_SOURCE_CODE:
status = ZwWriteFile(pIOParams->hFile,
NULL,
NULL,
NULL,
1149: &IoStatus,
1150: pBuff,
1151: MyDrv_FILESIZE_CHUNK,
1152: &Pos,
> 1153: NULL);
1154:
1155: Pos.QuadPart += MyDrv_FILESIZE_CHUNK;
1156:
1157: if (!NT_SUCCESS(status)||!NT_SUCCESS(IoStatus.Status))
1158: {

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: MyDrv!MyDrvIO+ead

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: MyDrv

IMAGE_NAME: MyDrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e23de0b

FAILURE_BUCKET_ID: X64_0x93_VRF_MyDrv!MyDrvIO+ead

BUCKET_ID: X64_0x93_VRF_MyDrv!MyDrvIO+ead

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

I could really use some help with this…

Amit

2

I suspect that your handle is probably closed at this point. What does !handle return for the handle value?

Are you synchronizing all code paths that use your handle against all code paths that close the handle?

  • S (Msft)

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of A B
Sent: Monday, July 18, 2011 8:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage

All,

Platform: Win2k8R2, Multi core CPU

We have a volume filter which is assisted by a user mode service. This duo has a few meta data files which are maintained by the driver and used by the service.

This driver has been put to high stress before, where these meta data files are created and accessed at very high frequencies and updated too.
The driver opens a file and passes on the Kernel mode handle to the user for book keeping. When ever the user mode service needs to operate on the files, it send the handle down to the driver. The user mode code *never* uses this handle directly.

On win2k8R2 we are running verifier tests on the duo. We encounter a strange crash. Verifier options enabled are:

[snip - exceeding OSR maximum message size]

Only these two unique combinations make the crash happen. QA has tried all other combinations, and we are sure. Even, these two when enabled independently, doesnt make it crash.

The files are opened using the IoCreateFileSpecifyDeviceObjectHint API. Object attributes are:

[snip - exceeding OSR maximum message size]

after a while we get a blue screen saying that NtClose tried closing an invalid Kernel handle. The handle value shown is actually an user mode handle value (the high bit cleared) and as you can see (below) the other parameters of the dump are gibberish. Also, the line where where it shows the crash in the code is actually a ZwWriteFile call. Please note, that the handle passed to ZwWriteFile through pIOParams->hFile is 0xffffffff`80000788 and ARG1 has the bits cleared.

[snip - exceeding OSR maximum message size]
\

3

Skywing,

I thought so too, The stack trace posted is currently with a test
application, which is single threaded. This was written to reproduce the
issue. Also since all calls to open/edit/close are throug the driver and the
IOCTL is called in sync mode, so the handle can’t be closed before.

Also. why does the stack trace point to NtClose where as windbg confidently
points to WriteFile. The local variables in the context seem to be valid.

Also, is it the right behavior where in NtClose the high bit is turned off
from the handle?

0: kd> !handle 788

PROCESS fffffa8004f86060
SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0
DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32.
Image: MyProc64x.exe

Handle table at fffff8a001c79000 with 32 entries in use

Invalid handle: 0x788

0: kd> !handle 0xffffffff`80000788

PROCESS fffffa8004f86060
SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0
DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32.
Image: MyProc64x.exe

Kernel handle table at fffff8a0014b9000 with 475 entries in use

80000788: free handle, Entry address fffff8a0014bbe20, Next Entry
0000000000000778

I tried attaching appverifier too, but it didnt give any clues.

I tried enabling htrace, but it doesnt seem to work, I cant figure out why
not.

Also, in the second output, why does it say Next Entry 0000000000000778 when
in the previous output it said invalid handle value the same…

On Mon, Jul 18, 2011 at 9:03 PM, Skywing wrote:

> I suspect that your handle is probably closed at this point. What does
> !handle return for the handle value?
>
>
>
> Are you synchronizing all code paths that use your handle against all code
> paths that close the handle?
>
> ****
>
> - S (Msft)
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of A B
> Sent: Monday, July 18, 2011 8:10 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage
>
> ****
>
> All,
>
>
>
> Platform: Win2k8R2, Multi core CPU
>
> ****
>
> We have a volume filter which is assisted by a user mode service. This duo
> has a few meta data files which are maintained by the driver and used by the
> service.
>
>
>
> This driver has been put to high stress before, where these meta data files
> are created and accessed at very high frequencies and updated too.
>
> The driver opens a file and passes on the Kernel mode handle to the user
> for book keeping. When ever the user mode service needs to operate on the
> files, it send the handle down to the driver. The user mode code never
> uses this handle directly.
>
>
>
> On win2k8R2 we are running verifier tests on the duo. We encounter a
> strange crash. Verifier options enabled are:
>
> ****
>
> [snip ? exceeding OSR maximum message size]
>
>
>
> Only these two unique combinations make the crash happen. QA has tried all
> other combinations, and we are sure. Even, these two when enabled
> independently, doesnt make it crash.
>
> ****
>
> The files are opened using the IoCreateFileSpecifyDeviceObjectHint API.
> Object attributes are:
>
> **
>
> [snip ? exceeding OSR maximum message size]
>
> ****
>
> ****
>
> after a while we get a blue screen saying that NtClose tried closing an
> invalid Kernel handle. The handle value shown is actually an user mode
> handle value (the high bit cleared) and as you can see (below) the other
> parameters of the dump are gibberish. Also, the line where where it shows
> the crash in the code is actually a ZwWriteFile call. Please note, that the
> handle passed to ZwWriteFile through pIOParams->hFile is 0xffffffff`80000788
> and ARG1 has the bits cleared.
>
> **
>
> [snip ? exceeding OSR maximum message size]**
>
> \ ****
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

- ab

4

The stack trace doesn’t point to NtClose. The bug check description text is (mostly) static and in this case is slightly misleading - but without verifier you would typically just see this checked in NtClose versus other functions.

  • S

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of A B
Sent: Monday, July 18, 2011 8:58 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage

Skywing,

I thought so too, The stack trace posted is currently with a test application, which is single threaded. This was written to reproduce the issue. Also since all calls to open/edit/close are throug the driver and the IOCTL is called in sync mode, so the handle can’t be closed before.

Also. why does the stack trace point to NtClose where as windbg confidently points to WriteFile. The local variables in the context seem to be valid.

Also, is it the right behavior where in NtClose the high bit is turned off from the handle?

0: kd> !handle 788

PROCESS fffffa8004f86060
SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0
DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32.
Image: MyProc64x.exe

Handle table at fffff8a001c79000 with 32 entries in use

Invalid handle: 0x788

0: kd> !handle 0xffffffff`80000788

PROCESS fffffa8004f86060
SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0
DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32.
Image: MyProc64x.exe

Kernel handle table at fffff8a0014b9000 with 475 entries in use

80000788: free handle, Entry address fffff8a0014bbe20, Next Entry 0000000000000778

I tried attaching appverifier too, but it didnt give any clues.

I tried enabling htrace, but it doesnt seem to work, I cant figure out why not.

Also, in the second output, why does it say Next Entry 0000000000000778 when in the previous output it said invalid handle value the same…
On Mon, Jul 18, 2011 at 9:03 PM, Skywing > wrote:
I suspect that your handle is probably closed at this point. What does !handle return for the handle value?

Are you synchronizing all code paths that use your handle against all code paths that close the handle?

- S (Msft)

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of A B
Sent: Monday, July 18, 2011 8:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage

All,

Platform: Win2k8R2, Multi core CPU

We have a volume filter which is assisted by a user mode service. This duo has a few meta data files which are maintained by the driver and used by the service.

This driver has been put to high stress before, where these meta data files are created and accessed at very high frequencies and updated too.
The driver opens a file and passes on the Kernel mode handle to the user for book keeping. When ever the user mode service needs to operate on the files, it send the handle down to the driver. The user mode code never uses this handle directly.

On win2k8R2 we are running verifier tests on the duo. We encounter a strange crash. Verifier options enabled are:

[snip - exceeding OSR maximum message size]

Only these two unique combinations make the crash happen. QA has tried all other combinations, and we are sure. Even, these two when enabled independently, doesnt make it crash.

The files are opened using the IoCreateFileSpecifyDeviceObjectHint API. Object attributes are:

[snip - exceeding OSR maximum message size]

after a while we get a blue screen saying that NtClose tried closing an invalid Kernel handle. The handle value shown is actually an user mode handle value (the high bit cleared) and as you can see (below) the other parameters of the dump are gibberish. Also, the line where where it shows the crash in the code is actually a ZwWriteFile call. Please note, that the handle passed to ZwWriteFile through pIOParams->hFile is 0xffffffff`80000788 and ARG1 has the bits cleared.

[snip - exceeding OSR maximum message size]
<br>
—
NTDEV is sponsored by OSR

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

–

- ab
— NTDEV is sponsored by OSR 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</mailto:xxxxx></mailto:xxxxx>

5

i treid the ‘u’ command on the seemingly 64 addresses given in parameter 2
and 3 t osee if it is valid code, didn’t look like it. Then i tried db on
them, and it seemed some where inside a registry hive, ofcourse I could be
wrong, bu the strings that came up in that vicinity looked like registery
keys and values…

here is the output of handle

0: kd> !handle

PROCESS fffffa8004f86060
SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0
DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32.
Image: MyProc64x.exe

Handle table at fffff8a001c79000 with 32 entries in use

0004: Object: fffff8a001c72900 GrantedAccess: 00000009 Entry:
fffff8a001c79010
Object: fffff8a001c72900 Type: (fffffa80040fca50) Key
ObjectHeader: fffff8a001c728d0 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name:
\REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE
EXECUTION OPTIONS

0008: Object: fffffa800512c610 GrantedAccess: 00100001 Entry:
fffff8a001c79020
Object: fffffa800512c610 Type: (fffffa80040ed210) File
ObjectHeader: fffffa800512c5e0 (new version)
HandleCount: 1 PointerCount: 1

000c: Object: fffff8a004dceeb0 GrantedAccess: 00000003 Entry:
fffff8a001c79030
Object: fffff8a004dceeb0 Type: (fffffa8004007af0) Directory
ObjectHeader: fffff8a004dcee80 (new version)
HandleCount: 27 PointerCount: 65
Directory Object: fffff8a000004bf0 Name: KnownDlls

0010: Object: fffffa80045e8f20 GrantedAccess: 00100020 Entry:
fffff8a001c79040
Object: fffffa80045e8f20 Type: (fffffa80040ed210) File
ObjectHeader: fffffa80045e8ef0 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \MyProc64x\win64-x64_release
{HarddiskVolume4}

0014: Object: fffffa8004ef46a0 GrantedAccess: 001f0003 Entry:
fffff8a001c79050
Object: fffffa8004ef46a0 Type: (fffffa80040e9570) Event
ObjectHeader: fffffa8004ef4670 (new version)
HandleCount: 3 PointerCount: 3

0018: Object: fffffa80045efe60 GrantedAccess: 001f0001 Entry:
fffff8a001c79060
Object: fffffa80045efe60 Type: (fffffa80041008a0) ALPC Port
ObjectHeader: fffffa80045efe30 (new version)
HandleCount: 1 PointerCount: 3

001c: Object: fffffa80045fc6f0 GrantedAccess: 001f0001 Entry:
fffff8a001c79070
Object: fffffa80045fc6f0 Type: (fffffa80041008a0) ALPC Port
ObjectHeader: fffffa80045fc6c0 (new version)
HandleCount: 1 PointerCount: 3

0020: Object: fffff8a001cb5ab0 GrantedAccess: 00020019 Entry:
fffff8a001c79080
Object: fffff8a001cb5ab0 Type: (fffffa80040fca50) Key
ObjectHeader: fffff8a001cb5a80 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name:
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\CONTROL\NLS\SORTING\VERSIONS

0024: Object: fffffa80050b0150 GrantedAccess: 001f0001 Entry:
fffff8a001c79090
Object: fffffa80050b0150 Type: (fffffa80040eb570) Mutant
ObjectHeader: fffffa80050b0120 (new version)
HandleCount: 1 PointerCount: 1

0028: Object: fffff8a001bcb550 GrantedAccess: 000f003f Entry:
fffff8a001c790a0
Object: fffff8a001bcb550 Type: (fffffa80040fca50) Key
ObjectHeader: fffff8a001bcb520 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \REGISTRY\MACHINE

002c: Object: fffffa8005084960 GrantedAccess: 001f0003 Entry:
fffff8a001c790b0
Object: fffffa8005084960 Type: (fffffa80040e9570) Event
ObjectHeader: fffffa8005084930 (new version)
HandleCount: 1 PointerCount: 1

0030: Object: fffff8a001cb0be0 GrantedAccess: 00000001 Entry:
fffff8a001c790c0
Object: fffff8a001cb0be0 Type: (fffffa80040fca50) Key
ObjectHeader: fffff8a001cb0bb0 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name:
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\CONTROL\SESSION MANAGER

0034: Object: fffffa8005032aa0 GrantedAccess: 001f0003 Entry:
fffff8a001c790d0
Object: fffffa8005032aa0 Type: (fffffa80040e9570) Event
ObjectHeader: fffffa8005032a70 (new version)
HandleCount: 1 PointerCount: 1

0038: Object: fffffa8004f78060 GrantedAccess: 001f0003 Entry:
fffff8a001c790e0
Object: fffffa8004f78060 Type: (fffffa80040e9570) Event
ObjectHeader: fffffa8004f78030 (new version)
HandleCount: 1 PointerCount: 1

003c: Object: fffffa80046047c0 GrantedAccess: 001f0003 Entry:
fffff8a001c790f0
Object: fffffa80046047c0 Type: (fffffa80040e9570) Event
ObjectHeader: fffffa8004604790 (new version)
HandleCount: 1 PointerCount: 1

0040: Object: fffffa8004ebe180 GrantedAccess: 00000804 Entry:
fffff8a001c79100
Object: fffffa8004ebe180 Type: (fffffa80040fe7c0) EtwRegistration
ObjectHeader: fffffa8004ebe150 (new version)
HandleCount: 1 PointerCount: 1

0044: Object: fffffa80051fb4f0 GrantedAccess: 00000804 Entry:
fffff8a001c79110
Object: fffffa80051fb4f0 Type: (fffffa80040fe7c0) EtwRegistration
ObjectHeader: fffffa80051fb4c0 (new version)
HandleCount: 1 PointerCount: 1

0048: Object: fffffa8005243cf0 GrantedAccess: 001f0003 Entry:
fffff8a001c79120
Object: fffffa8005243cf0 Type: (fffffa80040e9570) Event
ObjectHeader: fffffa8005243cc0 (new version)
HandleCount: 1 PointerCount: 1

004c: Object: fffffa8004ffa060 GrantedAccess: 001fffff Entry:
fffff8a001c79130
Object: fffffa8004ffa060 Type: (fffffa8004008a50) Thread
ObjectHeader: fffffa8004ffa030 (new version)
HandleCount: 2 PointerCount: 3

0050: Object: fffffa800504b1b0 GrantedAccess: 001f0001 Entry:
fffff8a001c79140
Object: fffffa800504b1b0 Type: (fffffa80041008a0) ALPC Port
ObjectHeader: fffffa800504b180 (new version)
HandleCount: 1 PointerCount: 1

0054: Object: fffff8a001cbf060 GrantedAccess: 000f0003 Entry:
fffff8a001c79150
Object: fffff8a001cbf060 Type: (fffffa80040edde0) KeyedEvent
ObjectHeader: fffff8a001cbf030 (new version)
HandleCount: 1 PointerCount: 1

0058: Object: fffffa8004a78500 GrantedAccess: 001f0003 Entry:
fffff8a001c79160
Object: fffffa8004a78500 Type: (fffffa80040ed360) IoCompletion
ObjectHeader: fffffa8004a784d0 (new version)
HandleCount: 1 PointerCount: 2

005c: Object: fffffa8004606dc0 GrantedAccess: 000f00ff Entry:
fffff8a001c79170
Object: fffffa8004606dc0 Type: (fffffa80040ed9f0) TpWorkerFactory
ObjectHeader: fffffa8004606d90 (new version)
HandleCount: 4 PointerCount: 4

0060: Object: fffffa8004606dc0 GrantedAccess: 000f00ff Entry:
fffff8a001c79180
Object: fffffa8004606dc0 Type: (fffffa80040ed9f0) TpWorkerFactory
ObjectHeader: fffffa8004606d90 (new version)
HandleCount: 4 PointerCount: 4

0064: Object: fffffa8004606dc0 GrantedAccess: 000f00ff Entry:
fffff8a001c79190
Object: fffffa8004606dc0 Type: (fffffa80040ed9f0) TpWorkerFactory
ObjectHeader: fffffa8004606d90 (new version)
HandleCount: 4 PointerCount: 4

0068: Object: fffffa8004606dc0 GrantedAccess: 000f00ff Entry:
fffff8a001c791a0
Object: fffffa8004606dc0 Type: (fffffa80040ed9f0) TpWorkerFactory
ObjectHeader: fffffa8004606d90 (new version)
HandleCount: 4 PointerCount: 4

006c: Object: fffffa80045ae4e0 GrantedAccess: 00100002 Entry:
fffff8a001c791b0
Object: fffffa80045ae4e0 Type: (fffffa80040ed080) Timer
ObjectHeader: fffffa80045ae4b0 (new version)
HandleCount: 1 PointerCount: 2

0070: Object: fffffa8005107ad0 GrantedAccess: 001f0003 Entry:
fffff8a001c791c0
Object: fffffa8005107ad0 Type: (fffffa80040ed080) Timer
ObjectHeader: fffffa8005107aa0 (new version)
HandleCount: 1 PointerCount: 2

0074: Object: fffffa80051fa260 GrantedAccess: 001fffff Entry:
fffff8a001c791d0
Object: fffffa80051fa260 Type: (fffffa8004008a50) Thread
ObjectHeader: fffffa80051fa230 (new version)
HandleCount: 2 PointerCount: 3

0078: Object: fffffa80051fa260 GrantedAccess: 001fffff Entry:
fffff8a001c791e0
Object: fffffa80051fa260 Type: (fffffa8004008a50) Thread
ObjectHeader: fffffa80051fa230 (new version)
HandleCount: 2 PointerCount: 3

007c: Object: fffffa8004f09af0 GrantedAccess: 00100002 Entry:
fffff8a001c791f0
Object: fffffa8004f09af0 Type: (fffffa80040ed080) Timer
ObjectHeader: fffffa8004f09ac0 (new version)
HandleCount: 1 PointerCount: 2

0080: Object: fffffa80045ee7d0 GrantedAccess: 00100080 Entry:
fffff8a001c79200
Object: fffffa80045ee7d0 Type: (fffffa80040ed210) File
ObjectHeader: fffffa80045ee7a0 (new version)
HandleCount: 1 PointerCount: 3

On Mon, Jul 18, 2011 at 9:31 PM, Skywing wrote:

> The stack trace doesn?t point to NtClose. The bug check description text
> is (mostly) static and in this case is slightly misleading ? but without
> verifier you would typically just see this checked in NtClose versus other
> functions.
>
>
>
> - S
>
> ****
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of A B
> Sent: Monday, July 18, 2011 8:58 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage
>
>
>
> Skywing,
>
> ****
>
> I thought so too, The stack trace posted is currently with a test
> application, which is single threaded. This was written to reproduce the
> issue. Also since all calls to open/edit/close are throug the driver and the
> IOCTL is called in sync mode, so the handle can’t be closed before.
>
> **
>
> Also. why does the stack trace point to NtClose where as windbg confidently
> points to WriteFile. The local variables in the context seem to be valid.
>
>
> ****
>
> Also, is it the right behavior where in NtClose the high bit is turned off
> from the handle?
>
>
>
> 0: kd> !handle 788
>
> ****
>
> PROCESS fffffa8004f86060
>
> SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0
>
> DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32.
>
>
> Image: MyProc64x.exe
>
>
>
> Handle table at fffff8a001c79000 with 32 entries in use
>
> ****
>
> Invalid handle: 0x788
>
>
>
> **
>
> 0: kd> !handle 0xffffffff80000788**** <br>&gt;<br>&gt; **** <br>&gt;<br>&gt; PROCESS fffffa8004f86060 ****<br>&gt;<br>&gt; SessionId: 1 Cid: 03d4 Peb: 7fffffd8000 ParentCid: 04c0**** <br>&gt;<br>&gt; DirBase: 108a57000 ObjectTable: fffff8a001c948b0 HandleCount: 32. **<br>&gt;** <br>&gt;<br>&gt; Image: MyProc64x.exe ****<br>&gt;<br>&gt;** **<br>&gt;<br>&gt; Kernel handle table at fffff8a0014b9000 with 475 entries in use**** <br>&gt;<br>&gt; **** <br>&gt;<br>&gt; 80000788: free handle, Entry address fffff8a0014bbe20, Next Entry<br>&gt; 0000000000000778 ****<br>&gt;<br>&gt;** **<br>&gt;<br>&gt;** **<br>&gt;<br>&gt; I tried attaching appverifier too, but it didnt give any clues.**** <br>&gt;<br>&gt; **** <br>&gt;<br>&gt; I tried enabling htrace, but it doesnt seem to work, I cant figure out why<br>&gt; not. ****<br>&gt;<br>&gt;** **<br>&gt;<br>&gt; Also, in the second output, why does it say Next Entry 0000000000000778<br>&gt; when in the previous output it said invalid handle value the same...**** <br>&gt;<br>&gt; On Mon, Jul 18, 2011 at 9:03 PM, Skywing <xxxxx><br>&gt; wrote: ****<br>&gt;<br>&gt; I suspect that your handle is probably closed at this point. What does<br>&gt; !handle return for the handle value?**** <br>&gt;<br>&gt; ****<br>&gt;<br>&gt; Are you synchronizing all code paths that use your handle against all code<br>&gt; paths that close the handle?**** <br>&gt;<br>&gt; ****<br>&gt;<br>&gt; - S (Msft)****<br>&gt;<br>&gt; ****<br>&gt;<br>&gt; *From:* xxxxx@lists.osr.com [mailto:<br>&gt; xxxxx@lists.osr.com] *On Behalf Of *A B<br>&gt; *Sent:* Monday, July 18, 2011 8:10 AM<br>&gt; *To:* Windows System Software Devs Interest List<br>&gt; *Subject:* [ntdev] Invalid Kernel Handle with Parameter 2 Garbage****<br>&gt;<br>&gt; ****<br>&gt;<br>&gt; All,**** <br>&gt;<br>&gt; ****<br>&gt;<br>&gt; Platform: Win2k8R2, Multi core CPU**** <br>&gt;<br>&gt; ****<br>&gt;<br>&gt; We have a volume filter which is assisted by a user mode service. This duo<br>&gt; has a few meta data files which are maintained by the driver and used by the<br>&gt; service.**** <br>&gt;<br>&gt; ****<br>&gt;<br>&gt; This driver has been put to high stress before, where these meta data files<br>&gt; are created and accessed at very high frequencies and updated too.**** <br>&gt;<br>&gt; The driver opens a file and passes on the Kernel mode handle to the user<br>&gt; for book keeping. When ever the user mode service needs to operate on the<br>&gt; files, it send the handle down to the driver. The user mode code *never*<br>&gt; uses this handle directly. ****<br>&gt;<br>&gt;**** <br>&gt;<br>&gt; On win2k8R2 we are running verifier tests on the duo. We encounter a<br>&gt; strange crash. Verifier options enabled are: ****<br>&gt;<br>&gt;**** <br>&gt;<br>&gt; [snip ? exceeding OSR maximum message size] ****<br>&gt;<br>&gt;**** <br>&gt;<br>&gt; Only these two unique combinations make the crash happen. QA has tried all<br>&gt; other combinations, and we are sure. Even, these two when enabled<br>&gt; independently, doesnt make it crash. ****<br>&gt;<br>&gt;**** <br>&gt;<br>&gt; The files are opened using the IoCreateFileSpecifyDeviceObjectHint API.<br>&gt; Object attributes are: ****<br>&gt;<br>&gt;**** <br>&gt;<br>&gt; [snip ? exceeding OSR maximum message size] ****<br>&gt;<br>&gt;**** <br>&gt;<br>&gt; ****<br>&gt;<br>&gt; after a while we get a blue screen saying that NtClose tried closing an<br>&gt; invalid Kernel handle. The handle value shown is actually an user mode<br>&gt; handle value (the high bit cleared) and as you can see (below) the other<br>&gt; parameters of the dump are gibberish. Also, the line where where it shows<br>&gt; the crash in the code is actually a ZwWriteFile call. Please note, that the<br>&gt; handle passed to ZwWriteFile through pIOParams-&gt;hFile is 0xffffffff80000788
> and ARG1 has the bits cleared.**
>
>
>
> [snip ? exceeding OSR maximum message size]
>
> \
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
>
>
>
> –
>
> - ab
>
> — NTDEV is sponsored by OSR 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
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

- ab

6

A B wrote:

We have a volume filter which is assisted by a user mode service. This
duo has a few meta data files which are maintained by the driver and
used by the service.

This driver has been put to high stress before, where these meta data
files are created and accessed at very high frequencies and updated too.
The driver opens a file and passes on the Kernel mode handle to the
user for book keeping. When ever the user mode service needs to
operate on the files, it send the handle down to the driver. The user
mode code *never* uses this handle directly.

On win2k8R2 we are running verifier tests on the duo. We encounter a
strange crash. Verifier options enabled are:
0: kd> !verifier

Verify Level 804 … enabled options are:
Inject random low-resource API failures
Miscellaneous checks enabled

Now, do you understand that your driver is not expected to operate
correctly when random failures are enabled? It shouldn’t blue screen,
of course, but you are certainly allowed to fail.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

so you mean to say that verifier is deliberately closing the handle and
testing whether we can handle the scenario of an accidental/deliberate
handle close? In other words, every time I use a handle in the Zw* calls, I
am expected to check whether it is valid?

If so, how do I do that, I, with my limited knowledge, am not aware of any
method that tells us if a handle is a valid one or not.

Thanks

amit

On Mon, Jul 18, 2011 at 11:45 PM, Tim Roberts wrote:

> A B wrote:
> >
> > We have a volume filter which is assisted by a user mode service. This
> > duo has a few meta data files which are maintained by the driver and
> > used by the service.
> >
> > This driver has been put to high stress before, where these meta data
> > files are created and accessed at very high frequencies and updated too.
> > The driver opens a file and passes on the Kernel mode handle to the
> > user for book keeping. When ever the user mode service needs to
> > operate on the files, it send the handle down to the driver. The user
> > mode code never uses this handle directly.
> >
> > On win2k8R2 we are running verifier tests on the duo. We encounter a
> > strange crash. Verifier options enabled are:
> > 0: kd> !verifier
> >
> > Verify Level 804 … enabled options are:
> > Inject random low-resource API failures
> > Miscellaneous checks enabled
>
> Now, do you understand that your driver is not expected to operate
> correctly when random failures are enabled? It shouldn’t blue screen,
> of course, but you are certainly allowed to fail.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

- ab

8

A B wrote:

so you mean to say that verifier is deliberately closing the handle
and testing whether we can handle the scenario of an
accidental/deliberate handle close? In other words, every time I use a
handle in the Zw* calls, I am expected to check whether it is valid?

No, it won’t close handles out from under you without notice, but any
kernel API might fail. The ZwCreateFile call might fail, but once it
has succeeded, the handle should stay valid.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

Thanks. Atleast now I know that in this case then it definitely is NOT a
verifier failure scenario, but a bug in my code.

why is the BSOD argument not what is documented…?

On Tue, Jul 19, 2011 at 1:36 AM, Tim Roberts wrote:

> A B wrote:
> > so you mean to say that verifier is deliberately closing the handle
> > and testing whether we can handle the scenario of an
> > accidental/deliberate handle close? In other words, every time I use a
> > handle in the Zw* calls, I am expected to check whether it is valid?
>
> No, it won’t close handles out from under you without notice, but any
> kernel API might fail. The ZwCreateFile call might fail, but once it
> has succeeded, the handle should stay valid.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

- ab

10

Excuse me, but you’re NOT supposed to pass kernel handles up and down through unser mode (inherently UNTRUSTED) code. If you want to give the user mode some handle, maintain your own table in the driver to map the usermode tag to the kernel handle.

11

i am a novice myself in kernel programming, but the MSDN page for
ObReferenceObjectByHandle routine says that if we pass an invalid
handle to it, the status returned will be STATUS_INVALID_HANDLE.

So can we not use this routine to check the validity of a handle? GREP
on the SRC folder shows many palces of this APIs usage, an one example
is the metadatamanager sample.

Just asking.

On Tue, Jul 19, 2011 at 4:58 AM, wrote:
> Excuse me, but you’re NOT supposed to pass kernel handles up and down through unser mode (inherently UNTRUSTED) code. If you want to give the user mode some handle, maintain your own table in the driver to map the usermode tag to the kernel handle.
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

12

On 19-Jul-2011 16:22, Ami Awbadhho wrote:

i am a novice myself in kernel programming, but the MSDN page for
ObReferenceObjectByHandle routine says that if we pass an invalid
handle to it, the status returned will be STATUS_INVALID_HANDLE.

So can we not use this routine to check the validity of a handle? GREP
on the SRC folder shows many palces of this APIs usage, an one example
is the metadatamanager sample.

Just asking.

Yes you can use ObReferenceObjectByHandle to “sanitize” usermode handles.
For example, suppose the usermode passes you an event handle.
You want to stash it and later signal the event.
Then you do:

PKEVENT pevent;
NTSTATUS status = ObReferenceObjectByHandle(
userhandle,
GENERIC_ALL, /*or whatever: access that you want for yourself*/
*ExEventObjectType, /* expected type */
Usermode, /* because it is usermode handle */
&pevent, /* returned to you */
NULL
);

This API will verify that the handle is valid on the user’s side, and is
indeed an event handle and not something else.
Of course this call must be done when the user handle is valid.
If the check succeeded, you receive the object *pointer* which
you can pass to KeSetEvent.

In case you need a handle: call ObReferenceObjectByPointer
on that pointer with accessmode=KPROCESSOR_MODE.
This will return you a kernel side handle.

Regards,
–pa

On Tue, Jul 19, 2011 at 4:58 AM, wrote:
>> Excuse me, but you’re NOT supposed to pass kernel handles up and down through unser mode (inherently UNTRUSTED) code. If you want to give the user mode some handle, maintain your own table in the driver to map the usermode tag to the kernel handle.

13

Ami Awbadhho wrote:

i am a novice myself in kernel programming, but the MSDN page for
ObReferenceObjectByHandle routine says that if we pass an invalid
handle to it, the status returned will be STATUS_INVALID_HANDLE.

So can we not use this routine to check the validity of a handle?

Well, that depends. You can use it to validate whether a user-mode
handle is valid in your current context. You cannot necessarily
validate whether a kernel handle is valid. Handles in user mode are
small integers – basically an offset into a table. Such numbers can be
validated. Handles in kernel mode are pointers to structures. There’s
no way to validate that a random kernel address happens to point to a
kernel object.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

14

Awbadhho,

I had tried your suggestion before posting this thread, just to be sure that
indeed the handle was a valid one, but it still didn’t resolve the crash. I
had also put in traces to everywhere in the code where we use ZwCreateFile,
ZwOpenFile, IoCreateFileSpecifyDeviceHint, and ZwClose, to see if I am
double closing any handle.

But nothing revealed anything yet.

Amit

On Tue, Jul 19, 2011 at 10:02 PM, Tim Roberts wrote:

> Ami Awbadhho wrote:
> > i am a novice myself in kernel programming, but the MSDN page for
> > ObReferenceObjectByHandle routine says that if we pass an invalid
> > handle to it, the status returned will be STATUS_INVALID_HANDLE.
> >
> > So can we not use this routine to check the validity of a handle?
>
> Well, that depends. You can use it to validate whether a user-mode
> handle is valid in your current context. You cannot necessarily
> validate whether a kernel handle is valid. Handles in user mode are
> small integers – basically an offset into a table. Such numbers can be
> validated. Handles in kernel mode are pointers to structures. There’s
> no way to validate that a random kernel address happens to point to a
> kernel object.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

- ab

15

Can you post all of the code between the IoCreateFile and ZwWriteFile calls?

The fact that the high bits are clear in the bugcheck output looks alarming,
but it really isn’t. The O/S clears all of those bits before looking the
handle up in the kernel handle table, so that’s what you’re seeing in the
output. And the other two undocumented parameters are just internal O/S
structures, I don’t think that decoding them will tell you much other than
the fact that the handle entry is freed.

-scott

Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

16

Scott,

each of the FS operations (create,open,get/set file size, read/write) are
implemented as IOCTLS from user land, Where the actual operation is
performed using Zw API or by rolling IRPs. Hence the code for the same is
quite large. Since it is copyrighted code, I will have to remove the
business logic part before I can post them, which will take some time.

I have one other qn but. If a handle is opened in the context of a user
process, and this handle is passed on via an IOCTL to the driver which then
tries to close it, it would mean that the thread context will be of the said
process. If so, then can verifier flag this as an error? Because a kernel
driver is trying to close a handle in the context of an user process? Could
moving the close operation in a workitem them help?

thanks

amit

On Wed, Jul 20, 2011 at 3:25 AM, Scott Noone wrote:

> Can you post all of the code between the IoCreateFile and ZwWriteFile
> calls?
>
> The fact that the high bits are clear in the bugcheck output looks
> alarming, but it really isn?t. The O/S clears all of those bits before
> looking the handle up in the kernel handle table, so that?s what you?re
> seeing in the output. And the other two undocumented parameters are just
> internal O/S structures, I don?t think that decoding them will tell you much
> other than the fact that the handle entry is freed.
>
> -scott
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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=ListServerhttp:
>

–

- ab</http:>

17

You need to be in the same process context that opened the handle if you want to close it (if it?s a user handle, which it had better be if you are accepting it from an IOCTL).

It?s very atypical to have a design where a client application passes a handle to a driver and then expects the driver to close it. Is this really necessary? Could you just capture a reference to the underlying object from the driver and leave it up to the application to close the handle (i.e. after issuing the IOCTL)?

  • S (Msft)

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of A B
Sent: Wednesday, July 20, 2011 1:21 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage

Scott,

each of the FS operations (create,open,get/set file size, read/write) are implemented as IOCTLS from user land, Where the actual operation is performed using Zw API or by rolling IRPs. Hence the code for the same is quite large. Since it is copyrighted code, I will have to remove the business logic part before I can post them, which will take some time.

I have one other qn but. If a handle is opened in the context of a user process, and this handle is passed on via an IOCTL to the driver which then tries to close it, it would mean that the thread context will be of the said process. If so, then can verifier flag this as an error? Because a kernel driver is trying to close a handle in the context of an user process? Could moving the close operation in a workitem them help?

thanks

amit
On Wed, Jul 20, 2011 at 3:25 AM, Scott Noone > wrote:
Can you post all of the code between the IoCreateFile and ZwWriteFile calls?

The fact that the high bits are clear in the bugcheck output looks alarming, but it really isn?t. The O/S clears all of those bits before looking the handle up in the kernel handle table, so that?s what you?re seeing in the output. And the other two undocumented parameters are just internal O/S structures, I don?t think that decoding them will tell you much other than the fact that the handle entry is freed.

-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

—
NTDEV is sponsored by OSR

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

–

- ab
— NTDEV is sponsored by OSR 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

18

>You need to be in the same process context that opened the handle if you
want to close it (if it?s a user handle

[AB]Yes we are. But my hunch is, appverifier or driver verifier is killing
the process (which runs in a script) and this makes the handle invalid.
Since the same stress test doesn’t blue screen for 15 days continuous runs.

It?s very atypical to have a design where a client application passes a
handle to a driver and then expects the driver to close it.
[AB] Couldn’t agree more. This is legacy code. Probably badly designed.

Is this really necessary?
[AB] We are redesigning this, but have to live with it for the time being.

Could you just capture a reference to the underlying object from the driver
and leave it up to the application to close the handle (i.e. after issuing
the IOCTL)?
[AB] Yes, I plan to do the same.

I would like to take a minute here and say thanks to all of you for trying
to help, I really appreciate it.

Thanks

Amit

On Thu, Jul 21, 2011 at 3:10 AM, Skywing wrote:

> You need to be in the same process context that opened the handle if you
> want to close it (if it?s a user handle, which it had better be if you are
> accepting it from an IOCTL).
>
> **
>
> It?s very atypical to have a design where a client application passes a
> handle to a driver and then expects the driver to close it. Is this really
> necessary? Could you just capture a reference to the underlying object from
> the driver and leave it up to the application to close the handle (i.e.
> after issuing the IOCTL)?**
>
> ****
>
> - S (Msft)
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of A B
> Sent: Wednesday, July 20, 2011 1:21 PM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Invalid Kernel Handle with Parameter 2 Garbage
>
> ****
>
> Scott,
>
> **
>
> each of the FS operations (create,open,get/set file size, read/write) are
> implemented as IOCTLS from user land, Where the actual operation is
> performed using Zw API or by rolling IRPs. Hence the code for the same is
> quite large. Since it is copyrighted code, I will have to remove the
> business logic part before I can post them, which will take some time.
>
> ****
>
> I have one other qn but. If a handle is opened in the context of a user
> process, and this handle is passed on via an IOCTL to the driver which then
> tries to close it, it would mean that the thread context will be of the said
> process. If so, then can verifier flag this as an error? Because a kernel
> driver is trying to close a handle in the context of an user process? Could
> moving the close operation in a workitem them help?
>
>
>
> thanks
>
> ****
>
> amit
>
> On Wed, Jul 20, 2011 at 3:25 AM, Scott Noone wrote:
>
> Can you post all of the code between the IoCreateFile and ZwWriteFile
> calls?
>
> The fact that the high bits are clear in the bugcheck output looks
> alarming, but it really isn?t. The O/S clears all of those bits before
> looking the handle up in the kernel handle table, so that?s what you?re
> seeing in the output. And the other two undocumented parameters are just
> internal O/S structures, I don?t think that decoding them will tell you much
> other than the fact that the handle entry is freed.
>
> -scott
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
>
>
>
> –
>
> - ab
>
> — NTDEV is sponsored by OSR 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
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

- ab