Deadlock problem with ERESOURCEs in filesystem driver

Priya

unread,

Jan 3, 2010, 10:10:01 PM1/3/10

to

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

David Craig

unread,

Jan 3, 2010, 10:45:42 PM1/3/10

to

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" <Pr...@discussions.microsoft.com> wrote in message
news:93F4A71D-E9F3-44E5...@microsoft.com...

Priya

unread,

Jan 4, 2010, 3:44:01 AM1/4/10

to

Hi David,

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

Thanks,
Priya

Maxim S. Shatskih

unread,

Jan 4, 2010, 4:47:45 AM1/4/10

to

> 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
ma...@storagecraft.com
http://www.storagecraft.com

Priya

unread,

Jan 4, 2010, 11:31:01 AM1/4/10

to

Hi Maxim,

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

Thanks,
Priya

"Maxim S. Shatskih" wrote:

> .
>

Priya

unread,

Jan 5, 2010, 5:46:02 PM1/5/10

to

Hi Maxim,

Fixing the locking hierarchy seems to have eliminated the problem. I haven't
been able to recreate the deadlock in my preliminary testing. Thank you for
your help.

Thanks,
Priya

"Maxim S. Shatskih" wrote:

> .
>