Prev: Updating UMDF drivers during development
Next: Diplay driver architecture - Direct3D, OpenGL or both?
From: Priya on 3 Jan 2010 22:10
Hi,

I am working on a Windows filesystem driver and I'm seeing a deadlock
problem with 2 ERESOURCES.

I have an ERESOURCE field for each Volume Control Block (VCB) that I use in
the driver and another one for each File Control Block (FCB). In my testing
there is only one VCB and multiple FCBs since I use a single volume and
simultaneously access several files on that volume. Both the locks are
required for certain file operations. Most of the time this works OK, but
sometimes the driver hangs with a deadlock.

I added some logging and reference counting to verify that my driver code is
acquiring and releasing the locks in the right order. According to the logs,
one of the driver threads holds the VCB lock and is waiting indefinitely for
an FCB lock which is not owned by any other thread. Since all threads
eventually need the VCB lock they all end up waiting indefinitely for it.

I tried forcing a crash dump and analysing the dump file. This shows that
the system thinks the FCB lock of interest is still being held by the thread
which last released it. Can anyone tell me under what scenario this can
happen?

Next I tried stepping through the driver code using WinDbg. I set a "Break
on write access" on the OwnerEntry.OwnerCount field of the ERESOURCE lock of
one particular FCB and repeatedly performed operations on that file. Most of
the time when this breakpoint was hit, it was in my driver code as expected.
However couple of times, when the breakpoint was hit the call stack did not
look familiar. The function at the bottom of the call stack was
RHDosPathNameToRelativeNTPathName_U. This is not used in my code and I have
not been able to find any information on it on the Internet. Does anybody
have more information about this function or any idea what could be going on?
I can post the complete call stack if necessary.

I have run out of things to try at this point to debug this problem. So any
suggestions or information provided will be greatly appreciated.

Thank you for your help.

Regards,
Priya

From: David Craig on 3 Jan 2010 22:45
Ask this question in the correct newsgroup. File systems and file system
filters are not handled in this newsgroup. NTFSD at osronline.com is the
only newsgroup for file system questions.

"Priya" <Priya(a)discussions.microsoft.com> wrote in message
news:93F4A71D-E9F3-44E5-AB2D-12AF5BB812EB(a)microsoft.com...
> Hi,
>
> I am working on a Windows filesystem driver and I'm seeing a deadlock
> problem with 2 ERESOURCES.
>
> I have an ERESOURCE field for each Volume Control Block (VCB) that I use
> in
> the driver and another one for each File Control Block (FCB). In my
> testing
> there is only one VCB and multiple FCBs since I use a single volume and
> simultaneously access several files on that volume. Both the locks are
> required for certain file operations. Most of the time this works OK, but
> sometimes the driver hangs with a deadlock.
>
> I added some logging and reference counting to verify that my driver code
> is
> acquiring and releasing the locks in the right order. According to the
> logs,
> one of the driver threads holds the VCB lock and is waiting indefinitely
> for
> an FCB lock which is not owned by any other thread. Since all threads
> eventually need the VCB lock they all end up waiting indefinitely for it.
>
> I tried forcing a crash dump and analysing the dump file. This shows that
> the system thinks the FCB lock of interest is still being held by the
> thread
> which last released it. Can anyone tell me under what scenario this can
> happen?
>
> Next I tried stepping through the driver code using WinDbg. I set a "Break
> on write access" on the OwnerEntry.OwnerCount field of the ERESOURCE lock
> of
> one particular FCB and repeatedly performed operations on that file. Most
> of
> the time when this breakpoint was hit, it was in my driver code as
> expected.
> However couple of times, when the breakpoint was hit the call stack did
> not
> look familiar. The function at the bottom of the call stack was
> RHDosPathNameToRelativeNTPathName_U. This is not used in my code and I
> have
> not been able to find any information on it on the Internet. Does anybody
> have more information about this function or any idea what could be going
> on?
> I can post the complete call stack if necessary.
>
> I have run out of things to try at this point to debug this problem. So
> any
> suggestions or information provided will be greatly appreciated.
>
> Thank you for your help.
>
> Regards,
> Priya
>


From: Priya on 4 Jan 2010 03:44
Hi David,

Thank you for taking the time to respond to my question. I have posted this
in the NTFSD forum.

Thanks,
Priya


"David Craig" wrote:

> Ask this question in the correct newsgroup. File systems and file system
> filters are not handled in this newsgroup. NTFSD at osronline.com is the
> only newsgroup for file system questions.

From: Maxim S. Shatskih on 4 Jan 2010 04:47
> one of the driver threads holds the VCB lock and is waiting indefinitely for
> an FCB lock which is not owned by any other thread

This means you have no proper locking hieararchy.

Eliminate all cases from your code where FCB locks are acquired with VCB lock already held.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Priya on 4 Jan 2010 11:31
Hi Maxim,

Thank you for the suggestion. I will try that out.

Thanks,
Priya


"Maxim S. Shatskih" wrote:

> > one of the driver threads holds the VCB lock and is waiting indefinitely for
> > an FCB lock which is not owned by any other thread
>
> This means you have no proper locking hieararchy.
>
> Eliminate all cases from your code where FCB locks are acquired with VCB lock already held.
>
> --
> Maxim S. Shatskih
> Windows DDK MVP
> maxim(a)storagecraft.com
> http://www.storagecraft.com
>
> .
>
 |  Next  |  Last
Pages: 1 2
Prev: Updating UMDF drivers during development
Next: Diplay driver architecture - Direct3D, OpenGL or both?