I have a user mode file system that is working fine in normal case. But in case when a file is opened and operation are going on the file and user mode file system process get killed I see a Bug Check 0x18: REFERENCE_BY_POINTER.
This is what im doing when user mode file system process gets killed…
- Delete Symbolic link
- Lock the file system VCB.
- Mark file sytem VCB as Unmounted (will stop from getting more request)
- Release all pending IRP.
- Release all FCB,CCB
- Delete File System Device Object
Am i missing something? Why there is a bug check. Normal dismount works fine (No BugCheck).
This should be manageable to track if you look maybe at the stack in the
!analyze -v output.
Maybe you can share it with us as well.
Regards,
Gabriel
www.kasardia.com
Windows Driver Consulting
On Fri, Apr 22, 2016 at 9:56 AM, wrote:
> I have a user mode file system that is working fine in normal case. But in
> case when a file is opened and operation are going on the file and user
> mode file system process get killed I see a Bug Check 0x18:
> REFERENCE_BY_POINTER.
>
> This is what im doing when user mode file system process gets killed…
> - Delete Symbolic link
> - Lock the file system VCB.
> - Mark file sytem VCB as Unmounted (will stop from getting more request)
> - Release all pending IRP.
> - Release all FCB,CCB
> - Delete File System Device Object
>
> Am i missing something? Why there is a bug check. Normal dismount works
> fine (No BugCheck).
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Bercea. G.</http:>
This is the analysis…
REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: ffffe000948035b0, Object whose reference count is being lowered
Arg3: 0000000000000006, Reserved
Arg4: ffffffffffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object’s reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object?s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.
Debugging Details:
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x18
PROCESS_NAME: wmplayer.exe
CURRENT_IRQL: 2
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
LAST_CONTROL_TRANSFER: from fffff80079be4a46 to fffff80079b61b90
STACK_TEXT:
ffffd0002a6de0c8 fffff80079be4a46 : 0000000000000000 0000000000000000 ffffd0002a6de230 fffff80079a518cc : nt!DbgBreakPointWithStatus
ffffd0002a6de0d0 fffff80079be4357 : 0000000000000003 0000000000000000 fffff80079b68f80 0000000000000018 : nt!KiBugCheckDebugBreak+0x12
ffffd0002a6de130 fffff80079b5b0a4 : ffffe000948035b0 ffffe00093bf6310 ffffe00092c33500 ffffe00095bc79e0 : nt!KeBugCheck2+0x8ab
ffffd0002a6de840 fffff80079b9285a : 0000000000000018 0000000000000000 ffffe000948035b0 0000000000000006 : nt!KeBugCheckEx+0x104
ffffd0002a6de880 fffff80079df992f : ffffe00095bc79e0 0000000000000000 ffffe000907b66d0 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x273aa ffffd0002a6de8c0 fffff80079e1b004 : 0000000000000000 ffffe00095bc79e0 ffffe00090328080 ffffe00095bc79b0 : nt!IopDeleteFile+0x19b ffffd0002a6de940 fffff80079a6db8f : 0000000000000000 ffffd0002a6dea99 ffffe00095bc79e0 ffffe00090328080 : nt!ObpRemoveObjectRoutine+0x64 ffffd0002a6de9a0 fffff80079df8c24 : ffffe00095bc79b0 00000000ffff8010 0000000000007ff0 0000000000007ff0 : nt!ObfDereferenceObjectWithTag+0x8f ffffd0002a6de9e0 fffff80079b667b3 : ffffe00092c33080 00000000000005cc 0000000000f1fdb0 0000000000f5d75c : nt!NtClose+0x204 ffffd0002a6deb00 00000000770c2772 : 00000000770c2738 000000237717da4c 0000000000000023 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 0000000000f1e728 00000000770c2738 : 000000237717da4c 0000000000000023 0000000000000000 0000000000f5d59c : wow64cpu!CpupSyscallStub+0x2 0000000000f1e730 000000007708323a : 0000000000000000 00000000770c1503 0000000000000000 0000000077083420 : wow64cpu!Thunk0Arg+0x5 0000000000f1e7e0 000000007708317e : 0000000000000000 0000000000000000 0000000000f1fd30 0000000000f1f150 : wow64!RunCpuSimulation+0xa 0000000000f1e830 00007ffd56a0f15b : 0000000000df00d0 0000000000000000 0000000000000010 000000007ed53000 : wow64!Wow64LdrpInitialize+0x172 0000000000f1ed70 00007ffd569fa188 : 00007ffd56940000 0000000000000000 0000000000000000 000000007ed53000 : ntdll!LdrpInitializeProcess+0x157b 0000000000f1f090 00007ffd56996a5a : 0000000000f1f150 0000000000000000 0000000000000000 000000007ed53000 : ntdll!_LdrpInitialize+0x636dc 0000000000f1f100 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe
Ok a good step 1.
What does
!object ffffe000948035b0
show in the debugger ?
Regards,
Gabriel Bercea
www.kasardia.com
Windows Kernel Driver Consultant
On Fri, Apr 22, 2016 at 2:41 PM, wrote:
> This is the analysis…
>
> REFERENCE_BY_POINTER (18)
> Arguments:
> Arg1: 0000000000000000, Object type of the object whose reference count is
> being lowered
> Arg2: ffffe000948035b0, Object whose reference count is being lowered
> Arg3: 0000000000000006, Reserved
> Arg4: ffffffffffffffff, Reserved
> The reference count of an object is illegal for the current state
> of the object.
> Each time a driver uses a pointer to an object the driver calls a
> kernel routine
> to increment the reference count of the object. When the driver is
> done with the
> pointer the driver calls another kernel routine to decrement the
> reference count.
> Drivers must match calls to the increment and decrement routines.
> This bugcheck
> can occur because an object’s reference count goes to zero while
> there are still
> open handles to the object, in which case the fourth parameter
> indicates the number
> of opened handles. It may also occur when the object’s reference
> count drops below zero
> whether or not there are open handles to the object, and in that
> case the fourth parameter
> contains the actual value of the pointer references count.
>
> Debugging Details:
> ------------------
>
>
> DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
>
> BUGCHECK_STR: 0x18
>
> PROCESS_NAME: wmplayer.exe
>
> CURRENT_IRQL: 2
>
> ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
>
> LAST_CONTROL_TRANSFER: from fffff80079be4a46 to fffff80079b61b90
>
> STACK_TEXT:
> ffffd0002a6de0c8 fffff80079be4a46 : 0000000000000000 0000000000000000
> ffffd0002a6de230 fffff80079a518cc : nt!DbgBreakPointWithStatus
> ffffd0002a6de0d0 fffff80079be4357 : 0000000000000003 0000000000000000
> fffff80079b68f80 0000000000000018 : nt!KiBugCheckDebugBreak+0x12
> ffffd0002a6de130 fffff80079b5b0a4 : ffffe000948035b0 ffffe00093bf6310
> ffffe00092c33500 ffffe00095bc79e0 : nt!KeBugCheck2+0x8ab
> ffffd0002a6de840 fffff80079b9285a : 0000000000000018 0000000000000000
> ffffe000948035b0 0000000000000006 : nt!KeBugCheckEx+0x104
> ffffd0002a6de880 fffff80079df992f : ffffe00095bc79e0 0000000000000000
> ffffe000907b66d0 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x273aa<br>> ffffd0002a6de8c0 fffff80079e1b004 : 0000000000000000 ffffe00095bc79e0<br>> ffffe00090328080 ffffe00095bc79b0 : nt!IopDeleteFile+0x19b<br>> ffffd0002a6de940 fffff80079a6db8f : 0000000000000000 ffffd0002a6dea99<br>> ffffe00095bc79e0 ffffe00090328080 : nt!ObpRemoveObjectRoutine+0x64<br>> ffffd0002a6de9a0 fffff80079df8c24 : ffffe00095bc79b0 00000000ffff8010<br>> 0000000000007ff0 0000000000007ff0 : nt!ObfDereferenceObjectWithTag+0x8f<br>> ffffd0002a6de9e0 fffff80079b667b3 : ffffe00092c33080 00000000000005cc<br>> 0000000000f1fdb0 0000000000f5d75c : nt!NtClose+0x204<br>> ffffd0002a6deb00 00000000770c2772 : 00000000770c2738 000000237717da4c<br>> 0000000000000023 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13<br>> 0000000000f1e728 00000000770c2738 : 000000237717da4c 0000000000000023<br>> 0000000000000000 0000000000f5d59c : wow64cpu!CpupSyscallStub+0x2<br>> 0000000000f1e730 000000007708323a : 0000000000000000 00000000770c1503<br>> 0000000000000000 0000000077083420 : wow64cpu!Thunk0Arg+0x5<br>> 0000000000f1e7e0 000000007708317e : 0000000000000000 0000000000000000<br>> 0000000000f1fd30 0000000000f1f150 : wow64!RunCpuSimulation+0xa<br>> 0000000000f1e830 00007ffd56a0f15b : 0000000000df00d0 0000000000000000<br>> 0000000000000010 000000007ed53000 : wow64!Wow64LdrpInitialize+0x172<br>> 0000000000f1ed70 00007ffd569fa188 : 00007ffd56940000 0000000000000000<br>> 0000000000000000 000000007ed53000 : ntdll!LdrpInitializeProcess+0x157b<br>> 0000000000f1f090 00007ffd56996a5a : 0000000000f1f150 0000000000000000<br>> 0000000000000000 000000007ed53000 : ntdll!_LdrpInitialize+0x636dc<br>> 0000000000f1f100 0000000000000000 : 0000000000000000 0000000000000000<br>> 0000000000000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Bercea. G.</http:>
Object: ffffe000948035b0 Type: (ffffd00060cee000)
ObjectHeader: ffffe00094803580 (new version)
HandleCount: 0 PointerCount: 0
Directory Object: 00000000 Name: (*** Name not accessible ***)
Look at what FASTFAT does on media removal and do the same.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
>I have a user mode file system that is working fine in normal case. But in case when a file is opened and operation are going on the file and user mode file system process get killed I see a Bug Check 0x18: REFERENCE_BY_POINTER.
>
> This is what im doing when user mode file system process gets killed…
> - Delete Symbolic link
> - Lock the file system VCB.
> - Mark file sytem VCB as Unmounted (will stop from getting more request)
> - Release all pending IRP.
> - Release all FCB,CCB
> - Delete File System Device Object
>
> Am i missing something? Why there is a bug check. Normal dismount works fine (No BugCheck).
>
That is exactly what I was about to suggest next.
Basically, look at the whole fastfat and when in doubt try to replicate or
duplicate the behavior.
I will go through the architecture of the UMFS this weekend myself and maybe
suggest something better but till then just see how a real life FS is
implemented and how it handles these cases.
Regards,
Gabriel Bercea
Windows Kernel Driver Consulting
www.kasardia.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, 22 April, 2016 21:14
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Accidental removal of file system casuses
REFERECE_BY_PONTER BugCheck .
Look at what FASTFAT does on media removal and do the same.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
>I have a user mode file system that is working fine in normal case. But in
case when a file is opened and operation are going on the file and user mode
file system process get killed I see a Bug Check 0x18: REFERENCE_BY_POINTER.
>
> This is what im doing when user mode file system process gets killed…
> - Delete Symbolic link
> - Lock the file system VCB.
> - Mark file sytem VCB as Unmounted (will stop from getting more
> request)
> - Release all pending IRP.
> - Release all FCB,CCB
> - Delete File System Device Object
>
> Am i missing something? Why there is a bug check. Normal dismount works
fine (No BugCheck).
>
—
NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:>
REFERENCE_BY_POINTER happens if you decrement the reference count of an object below zero (or increment the count from 0-1, but that’s not the case here).
In this case, the I/O Manager is trying to send an IRP_MJ_CLOSE (IopDeleteFile) and in doing so has decremented the reference count of an object to zero. Can’t tell which object it is from this output because the object is already deleted, though it is going to be either a file object or a device object.
So, you’ve torn something down prematurely. You can’t just arbitrarily delete your state in the file system, deletion needs to be delayed until all reference counts go to zero. For a user mode file system you have to treat service exit as a special case of dismount of the file system, hence the previous comments.
First step I would recommend would be to enable Driver Verifier on your driver *and* the NT module. This will cause your device and file objects to come out of Special Pool, which will give you instant crashes if you’re deleting objects prematurely. You can then run !verifier 80 to see the call stack of where you freed the object.
-scott
OSR
@OSRDrivers
Thanks to everyone… Again OSR saved my time and effort … I have found the root cause…Thanks to all
For the archives, what was the solution?
(xkcd summarizes this situation nicely: http://xkcd.com/979/)
-scott
OSR
@OSRDrivers