BSOD apc index mismatch

OSR_Community_User · February 9, 2010, 5:07am

Hi all,

any ideas what could cause a BSOD apc index mismatch?
I’m developing an audio driver,

Thanks,
/Uwe

Loading Dump File [C:\Windows\Minidump\020910-34959-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\Symbols
Executable search path is: C:\Windows
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff80002a59000 PsLoadedModuleList = 0xfffff80002c96e50
Debug session time: Tue Feb 9 10:44:52.419 2010 (GMT+1)
System Uptime: 0 days 0:00:58.524
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1, {77b9ff2a, 0, fffd, fffff8800227cca0}

Probably caused by : ntkrnlmp.exe ( nt!KiSystemServiceExit+245 )

Followup: MachineOwner

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

APC_INDEX_MISMATCH (1)
This is a kernel internal error. The most common reason to see this
bugcheck is when a filesystem or a driver has a mismatched number of
calls to disable and re-enable APCs. The key data item is the
Thread->KernelApcDisable field. A negative value indicates that a driver
has disabled APC calls without re-enabling them. A positive value indicates
that the reverse is true. This check is made on exit from a system call.
Arguments:
Arg1: 0000000077b9ff2a, address of system function (system call)
Arg2: 0000000000000000, Thread->ApcStateIndex << 8 | Previous ApcStateIndex
Arg3: 000000000000fffd, Thread->KernelApcDisable
Arg4: fffff8800227cca0, Previous KernelApcDisable

Debugging Details:

FAULTING_IP:
+0
00000000`77b9ff2a ?? ???

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x1

PROCESS_NAME: audiodg.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002aca469 to fffff80002acaf00

STACK_TEXT:
fffff8800227ca68 fffff80002aca469 : 0000000000000001 0000000077b9ff2a 0000000000000000 000000000000fffd : nt!KeBugCheckEx
fffff8800227ca70 fffff80002aca3a0 : fffffa8009f892c0 0000000001f6e0d8 fffff8800227cbc8 0000000000000001 :
nt!KiBugCheckDispatch+0x69
fffff8800227cbb0 0000000077b9ff2a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiSystemServiceExit+0x245
0000000001f6e0a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77b9ff2a

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiSystemServiceExit+245
fffff800`02aca3a0 4883ec50 sub rsp,50h

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!KiSystemServiceExit+245

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600

FAILURE_BUCKET_ID: X64_0x1_nt!KiSystemServiceExit+245

BUCKET_ID: X64_0x1_nt!KiSystemServiceExit+245

Followup: MachineOwner

Maxim_S_Shatskih · February 9, 2010, 5:21am

KeAttachProcess without matching KeDetachProcess?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“uwekirst” wrote in message news:xxxxx@ntdev…
> Hi all,
>
> any ideas what could cause a BSOD apc index mismatch?
> I’m developing an audio driver,
>
> Thanks,
> /Uwe
>
>
> Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [C:\Windows\Minidump\020910-34959-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is: C:\Symbols
> Executable search path is: C:\Windows
> Windows 7 Kernel Version 7600 MP (2 procs) Free x64
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
> Machine Name:
> Kernel base = 0xfffff80002a59000 PsLoadedModuleList = 0xfffff80002c96e50
> Debug session time: Tue Feb 9 10:44:52.419 2010 (GMT+1)
> System Uptime: 0 days 0:00:58.524
> Loading Kernel Symbols
> …
> …
> …
> Loading User Symbols
> Loading unloaded module list
> …
> ***
> *
>
> * Bugcheck
> Analysis
> *
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 1, {77b9ff2a, 0, fffd, fffff8800227cca0}
>
> Probably caused by : ntkrnlmp.exe ( nt!KiSystemServiceExit+245 )
>
> Followup: MachineOwner
> ---------
>
> 1: kd> !analyze -v
> ***
> *
>
> * Bugcheck
> Analysis
> *
>
>
>
> APC_INDEX_MISMATCH (1)
> This is a kernel internal error. The most common reason to see this
> bugcheck is when a filesystem or a driver has a mismatched number of
> calls to disable and re-enable APCs. The key data item is the
> Thread->KernelApcDisable field. A negative value indicates that a driver
> has disabled APC calls without re-enabling them. A positive value indicates
> that the reverse is true. This check is made on exit from a system call.
> Arguments:
> Arg1: 0000000077b9ff2a, address of system function (system call)
> Arg2: 0000000000000000, Thread->ApcStateIndex << 8 | Previous ApcStateIndex
> Arg3: 000000000000fffd, Thread->KernelApcDisable
> Arg4: fffff8800227cca0, Previous KernelApcDisable
>
> Debugging Details:
> ------------------
>
>
> FAULTING_IP:
> +0
> 0000000077b9ff2a ?? ??? > > CUSTOMER_CRASH_COUNT: 1 > > DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT > > BUGCHECK_STR: 0x1 > > PROCESS_NAME: audiodg.exe > > CURRENT_IRQL: 0 > > LAST_CONTROL_TRANSFER: from fffff80002aca469 to fffff80002acaf00 > > STACK_TEXT: > fffff8800227ca68 fffff80002aca469 : 0000000000000001
> 0000000077b9ff2a 0000000000000000 000000000000fffd : nt!KeBugCheckEx > fffff8800227ca70 fffff80002aca3a0 : fffffa8009f892c0
> 0000000001f6e0d8 fffff8800227cbc8 0000000000000001 : > nt!KiBugCheckDispatch+0x69 > fffff8800227cbb0 0000000077b9ff2a : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > nt!KiSystemServiceExit+0x245 > 0000000001f6e0a8 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : 0x77b9ff2a > > > STACK_COMMAND: kb > > FOLLOWUP_IP: > nt!KiSystemServiceExit+245 > fffff80002aca3a0 4883ec50 sub rsp,50h
>
> SYMBOL_STACK_INDEX: 2
>
> SYMBOL_NAME: nt!KiSystemServiceExit+245
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600
>
> FAILURE_BUCKET_ID: X64_0x1_nt!KiSystemServiceExit+245
>
> BUCKET_ID: X64_0x1_nt!KiSystemServiceExit+245
>
> Followup: MachineOwner
> ---------
>
>

OSR_Community_User · February 9, 2010, 6:00am

Anything else?

I think I’m not using KeAttachProcess or KeStackAttachProcess in my code.

My audio driver is portcls base, wavecyclic.

Thanks,
/Uwe

Maxim S. Shatskih schrieb:

KeAttachProcess without matching KeDetachProcess?

Krzysztof_Uchronski-1 · February 9, 2010, 7:16am

Check whether you have anything in your code that changes APC state, e.g. if you are acquiring guarded/fast mutex it has to be released before exiting kernel. Also if for any reason you’re using SEH to catch exceptions generated by the function which is changing APC state then it’s highly likely that when exception is raised APC state is not restored (e.g. because code responsible for releasing fast mutex exited prematurely without actually releasing it).
You can also try to reconstruct the kernel stack for the thread in which context crash happened - it’s not very reliable in this case but maybe it gives you some hints about what kernel code was actually executed.

Krzysztof Uchronski

Scott_Noone_OSR · February 9, 2010, 9:38am

Do you call KeEnterCriticalSection at all? (Calling it is a requirement for
using ERESOURCES, so if you don’t think you do you might want to check if
you have it buried in a lock acquire macro someplace).

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“uwekirst” wrote in message news:xxxxx@ntdev…
> Anything else?
>
> I think I’m not using KeAttachProcess or KeStackAttachProcess in my code.
>
> My audio driver is portcls base, wavecyclic.
>
> Thanks,
> /Uwe
>
> Maxim S. Shatskih schrieb:
>> KeAttachProcess without matching KeDetachProcess?
>>
>>
>
>

OSR_Community_User · February 10, 2010, 3:37am

Hi,

I’m using the following objects: a mutex (not fast or guarded), spin
locks and a remove lock.
Furthermore I’m creating a thread.
Is this allowed in add device or should I better move that to start device?

Thanks,
/Uwe

Scott_Noone_OSR · February 10, 2010, 10:07am

> I’m using the following objects: a mutex (not fast or guarded)

Mutexes modify the KernelApcDisable value. I’d make sure all of your error
paths release your mutex.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“uwekirst” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m using the following objects: a mutex (not fast or guarded), spin locks
> and a remove lock.
> Furthermore I’m creating a thread.
> Is this allowed in add device or should I better move that to start
> device?
>
> Thanks,
> /Uwe
>
>

OSR_Community_User · February 12, 2010, 8:44am

I have now removed all references of my mutex in my code, but still getting
BSOD apc index mismatch.
Any ideas what else modifies the KernelApcDisable value?
I’m not using CriticalRegions.

The BSOD most probably happens during loading the driver after start device.
If I load the driver for the first time everything seems to be ok.
After powercycling the device (turning it on for the second time) it
crashes.
thanks,

/Uwe

Scott Noone schrieb:

> I’m using the following objects: a mutex (not fast or guarded)

Mutexes modify the KernelApcDisable value. I’d make sure all of your
error paths release your mutex.

-scott

OSR_Community_User · February 12, 2010, 1:42pm

Did you try testing your driver with Verifier enabled, on Windows 7 or Vista? Verifier might be able to catch the problem closer to its root cause.

To enable Verifier: “verifier.exe /standard /driver yourdriver.sys” from an Administrator elevated cmd.exe window. At the end of the investigation, you can use “verifier.exe /reset” to disable Verifier.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Friday, February 12, 2010 5:44 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BSOD apc index mismatch

I have now removed all references of my mutex in my code, but still getting
BSOD apc index mismatch.
Any ideas what else modifies the KernelApcDisable value?
I’m not using CriticalRegions.

The BSOD most probably happens during loading the driver after start device.
If I load the driver for the first time everything seems to be ok.
After powercycling the device (turning it on for the second time) it
crashes.
thanks,

/Uwe

Scott Noone schrieb:

> I’m using the following objects: a mutex (not fast or guarded)

Mutexes modify the KernelApcDisable value. I’d make sure all of your
error paths release your mutex.

-scott

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

OSR_Community_User · February 12, 2010, 3:13pm

Hi all,

Hello Dan, thank you for your suggestion.
If I enable the driver verifier the bugcheck looks like this.
It crashes in ksthunk.sys.
Any ideas?

thanks,
/Uwe

Loading Dump File [C:\Windows\Minidump\021210-20092-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\Symbols
Executable search path is: C:\Windows
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff80002e51000 PsLoadedModuleList = 0xfffff8000308ee50
Debug session time: Fri Feb 12 17:35:10.062 2010 (GMT+1)
System Uptime: 0 days 0:02:18.136
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol
loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {58, 2, 1, fffff80002ec74d8}

Probably caused by : ksthunk.sys (
ksthunk!CKernelFilterDevice::DeferIrpCompletion+12 )

Followup: MachineOwner

0: kd>

0: 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: 0000000000000058, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002ec74d8, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 0000000000000058

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiTryUnwaitThread+28
fffff800`02ec74d8 f0480fba6b4000 lock bts qword ptr [rbx+40h],0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

BUGCHECK_STR: 0xA

PROCESS_NAME: audiodg.exe

TRAP_FRAME: fffff880022674b0 – (.trap 0xfffff880022674b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88002267858 rbx=0000000000000000 rcx=fffff8000303be80
rdx=fffff98009896fb0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec74d8 rsp=fffff88002267640 rbp=0000000000000000
r8=0000000000000100 r9=0000000000000000 r10=fffff98009896fb0
r11=fffff98009896fb0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x28:
fffff80002ec74d8 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002ec2469 to fffff80002ec2f00

STACK_TEXT:
fffff88002267368 fffff80002ec2469 : 000000000000000a 0000000000000058 0000000000000002 0000000000000001 : nt!KeBugCheckEx
fffff88002267370 fffff80002ec10e0 : 0000000000000000 0000000000000018 0000000000000000 0000000000000000 :
nt!KiBugCheckDispatch+0x69
fffff880022674b0 fffff80002ec74d8 : 0000000000000000 0000000000000018 fffff98009896d30 fffff80003357b6b : nt!KiPageFault+0x260
fffff88002267640 fffff80002ec7314 : fffff88002267850 0000000000000000 0000000000000000 fffff8000303be80 :
nt!KiTryUnwaitThread+0x28
fffff880022676a0 fffff880042bf62e : fffff88000000000 fffff98000000000 fffffa80074a0f00 000000000005000e : nt!KeSetEvent+0x484
fffff88002267710 fffff8000336a5d6 : fffff98009896f68 fffff88002267850 fffff880022678d0 fffff98009896d30 :
ksthunk!CKernelFilterDevice::DeferIrpCompletion+0x12
fffff88002267740 fffff80002ec5516 : fffff98009896f6b fffff80000000000 0000000000000000 fffff88000000005 :
nt!IovpLocalCompletionRoutine+0x166
fffff880022677a0 fffff8000336219f : fffff98009896d30 fffff98009896f00 fffffa800780d900 0000000000000000 :
nt!IopfCompleteRequest+0x3a6
fffff88002267880 fffff880042bf94c : 0000000000000001 fffff98009896fb0 0000000000000001 fffffa800780d920 :
nt!IovCompleteRequest+0x19f
fffff88002267950 fffff80003368c16 : fffff98009896d30 0000000000000002 fffffa80c0000005 fffffa8007d13360 :
ksthunk!CKernelFilterDevice::DispatchIrp+0x244
fffff880022679b0 fffff800031db3a7 : fffffa800777aea0 fffff88002267ca0 fffffa800777aea0 fffffa80076d1740 :
nt!IovCallDriver+0x566
fffff88002267a10 fffff800031dbc06 : 0000000000d9e3f0 000000000000023d 0000000000000000 0000000000000000 :
nt!IopXxxControlFile+0x607
fffff88002267b40 fffff80002ec2153 : fffffa800755b710 0000000000d9e3d8 fffff88002267bc8 0000000000000001 :
nt!NtDeviceIoControlFile+0x56
fffff88002267bb0 00000000777eff2a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiSystemServiceCopyEnd+0x13
0000000000d9e3a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x777eff2a

STACK_COMMAND: kb

FOLLOWUP_IP:
ksthunk!CKernelFilterDevice::DeferIrpCompletion+12
fffff880`042bf62e b8160000c0 mov eax,0C0000016h

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: ksthunk!CKernelFilterDevice::DeferIrpCompletion+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ksthunk

IMAGE_NAME: ksthunk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bca93

FAILURE_BUCKET_ID:
X64_0xA_VRF_ksthunk!CKernelFilterDevice::DeferIrpCompletion+12

BUCKET_ID: X64_0xA_VRF_ksthunk!CKernelFilterDevice::DeferIrpCompletion+12

Followup: MachineOwner

0: kd> .trap 0xfffff880022674b0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88002267858 rbx=0000000000000000 rcx=fffff8000303be80
rdx=fffff98009896fb0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec74d8 rsp=fffff88002267640 rbp=0000000000000000
r8=0000000000000100 r9=0000000000000000 r10=fffff98009896fb0
r11=fffff98009896fb0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x28:
fffff80002ec74d8 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=???

Daniel Mihai schrieb:

Did you try testing your driver with Verifier enabled, on Windows 7 or Vista? Verifier might be able to catch the problem closer to its root cause.

To enable Verifier: “verifier.exe /standard /driver yourdriver.sys” from an Administrator elevated cmd.exe window. At the end of the investigation, you can use “verifier.exe /reset” to disable Verifier.

Dan

OSR_Community_User · February 12, 2010, 4:09pm

Is your driver sending IRPs to ksthunk? My guess is that a driver has sent the IRP below to ksthunk, ksthunk returned STATUS_PENDING, and the caller didn’t deal properly with that STATUS_PENDING code (e.g. perhaps it had to wait for the completion, but it didn’t wait).

But this is just a guess, based on the stack trace below. If reviewing the source code that sends IRPs to ksthunk doesn’t produce results, then you could find the address of the problematic IRP in the debugger, examine its contents (e.g. by using !irp), and try to figure out what’s wrong with it and/or its completion event.

Good luck!

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Friday, February 12, 2010 12:12 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BSOD apc index mismatch

Hi all,

Hello Dan, thank you for your suggestion.
If I enable the driver verifier the bugcheck looks like this.
It crashes in ksthunk.sys.
Any ideas?

thanks,
/Uwe

Loading Dump File [C:\Windows\Minidump\021210-20092-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\Symbols
Executable search path is: C:\Windows
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff80002e51000 PsLoadedModuleList = 0xfffff8000308ee50
Debug session time: Fri Feb 12 17:35:10.062 2010 (GMT+1)
System Uptime: 0 days 0:02:18.136
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol
loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {58, 2, 1, fffff80002ec74d8}

Probably caused by : ksthunk.sys (
ksthunk!CKernelFilterDevice::DeferIrpCompletion+12 )

Followup: MachineOwner

0: kd>

0: 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: 0000000000000058, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002ec74d8, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 0000000000000058

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiTryUnwaitThread+28
fffff800`02ec74d8 f0480fba6b4000 lock bts qword ptr [rbx+40h],0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

BUGCHECK_STR: 0xA

PROCESS_NAME: audiodg.exe

TRAP_FRAME: fffff880022674b0 – (.trap 0xfffff880022674b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88002267858 rbx=0000000000000000 rcx=fffff8000303be80
rdx=fffff98009896fb0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec74d8 rsp=fffff88002267640 rbp=0000000000000000
r8=0000000000000100 r9=0000000000000000 r10=fffff98009896fb0
r11=fffff98009896fb0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x28:
fffff80002ec74d8 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002ec2469 to fffff80002ec2f00

STACK_TEXT:
fffff88002267368 fffff80002ec2469 : 000000000000000a 0000000000000058 0000000000000002 0000000000000001 : nt!KeBugCheckEx
fffff88002267370 fffff80002ec10e0 : 0000000000000000 0000000000000018 0000000000000000 0000000000000000 :
nt!KiBugCheckDispatch+0x69
fffff880022674b0 fffff80002ec74d8 : 0000000000000000 0000000000000018 fffff98009896d30 fffff80003357b6b : nt!KiPageFault+0x260
fffff88002267640 fffff80002ec7314 : fffff88002267850 0000000000000000 0000000000000000 fffff8000303be80 :
nt!KiTryUnwaitThread+0x28
fffff880022676a0 fffff880042bf62e : fffff88000000000 fffff98000000000 fffffa80074a0f00 000000000005000e : nt!KeSetEvent+0x484
fffff88002267710 fffff8000336a5d6 : fffff98009896f68 fffff88002267850 fffff880022678d0 fffff98009896d30 :
ksthunk!CKernelFilterDevice::DeferIrpCompletion+0x12
fffff88002267740 fffff80002ec5516 : fffff98009896f6b fffff80000000000 0000000000000000 fffff88000000005 :
nt!IovpLocalCompletionRoutine+0x166
fffff880022677a0 fffff8000336219f : fffff98009896d30 fffff98009896f00 fffffa800780d900 0000000000000000 :
nt!IopfCompleteRequest+0x3a6
fffff88002267880 fffff880042bf94c : 0000000000000001 fffff98009896fb0 0000000000000001 fffffa800780d920 :
nt!IovCompleteRequest+0x19f
fffff88002267950 fffff80003368c16 : fffff98009896d30 0000000000000002 fffffa80c0000005 fffffa8007d13360 :
ksthunk!CKernelFilterDevice::DispatchIrp+0x244
fffff880022679b0 fffff800031db3a7 : fffffa800777aea0 fffff88002267ca0 fffffa800777aea0 fffffa80076d1740 :
nt!IovCallDriver+0x566
fffff88002267a10 fffff800031dbc06 : 0000000000d9e3f0 000000000000023d 0000000000000000 0000000000000000 :
nt!IopXxxControlFile+0x607
fffff88002267b40 fffff80002ec2153 : fffffa800755b710 0000000000d9e3d8 fffff88002267bc8 0000000000000001 :
nt!NtDeviceIoControlFile+0x56
fffff88002267bb0 00000000777eff2a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiSystemServiceCopyEnd+0x13
0000000000d9e3a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x777eff2a

STACK_COMMAND: kb

FOLLOWUP_IP:
ksthunk!CKernelFilterDevice::DeferIrpCompletion+12
fffff880`042bf62e b8160000c0 mov eax,0C0000016h

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: ksthunk!CKernelFilterDevice::DeferIrpCompletion+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ksthunk

IMAGE_NAME: ksthunk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bca93

FAILURE_BUCKET_ID:
X64_0xA_VRF_ksthunk!CKernelFilterDevice::DeferIrpCompletion+12

BUCKET_ID: X64_0xA_VRF_ksthunk!CKernelFilterDevice::DeferIrpCompletion+12

Followup: MachineOwner

0: kd> .trap 0xfffff880022674b0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88002267858 rbx=0000000000000000 rcx=fffff8000303be80
rdx=fffff98009896fb0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec74d8 rsp=fffff88002267640 rbp=0000000000000000
r8=0000000000000100 r9=0000000000000000 r10=fffff98009896fb0
r11=fffff98009896fb0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x28:
fffff80002ec74d8 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=???

Daniel Mihai schrieb:

Did you try testing your driver with Verifier enabled, on Windows 7 or Vista? Verifier might be able to catch the problem closer to its root cause.

To enable Verifier: “verifier.exe /standard /driver yourdriver.sys” from an Administrator elevated cmd.exe window. At the end of the investigation, you can use “verifier.exe /reset” to disable Verifier.

Dan

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

Tim_Roberts · February 12, 2010, 4:19pm

Daniel Mihai wrote:

Is your driver sending IRPs to ksthunk? My guess is that a driver has sent the IRP below to ksthunk, ksthunk returned STATUS_PENDING, and the caller didn’t deal properly with that STATUS_PENDING code (e.g. perhaps it had to wait for the completion, but it didn’t wait).

Ksthunk.sys is an “adapter” layer for kernel streaming devices. The
process name is “audiodg”, which is the special Vista user-mode audio
process.

So, my guess is there’s a bad audio driver in here somewhere, but it’s
rather unusual to see a manifestation like this. KS drivers don’t often
deal with IRPs directly – that’s the job of the AVStream framework.

I don’t think the original poster ever told us whether this is just
something he sees, or if he is actually developing a driver.

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

OSR_Community_User · February 15, 2010, 6:50am

Hi,

it seems I have found the cause of my BSOD.
The start device function of my miniport driver should not just return
STATUS_SUCCESS. Instead It should take the return value of install
subdevice which is probably STATUS_PENDING. The microsoft port driver
waits for the IRP to complete in that case.
Thank,

/Uwe

Daniel Mihai schrieb:

Is your driver sending IRPs to ksthunk? My guess is that a driver has sent the IRP below to ksthunk, ksthunk returned STATUS_PENDING, and the caller didn’t deal properly with that STATUS_PENDING code (e.g. perhaps it had to wait for the completion, but it didn’t wait).

Good luck!

Dan