When do driver writers care about APCs.
I normally don’t deal with them, except long ago a buggy code was only acquiring a mutex and never releasing it in any code path. That’s when my system crashed with
APC_INDEX_MISMATCH (1)
Now I’m seeing bugcode (1) again. Where would you look for this bug?
thanks,
massoud
From the Windbg documentation:
Bug Check 0x1: APC_INDEX_MISMATCH
The APC_INDEX_MISMATCH bug check has a value of 0x00000001. This
indicates that there has been a mismatch in the APC state index.
Parameters
The following parameters are displayed on the blue screen.
Parameter Description
1 The address of the system function (system call)
2 The value of the following bit computation: Thread->ApcStateIndex <<
8 | Previous ApcStateIndex
3 The value of Thread->KernelApcDisable
4 The value of the previous KernelApcDisable
Cause
The most common cause of this bug check is when a file system has a
mismatched sequence of KeEnterCriticalRegion calls and
KeLeaveCriticalRegion calls.
Comments
This is a kernel internal error which can occur only on a checked build.
This error occurs on exit from a system call.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@yahoo.com” wrote in message
news:xxxxx@ntdev:
> When do driver writers care about APCs.
> I normally don’t deal with them, except long ago a buggy code was only acquiring a mutex and never releasing it in any code path. That’s when my system crashed with
> APC_INDEX_MISMATCH (1)
>
> Now I’m seeing bugcode (1) again. Where would you look for this bug?
>
> thanks,
> massoud
“Don Burn” wrote in message news:xxxxx@ntdev…
From the Windbg documentation:
…
Comments
This is a kernel internal error which can occur only on a checked build.
This error occurs on exit from a system call.
Note that this is no longer correct, not sure when it changed exactly but
this crash is now present in the free build. Note that the online docs (and
the Win8 Consumer Preview WinDBG docs) have been updated to remove this
comment.
These are a pain to track down due to the fact that most of the state that
you need is gone by the time the bugcheck happens. Starting in Vista,
Verifier actually logs APC index changes (you can dump it with !verifier
200), though the last time I had one of these the log was so huge that I
ended up finding the bug using other means.
To the OP: Look out for any unmatched KeEnterCriticalRegion (do you use
ERESOURCEs?) or KeStackAttachProcess calls.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
Scott and Don,
Thanks for the replies. I don’t use critical sections explicitly but I do use mutex objects, which
according to the documentation automatically enter the thread into a critical region.
I just learned that they are reentrant, and since that is not my intention and usage, I will change them all to events. That way any bug will immediately show up as a hang.
thanks again,
Massoud
Are you using kmdf? Kmdf will enter a critical region for wdfwaitlock.
d
debt from my phone
From: xxxxx@yahoo.com
Sent: 4/26/2012 1:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Drivers and APCs
Scott and Don,
Thanks for the replies. I don’t use critical sections explicitly but I do use mutex objects, which
according to the documentation automatically enter the thread into a critical region.
I just learned that they are reentrant, and since that is not my intention and usage, I will change them all to events. That way any bug will immediately show up as a hang.
thanks again,
Massoud
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
> I just learned that they are reentrant, and since that is not my intention and usage, I will change them
all to events.
FAST_MUTEX is even better.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Maxim,
But if FAST_MUTEX raises my irql above passive, i’d better stay with events.
This driver is huge and I don’t know everything about it. Passive is safer.
There’s no “if” invlolved here. RTFM. It explicitly says that the IRQL
is raised to APC_LEVEL with APCs disabled until the fast mutex is
released. Using a regular mutex is more expensive but is more forgiving,
although it was not immediately clear what “special kernel APCs” were and
I didn’t follow links to find out.
joe
Thanks Maxim,
But if FAST_MUTEX raises my irql above passive, i’d better stay with
events.
This driver is huge and I don’t know everything about it. Passive is
safer.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Special Kernel mode APCs are i.e. those used to do copyout() upon
IoCompleteRequest if I recall correctly. It’s been a while since I have to
worry about that kind of stuff hence I could be wrong.
Calvin
On Sun, Apr 29, 2012 at 10:44 AM, wrote:
> There’s no “if” invlolved here. RTFM. It explicitly says that the IRQL
> is raised to APC_LEVEL with APCs disabled until the fast mutex is
> released. Using a regular mutex is more expensive but is more forgiving,
> although it was not immediately clear what “special kernel APCs” were and
> I didn’t follow links to find out.
> joe
>
> > Thanks Maxim,
> >
> > But if FAST_MUTEX raises my irql above passive, i’d better stay with
> > events.
> > This driver is huge and I don’t know everything about it. Passive is
> > safer.
> >
> > —
> > 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
>
> IRQL is raised to APC_LEVEL with APCs disabled until the fast
mutex is released. Using a regular mutex is more expensive
but is more forgiving
Whenever you acquire a lock in the kernel you should disable APCs anyway. Otherwise there is a risk that the caller could suspend the thread while it is holding the lock, and prevent other (more privileged) users from making progress.
>Special Kernel mode APCs are i.e. those used to do copyout() upon IoCompleteRequest
Yes. IopCompleteRequest.
I think this is the only special kernel APC.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Special kernel APCs just have different delivery restrictions than the other
two types of APCs (user and normal kernel), as outlined here:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff564853(v=vs.85).aspx
There are multiple different special kernel APCs used in the O/S, though as
driver writers we tend to only ever be affected by the I/O completion one.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
Special Kernel mode APCs are i.e. those used to do copyout() upon
IoCompleteRequest
Yes. IopCompleteRequest.
I think this is the only special kernel APC.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> There are multiple different special kernel APCs used in the O/S
Can you name a few?
For me, the very notion of “special” (instead of usual) APCs is to allow the CPU state (KeEnterCriticalRegion) where the “special” ones can be delivered and “usual” ones cannot. I see no practical purpose in this except allowing ZwXxxFile calls in this state, while still being free from usual APCs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>> There are multiple different special kernel APCs used in the O/S
Can you name a few?
It’s been a long time since I’ve looked in great detail, but doing a binary
cross reference check of the Win7 SP1 NT module shows (list not complete and
inferred usage based on my interpretation of the function names):
* Something apparently related to swapping worker thread stacks
* Something apparently related to changing/querying thread context
* Something apparently related to canceling queued I/O operations
For amusement I also put a conditional breakpoint in WinDBG, which found one
being used in AFD. A little spooky, but hey…
Note that this is strictly looking at the APC construction and, “knowing”
that they’re special based on undocumented APC details. Of course, this
doesn’t provide any information on the intention of these and why a normal
APC wasn’t sufficient (after all the interface *is* undocumented). However,
being a special kernel APC is a feature/implementation detail of the APC
API, thus it’s not something that is specifically reserved to
IopCompleteRequest.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
There are multiple different special kernel APCs used in the O/S
Can you name a few?
For me, the very notion of “special” (instead of usual) APCs is to allow the
CPU state (KeEnterCriticalRegion) where the “special” ones can be delivered
and “usual” ones cannot. I see no practical purpose in this except allowing
ZwXxxFile calls in this state, while still being free from usual APCs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com