Bugcheck D1 in ks.sys

NTDEV
1

I’ve written an AVStream video capture driver. When I turn on
DriverVerifier, I get bugcheck D1 (!analyze -v output is below). It
happens when I insert the filter into GraphEdt.exe, render the preview
pin, and hit play. The bugcheck occurs after the first call to Process
(right after entering the Run state).

The memory being accessed (e3987bc8) is indeed pageable; !pool e3987bc8
2 shows:

Pool page e3987bc8 region is Paged pool
*e3987b68 size: 70 previous size: 28 (Allocated) *KSpf
Owning component : Unknown (update pooltag.txt)

It appears the KS.SYS has allocated the KSGATE structure from paged pool
(the tag “KSpf” is not used in my driver, so I’m guessing it is KS). It
also appears that KS.SYS is calling KsGateTurnInputOn at DISPATCH_LEVEL.
I have added code to all of my functions to capture the IRQL coming
in, and check it going out, to make sure it is the same; it comes up
clean, so I’m 99% sure it’s not me forgetting to release a spinlock or
something.

Any ideas? Oh, this is running on XP Pro SP2, with all the latest
updates installed.

TIA,

– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: e3987bc8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f6673dfd, address which referenced memory

Debugging Details:

WRITE_ADDRESS: e3987bc8 Paged pool

CURRENT_IRQL: 2

FAULTING_IP:
ks!KsGateTurnInputOn+d
f6673dfd f00fc108 lock xadd [eax],ecx

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 8053225b to 804e3592

STACK_TEXT:
ed1dc664 8053225b 00000003 ed1dc9c0 00000000
nt!RtlpBreakWithStatusInstruction
ed1dc6b0 80532d2e 00000003 e3987bc8 f6673dfd nt!KiBugCheckDebugBreak+0x19
ed1dca90 804e187f 0000000a e3987bc8 00000002 nt!KeBugCheck2+0x574
ed1dca90 f6673dfd 0000000a e3987bc8 00000002 nt!KiTrap0E+0x233
ed1dcb24 f6678279 e3987bc8 86a0b2b8 866c9884 ks!KsGateTurnInputOn+0xd
ed1dcb38 f6678b31 869c7270 86a0b2b8 00000000
ks!CKsQueue::SetStreamPointer+0x254
ed1dcb64 f667a310 01a0b2b8 00000000 861a56d0 ks!CKsQueue::AddFrame+0x5a
ed1dcb90 f668cf3a 866c97d8 00000000 ed1dcbb0
ks!CKsQueue::TransferKsIrp+0x1e6
ed1dcbb8 f667bf85 86a5c020 87130f00 ed1dcbfc
ks!CKsPin::DispatchDeviceIoControl+0x168
ed1dcbc8 804e37f7 86a5c020 87130f00 806ed2a4 ks!DispatchDeviceIoControl+0x28
ed1dcbd8 80669cc5 87130fd4 87130ff8 86704750 nt!IopfCallDriver+0x31
ed1dcbfc 80674c0b 86704698 86709170 87130f00 nt!IovCallDriver+0xa0
ed1dcc10 804e37f7 86704698 87130f00 806ed2a4 nt!ViDriverDispatchGeneric+0x2a
ed1dcc20 80669cc5 861ca230 806ed070 87130f00 nt!IopfCallDriver+0x31
ed1dcc44 8056a101 87130fdc 866d26f8 87130f00 nt!IovCallDriver+0xa0
ed1dcc58 80579a8a 86704698 87130f00 866d26f8
nt!IopSynchronousServiceTail+0x60
ed1dcd00 8057bfa5 0000025c 00000314 00000000 nt!IopXxxControlFile+0x611
ed1dcd34 804de7ec 0000025c 00000314 00000000 nt!NtDeviceIoControlFile+0x2a
ed1dcd34 7c90eb94 0000025c 00000314 00000000 nt!KiFastCallEntry+0xf8
057dfe68 7c90d8ef 7c8016be 0000025c 00000314 ntdll!KiFastSystemCallRet
057dfe6c 7c8016be 0000025c 00000314 00000000 ntdll!ZwDeviceIoControlFile+0xc
057dfecc 5e04b82d 0000025c 002f4017 00000000 kernel32!DeviceIoControl+0x78
057dff44 5e03ce0a 0027ff7c 00000001 057dff7c
ksproxy!CStandardInterfaceHandler::KsProcessMediaSamples+0x227
057dff84 5e03cf32 00000000 057dffb4 5e041762
ksproxy!CKsOutputPin::QueueBuffersToDevice+0x128
057dff90 5e041762 00000000 0090cce0 0006f2b8
ksproxy!CKsOutputPin::MarshalRoutine+0x16
057dffb4 7c80b683 00917758 0006f2b8 77d4d598
ksproxy!CAsyncItemHandler::AsyncItemProc+0x18e
057dffec 00000000 5e0415d4 00917758 00000000 kernel32!BaseThreadStart+0x37

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
ks!KsGateTurnInputOn+d
f6673dfd f00fc108 lock xadd [eax],ecx

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ks!KsGateTurnInputOn+d

MODULE_NAME: ks

IMAGE_NAME: ks.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107ef8

FAILURE_BUCKET_ID: 0xD1_W_VRF_ks!KsGateTurnInputOn+d

BUCKET_ID: 0xD1_W_VRF_ks!KsGateTurnInputOn+d

Followup: MachineOwner

2

Hi:

I would assume that Trap does not occur without Verifier off. I would
assume you have not altered the default setting for the Verifier. You could
use a Checked build to see you get additional info.

-William Michael Jones “Mike”

“Michael Jones” wrote in message
news:xxxxx@ntdev…
> I’ve written an AVStream video capture driver. When I turn on
> DriverVerifier, I get bugcheck D1 (!analyze -v output is below). It
> happens when I insert the filter into GraphEdt.exe, render the preview
> pin, and hit play. The bugcheck occurs after the first call to Process
> (right after entering the Run state).
>
> The memory being accessed (e3987bc8) is indeed pageable; !pool e3987bc8 2
> shows:
>
> Pool page e3987bc8 region is Paged pool
> *e3987b68 size: 70 previous size: 28 (Allocated) *KSpf
> Owning component : Unknown (update pooltag.txt)
>
> It appears the KS.SYS has allocated the KSGATE structure from paged pool
> (the tag “KSpf” is not used in my driver, so I’m guessing it is KS). It
> also appears that KS.SYS is calling KsGateTurnInputOn at DISPATCH_LEVEL. I
> have added code to all of my functions to capture the IRQL coming in, and
> check it going out, to make sure it is the same; it comes up clean, so I’m
> 99% sure it’s not me forgetting to release a spinlock or something.
>
> Any ideas? Oh, this is running on XP Pro SP2, with all the latest updates
> installed.
>
> TIA,
>
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
>
> ***
> *
> * Bugcheck Analysis
> *
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> 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 kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: e3987bc8, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000001, value 0 = read operation, 1 = write operation
> Arg4: f6673dfd, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> WRITE_ADDRESS: e3987bc8 Paged pool
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> ks!KsGateTurnInputOn+d
> f6673dfd f00fc108 lock xadd [eax],ecx
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 8053225b to 804e3592
>
> STACK_TEXT:
> ed1dc664 8053225b 00000003 ed1dc9c0 00000000
> nt!RtlpBreakWithStatusInstruction
> ed1dc6b0 80532d2e 00000003 e3987bc8 f6673dfd nt!KiBugCheckDebugBreak+0x19
> ed1dca90 804e187f 0000000a e3987bc8 00000002 nt!KeBugCheck2+0x574
> ed1dca90 f6673dfd 0000000a e3987bc8 00000002 nt!KiTrap0E+0x233
> ed1dcb24 f6678279 e3987bc8 86a0b2b8 866c9884 ks!KsGateTurnInputOn+0xd
> ed1dcb38 f6678b31 869c7270 86a0b2b8 00000000
> ks!CKsQueue::SetStreamPointer+0x254
> ed1dcb64 f667a310 01a0b2b8 00000000 861a56d0 ks!CKsQueue::AddFrame+0x5a
> ed1dcb90 f668cf3a 866c97d8 00000000 ed1dcbb0
> ks!CKsQueue::TransferKsIrp+0x1e6
> ed1dcbb8 f667bf85 86a5c020 87130f00 ed1dcbfc
> ks!CKsPin::DispatchDeviceIoControl+0x168
> ed1dcbc8 804e37f7 86a5c020 87130f00 806ed2a4
> ks!DispatchDeviceIoControl+0x28
> ed1dcbd8 80669cc5 87130fd4 87130ff8 86704750 nt!IopfCallDriver+0x31
> ed1dcbfc 80674c0b 86704698 86709170 87130f00 nt!IovCallDriver+0xa0
> ed1dcc10 804e37f7 86704698 87130f00 806ed2a4
> nt!ViDriverDispatchGeneric+0x2a
> ed1dcc20 80669cc5 861ca230 806ed070 87130f00 nt!IopfCallDriver+0x31
> ed1dcc44 8056a101 87130fdc 866d26f8 87130f00 nt!IovCallDriver+0xa0
> ed1dcc58 80579a8a 86704698 87130f00 866d26f8
> nt!IopSynchronousServiceTail+0x60
> ed1dcd00 8057bfa5 0000025c 00000314 00000000 nt!IopXxxControlFile+0x611
> ed1dcd34 804de7ec 0000025c 00000314 00000000 nt!NtDeviceIoControlFile+0x2a
> ed1dcd34 7c90eb94 0000025c 00000314 00000000 nt!KiFastCallEntry+0xf8
> 057dfe68 7c90d8ef 7c8016be 0000025c 00000314 ntdll!KiFastSystemCallRet
> 057dfe6c 7c8016be 0000025c 00000314 00000000
> ntdll!ZwDeviceIoControlFile+0xc
> 057dfecc 5e04b82d 0000025c 002f4017 00000000 kernel32!DeviceIoControl+0x78
> 057dff44 5e03ce0a 0027ff7c 00000001 057dff7c
> ksproxy!CStandardInterfaceHandler::KsProcessMediaSamples+0x227
> 057dff84 5e03cf32 00000000 057dffb4 5e041762
> ksproxy!CKsOutputPin::QueueBuffersToDevice+0x128
> 057dff90 5e041762 00000000 0090cce0 0006f2b8
> ksproxy!CKsOutputPin::MarshalRoutine+0x16
> 057dffb4 7c80b683 00917758 0006f2b8 77d4d598
> ksproxy!CAsyncItemHandler::AsyncItemProc+0x18e
> 057dffec 00000000 5e0415d4 00917758 00000000 kernel32!BaseThreadStart+0x37
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_IP:
> ks!KsGateTurnInputOn+d
> f6673dfd f00fc108 lock xadd [eax],ecx
>
> FAULTING_SOURCE_CODE:
>
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: ks!KsGateTurnInputOn+d
>
> MODULE_NAME: ks
>
> IMAGE_NAME: ks.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107ef8
>
> FAILURE_BUCKET_ID: 0xD1_W_VRF_ks!KsGateTurnInputOn+d
>
> BUCKET_ID: 0xD1_W_VRF_ks!KsGateTurnInputOn+d
>
> Followup: MachineOwner
> ---------
>

3

It does not occur when verifier is off (in fact, it is is sufficient
just to turn off “Force IRQL checking”). I tried a checked version of
the kernel, hal, and ks.sys; it didn’t turn up anything. Not looking
forward to installing a full-up checked build, but it may come to that.

I did get a response from someone at Microsoft in the other newsgroup
(microsoft.public.development.device.drivers) that indicated it might be
a bug in ks.sys which was fixed in Vista; if/when I find out more, I
will post.

Cheers,

–mkj

William Michael Jones wrote:

Hi:

I would assume that Trap does not occur without Verifier off. I would
assume you have not altered the default setting for the Verifier. You could
use a Checked build to see you get additional info.

–

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

4

“Force IRQL checking” is working here exactly as it is meant to. Without it, this bug could go undetected for months or years, occasionally crashing machines mysteriously.

IMO, don’t waste your time with a checked build. This is so clearly a KS bug [which was fixed for Vista], I’m surprised you got such a cautious reply elsewhere.