Driver Left Locked Pages

NTDEV
1

One of my customer is facing bluescreen with Bug check 0xCB where our driver
is responsible.

Here is the flow.

  1. Customer application(app) calls one of our dll(mydll) (which is an
    interface to my driver1)
  2. mydll passes the app’s relevant data to mydriver1 through an ioctl call.
  3. mydriver1’s dispatch routine calls another function in mydriver1
  4. mydriver1 lock’s the data(passed from the application) through
    MmProbeandlockpages ddk api.
  5. after doing some processing mydriver1 unlocks this data and mark’s the
    irp complete.

In the above scenario we are facing the bugcheck 0xCB. I suspect this
because of a thread trap in the customer’s application or customer’s
application itself trapping leading to this situation before we could
complete the irp. Kindly clarify my following doubts.

  1. I am able to list all the pending irp’s through irpfind. All the irp’s
    pending over my driver points to the same thread id. I dumped the thread
    information using the command !thread [threadid] got from !irpfind command.
    The list of pending irp’s in this command is different from the irp’s I found
    through irpfind command. Can you please explain why is it different?
  2. All the irp’s through the !thread [threadid] matches with one of the
    thread of the customer’s process. Is there any other way to extract all the
    irp’s pending under my driver other than the !irpfind.
  3. How to identify for which thread/process the irp was created?
  4. Is there a possibility to identify the culprit process/thread which
    trapped that lead to the bluescreen.
  5. Can there any other reason in this scenario as why my driver should
    bluescreen with bugcheck 0xCB?

Regards,
Ramki

2

First, what do you mean by a thread “trapping”? Do you mean terminating, possibly due to an unhandled exception?

Whenever any thread terminates, the kernel cancels all of the IRPs that were started by that thread. IRP cancellation is tricky – there are a lot of race conditions to consider, and getting it right can be difficult. So if I were you, I would examine the IRP cancellation logic in your driver. (The fact that a DLL is involved is not important. DLL boundaries mean nothing to IRPs.) A thread cannot be destroyed (reclaimed, etc.) until all of the IRPs for that thread complete.

Before Doron says it, I’ll say it – If possible, consider porting your driver to KMDF / WDF. You’ll find that a lot of the design problems that are common but error-prone, such as IRP cancellation, are much easier under KMDF.

Also, run your driver with Driver Verifier enabled. You don’t say whether or not you are doing this, but if you aren’t, it’s important that you do so. You will find many problems with your driver that you would not ordinarily find. And in some situations, such as yours, you may find that you have better information about the problem, such as a bugcheck earlier, or closer to the root of the problem.

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com [xxxxx@yahoo.com]
Sent: Sunday, March 18, 2007 7:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Left Locked Pages

One of my customer is facing bluescreen with Bug check 0xCB where our driver
is responsible.

Here is the flow.

  1. Customer application(app) calls one of our dll(mydll) (which is an
    interface to my driver1)
  2. mydll passes the app’s relevant data to mydriver1 through an ioctl call.
  3. mydriver1’s dispatch routine calls another function in mydriver1
  4. mydriver1 lock’s the data(passed from the application) through
    MmProbeandlockpages ddk api.
  5. after doing some processing mydriver1 unlocks this data and mark’s the
    irp complete.

In the above scenario we are facing the bugcheck 0xCB. I suspect this
because of a thread trap in the customer’s application or customer’s
application itself trapping leading to this situation before we could
complete the irp. Kindly clarify my following doubts.

  1. I am able to list all the pending irp’s through irpfind. All the irp’s
    pending over my driver points to the same thread id. I dumped the thread
    information using the command !thread [threadid] got from !irpfind command.
    The list of pending irp’s in this command is different from the irp’s I found
    through irpfind command. Can you please explain why is it different?
  2. All the irp’s through the !thread [threadid] matches with one of the
    thread of the customer’s process. Is there any other way to extract all the
    irp’s pending under my driver other than the !irpfind.
  3. How to identify for which thread/process the irp was created?
  4. Is there a possibility to identify the culprit process/thread which
    trapped that lead to the bluescreen.
  5. Can there any other reason in this scenario as why my driver should
    bluescreen with bugcheck 0xCB?

Regards,
Ramki

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

3

Am i that predictable :slight_smile: ? I guess I should turn off the response bot.

d

4

> 4. mydriver1 lock’s the data(passed from the application) through

MmProbeandlockpages ddk api.

What is the need of this? Irp->MdlAddress is automatically probed and locked
for DO_DIRECT_IO devices, and - more so - automatically properly unlocked on
completion.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com