Bug in NTFS (NtfsWriteUsnJournalChanges)

Meinolf Weber [MVP-DS]

2010-02-17 18:27:00 UTC

Hello Matt,

If you like to report a bug you should use the connect website for this:
https://connect.microsoft.com/default.aspx

They will take care of it and also give you information about the status.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

Post by Matt Yellen
I am running Windows 7 Enterprise. I have identified a bug in NTFS,
specifically NtfsWriteUsnJournalChanges. I am developing an NTFS
filter driver that redirects requests to multiple volumes and this
seems to have exacerbated the bug.
The version of NTFS.sys is 6.1.7600.16385
Modification date: 7/13/2009 9:20 PM
From tracing through the disassembly I have determined that
NtfsWriteUsnJournalChanges is processing records in a loop. The first
time through the loop a lock is aquired and then released. The second
time through the lock is released (KeReleaseMutex) without ever being
acquired and this causes the function to fail with
STATUS_MUTANT_NOT_OWNED.
I have been working with a Microsoft MVP with access to the source,
and he believes the problem I am seeing is due to a boolean which is
not properly cleared when the lock is released the first time through
the loop.
Can you confirm that what I am describing is in fact a bug in NTFS?
If so, is a hotfix available? If none is available woudl it be
possible to get a hotfix and when might that be released?
If it is at all helpful here is the full stack trace to the point

kd>> kv
kd>>

Post by Matt Yellen
ChildEBP RetAddr Args to Child
93e17934 8164c6ba 845a7f20 00000001 00000000 nt!KeReleaseMutant+0x20f
93e1794c 87b163c1 845a7f20 00000000 87b1636a nt!KeReleaseMutex+0x14
93e17958 87b1636a 144b82da 845a70d8 8342e008
Ntfs!NtfsWriteUsnJournalChanges+0x206 (FPO: [SEH])
93e179a4 87b19a01 8342e008 8a49de80 8342e008
Ntfs!NtfsWriteUsnJournalChanges+0x1b4 (FPO: [SEH])
93e179b8 87b2612f 8342e008 144b8076 0000000b
Ntfs!NtfsCheckpointCurrentTransaction+0x1b (FPO: [1,0,0])
93e17b08 87b1edc7 8342e008 8353b3f0 845a70d8
Ntfs!NtfsSetLinkInfo+0xb33
(FPO: [SEH])
93e17b84 87a8b32b 8342e008 8353b3f0 144b808e
Ntfs!NtfsCommonSetInformation+0x658 (FPO: [SEH])
93e17bf0 816484bc 845a7020 8353b3f0 8353b3f0
Ntfs!NtfsFsdSetInformation+0x107 (FPO: [SEH])
93e17c08 87a3220c 846bc020 8353b3f0 00000000 nt!IofCallDriver+0x63
93e17c2c 87a323cb 93e17c4c 846bc020 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa (FPO: [3,4,4])
[2,6,4])
93e17c7c 8185c8f3 f95d001e 00000610 0091eecc nt!IofCallDriver+0x63
93e17d18 8164f42a 00000610 0091f010 000e25f8
nt!NtSetInformationFile+0xa3f
[0,0,0])
0091eeb0 73b886d6 00000610 0091f010 000e25f8
ntdll!ZwSetInformationFile+0xc
(FPO: [5,0,0])
0091efc0 73b96274 00001dbb 00000610 0091f010
wcp!Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysS
etInformationFile+0x139 (FPO: [7,58,4])
0091f088 73b96f84 0000e1b7 00000001 0091f20c
wcp!Windows::Rtl::SystemImplementation::CSystemIsolationLayer::CreateH
ardLinkA+0x586 (FPO: [6,38,0])
0091f0bc 73b84f76 00000000 00000003 016b60d4
wcp!Windows::Rtl::SystemImplementation::CSystemIsolationLayer::Transfe
rFile+0xda (FPO: [7,2,4])
0091f1c8 73c1f354 00001c85 00000003 016b60d4
wcp!Windows::Rtl::SystemImplementation::CSystemIsolationLayer_IRtlSyst
emIsolationLayerTearoff::TransferFile+0x154 (FPO: [7,55,4])