BSOD REFERENCE_BY_POINTER

NTFSD
1

Dear All,

We need to find out the proper location for calling ZwClose and

ObDereferenceObject calls. During driver initialization we get the device

object using the following routines

ZwOpenFile
ObReferenceObjectByHandle
IoGetRelatedDeviceObject

During the driver lifetime we cannot call ObDereferenceObject on the file

object because we need it in calls for read/write IRPs and Device Control

requests. The best place seems to be in shutdown routine as no more requests

need to be generated. But calling ObDerefernceObject there causes BSOD

REFERENCE_BY_POINTER.

Need help in resolving this issue. If ObDereferenceObject on file object is

not called then the file system check runs on next boot due to open handle.

Thanks,
Uzair Lakhani

2

Hi Uzair,

Each successful call to ZwOpenFile needs a ZwClose to release system resources.

When you do a ObReferenceObjectByHandle on any handle, it increments the object’s pointer counter and it’ll require a ObDeferenceObject to undo that.

Even after getting the file object reference, you must keep its handle opened because some of the IO requests need to happen before the IRP_MJ_CLEANUP be sent to the file system.

IoGetRelatedDeviceObject doesn’t increment any object counter because it relies on the indirect file object reference. So, the device object returned by this function will be valid as long as the file object is, but you can also hold an extra reference to the device by calling ObReferenceObject if you intend to continue using the device after dereferencing the file object. Obviously, by acquiring an extra reference, you should call ObDereferenceObject when you don’t need the device object any more.

So, the sequence would be the following (I’m not checking for errors yo make the code smaller, but don’t forget doing so):

nts = ZwOpenFile(&hFile,
FILE_READ_ATTRIBUTES,
&ObjAttributes,
&iosb,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
0);

nts = ObReferenceObjectByHandle(hFile,
0,
*IoFileObjectType,
KernelMode,
(PVOID*)&pFileObj,
NULL);

pDeviceObj = IoGetRelatedDeviceObject(pFileObj);

//-f–> Do whatever you need for the time you need.

ObDereferenceObject(pFileObj);

ZwClose(hFile);

You can also use !handle and !object WinDbg extensions to help you to understand this.

Regards,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

3

Given the level of detail provided, all I can do is quote the documentation:

Post the output of !analyze -v if you want a chance of getting more help.
Even then, the bug check is pretty clear.

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Dear All,

We need to find out the proper location for calling ZwClose and

ObDereferenceObject calls. During driver initialization we get the device

object using the following routines

ZwOpenFile
ObReferenceObjectByHandle
IoGetRelatedDeviceObject

During the driver lifetime we cannot call ObDereferenceObject on the file

object because we need it in calls for read/write IRPs and Device Control

requests. The best place seems to be in shutdown routine as no more requests

need to be generated. But calling ObDerefernceObject there causes BSOD

REFERENCE_BY_POINTER.

Need help in resolving this issue. If ObDereferenceObject on file object is

not called then the file system check runs on next boot due to open handle.

Thanks,
Uzair Lakhani

4

Dear All,

First thanks for replying to the query. The problem is that I cannot call ObReferenceObjectByHandle and ObDereferenceObject in the same routine. The problem is that I need file object for IO_STACK_LOCATION file object field for read/write and device control requests so I cannot call ObDereferenceObject earlier.

As the remove request IRP_MN_REMOVE_DEVICE does not come for my driver as it remains installed on the system so I called the ObDerefenceObject in my shutdown routine as that seem to be the ideal point but it is causing the BSOD.

I think the shutdown routine is not the proper place for calling the ObDerefernceObject routine. Any input will be helpful for me.

Thanks,
Uzair Lakhani

5

Hi Uzair,

I’m not quite sure if that can help you, but you can receive plug-and-play notifications by using the IoRegisterPlugPlayNotification routine.

What are you trying to do? Do you need a file to be opened by the time the machine is turned on? Are you writing to this file from time to time?

Regards,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

6

Dear Fernando,

Thanks for the reply. Basically this problem is part of a problem. The complete problem is posted in another thread named File System Corruption Issue. The problem is that we have created a virtual device like X: in My Computer. Since this device is virtual so in order to handle read/write and device control requests for X: we forward the incoming requests to for example some other disk partition like D: so we need to open D: all the time until the system is shutdown so that the requests for X: can be forwarded to D:

Basically we are getting some file system related issues on the actual disk partition that was our target for read/write and device control requests. Although sometimes the file system check could not find any issues and some times it finds index related and MFT related errors.

Thanks,
Uzair Lakhani

7

>installed on the system so I called the ObDerefenceObject in my shutdown routine as that seem to be

the ideal point but it is causing the BSOD.

What is the need of freeing anything in shutdown? the machine will soon be gone.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Dear Maxim,

Thanks for be part of the discussion. Basically I need to release all locks on the target disk partition mentioned as D: in the last post. If all the handles are not closed using ZwClose and all the references are not dereferenced using ObDereferenceObject then I think the dirty bit for the target partition will be remained set and that will cause a file system check on reboot which I want to avoid.

I thought that two points can be where ObDereferenceObject and ZwClose can be called. One when the driver is going to be removed using IRP_MN_REMOVE_DEVICE and the other point will be at shutdown IRP_MJ_SHUTDOWN. Since the remove function will not be called in our case so I put the ObDereferenceObject and ZwClose routines in shutdown routine.

Hope I am able to clarify my point.

Thanks,
Uzair Lakhani

9

Dear Members,

Do I need to provide more details for the problem resolution.

Thanks,
Uzair Lakhani

10

To clarify your previous post, SHUTDOWN notification is just that, an
indication of when the system is shutting down. It does not indicate
your device is getting dismounted and you should tear down the stack.
Only during the PnP REMOVE_DEVICE processing is the file system stack
removed, in most cases.

That said, you can attempt to flush as much data out to disk during a
shutdown request but it is possible to still receive further requests
after the shutdown notification.

Pete

On 4/27/2013 1:18 AM, xxxxx@gmail.com wrote:

Dear Members,

Do I need to provide more details for the problem resolution.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

11

Dear Peter,

Thanks for your input. Basically in the beginning of the shutdown routine we call IoReleaseRemoveLockAndWait. By this the new incoming read/write and device control requests on X: will fail. Since no more requests need to be handled for X: so the original disk partition handle can be released for avoiding the file system check.

Thanks,
Uzair Lakhani

12

Are you performing this on the dispatch or completion side of the
IRP_MJ_SHUTDOWN request?

Pete

On 4/27/2013 8:13 AM, xxxxx@gmail.com wrote:

Dear Peter,

Thanks for your input. Basically in the beginning of the shutdown routine we call IoReleaseRemoveLockAndWait. By this the new incoming read/write and device control requests on X: will fail. Since no more requests need to be handled for X: so the original disk partition handle can be released for avoiding the file system check.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

13

Dear Peter,

Thanks for participating in the thread. I am performing this in dispatch routine. That is the routine registered in DriverEntry for IRP_MJ_SHUTDOWN.

Thanks,
Uzair Lakhani

14

As Scott has previously requested, possibly posting the output of the
!analyze -v from WinDbg will provide more insight into the crash.

Pete

On 4/28/2013 5:16 AM, xxxxx@gmail.com wrote:

Dear Peter,

Thanks for participating in the thread. I am performing this in dispatch routine. That is the routine registered in DriverEntry for IRP_MJ_SHUTDOWN.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

15

Dear Members,

Please find below debug messages:

Dump uploaded successfully. Please stand by while we perform the analysis.

Instant Online Crash Analysis, brought to you by OSR Open Systems Resources, Inc.While you’re waiting, why not check out: ?OSR’s Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window) ?OSR’s WDF Driver Development Seminar (opens in new tab/window)

Instant Online Crash Analysis, brought to you by OSR Open Systems Resources, Inc.
Primary Analysis
Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82a51000 PsLoadedModuleList = 0x82b99810
Debug session time: Mon Apr 29 01:40:16.557 2013 (UTC - 4:00)
System Uptime: 0 days 0:01:26.915
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 00000000, Object type of the object whose reference count is being lowered
Arg2: 867914a8, Object whose reference count is being lowered
Arg3: 00000002, Reserved
Arg4: ffffffff, 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:

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x18

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 82ab9f22 to 82b2dd10

STACK_TEXT:
8c37bcb4 82ab9f22 00000018 00000000 867914a8 nt!KeBugCheckEx+0x1e
8c37bcd8 82ab9ed0 867914a8 8fda074d 8c37bd28 nt!ObfDereferenceObjectWithTag+0x4b
8c37bce0 8fda074d 8c37bd28 8666dea8 ff676980 nt!ObfDereferenceObject+0xd
WARNING: Stack unwind information not available. Following frames may be wrong.
8c37bcf8 82a8d4bc 8666dea8 85b33bc0 8a7789f8 DTSC4Own+0x174d
8c37bd10 8861f91c 8a778958 8c37bd34 82ac110e nt!IofCallDriver+0x63
8c37bd1c 82ac110e 8a7789f8 00000000 ffffffff Ntfs!NtfsStorageDriverCallout+0x14
8c37bd1c 82ac1205 8a7789f8 00000000 ffffffff nt!KiSwapKernelStackAndExit+0x15a
8a778968 00000000 00000000 00000000 00000000 nt!KiSwitchKernelStackAndCallout+0x31

STACK_COMMAND: kb

FOLLOWUP_IP:
DTSC4Own+174d
8fda074d ?? ???

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: DTSC4Own+174d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: DTSC4Own

IMAGE_NAME: DTSC4Own.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 517e0733

FAILURE_BUCKET_ID: 0x18_OVER_DEREFERENCE_DTSC4Own+174d

BUCKET_ID: 0x18_OVER_DEREFERENCE_DTSC4Own+174d

Followup: MachineOwner

This free analysis is provided by OSR Open Systems Resources, Inc.

Thanks,
Uzair Lakhani

16

Dear Members,

Do I need to provide more details for the problem resolution.

Thanks,
Uzair Lakhani

17

From the crash information you provided the object being dereferenced
is invalid. So either you have already dereferenced the object or it is
an invalid object altogether.

I would go through your code and ensure that the object being
dereferenced is the correct object and you have not already dereferenced
it somewhere else.

Pete

On 4/30/2013 12:59 AM, xxxxx@gmail.com wrote:

Dear Members,

Do I need to provide more details for the problem resolution.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

18

Dear Peter,

In my code I have not dereferenced the object earlier. If by mistake I had dereferenced the object earlier then my device control request to the file system device object would return STATUS_INVALID_PARAMETER and due to which I will not be able to open my virtual device.

Since X: is virtual therefore requests like IOCTL_DISK_CHECK_VERIFY, IOCTL_DISK_GET_PARTITION_INFO_EX, IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_STORAGE_GET_HOTPLUG_INFO etc need to be forwarded to the disk partition using file system device object I have. But if the file object is dereferenced before then IoCallDriver for device control requests would return STATUS_INVALID_PARAMETER.

Previously I was dereferencing the file object earlier and was getting the said status. Therefore I comment that line that was dereferencing the file object and the STATUS_INVALID_PARAMETER status stopped coming. But now I am looking for a proper place for ObDerefenceObject and found shutdown to be the ideal point which is giving REFERENCE_BY_POINTER BSOD.

Thanks,
Uzair Lakhani

19

Are you possibly processing things multiple times? You may be receiving
more than one IRP_MJ_SHUTDOWN if you have allocated more than one device
object.

Pete

On 4/30/2013 8:20 AM, xxxxx@gmail.com wrote:

Dear Peter,

In my code I have not dereferenced the object earlier. If by mistake I had dereferenced the object earlier then my device control request to the file system device object would return STATUS_INVALID_PARAMETER and due to which I will not be able to open my virtual device.

Since X: is virtual therefore requests like IOCTL_DISK_CHECK_VERIFY, IOCTL_DISK_GET_PARTITION_INFO_EX, IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_STORAGE_GET_HOTPLUG_INFO etc need to be forwarded to the disk partition using file system device object I have. But if the file object is dereferenced before then IoCallDriver for device control requests would return STATUS_INVALID_PARAMETER.

Previously I was dereferencing the file object earlier and was getting the said status. Therefore I comment that line that was dereferencing the file object and the STATUS_INVALID_PARAMETER status stopped coming. But now I am looking for a proper place for ObDerefenceObject and found shutdown to be the ideal point which is giving REFERENCE_BY_POINTER BSOD.

Thanks,
Uzair Lakhani

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

20

Dear Scott,

Thanks for your input. I think you are right and my shutdown routine is called twice. I confirmed this by placing a custom bug check after ObDereferenceObject. Now at restart time my custom bug check is coming. It means that the BSOD REFERENCE_BY_POINTER is not coming first time but I think at second time.

What can be the reason for the shutdown call for more than one time and how can I resolve it.

Thanks,
Uzair Lakhani