Is there a possibility of a reference count maintenance error with ObReferenceObjectByName?

My minfilter create a communication server port. A blue screen issue occurred after running for a while on win7 x64, and the cause was this port reference count less than 0. I started !obtrace and found that there is the following record for each abnormal count reduction:
kd> !obtrace fffffa80`1999a560

2bd35 -1 Dflt -3 -3
nt! ?? ::FNODOBFM::'string'+2246e
nt!ObfDereferenceObject+d4
nt!ObInsertObjectEx+12e
nt!ObInsertObject+22
FLTMGR!FltpOpenClientPort+3e5
FLTMGR!FltpMsgDispatch+f2
FLTMGR! ?? ::NNGAKEGL::`string'+2664
nt!IopParseDevice+14e2
nt!ObpLookupObjectName+784
nt!ObOpenObjectByName+306
nt!IopCreateFile+a08
nt!NtCreateFile+78
nt!KiSystemServiceCopyEnd+13

2bd36 -1 Dflt -4 -4
nt! ?? ::FNODOBFM::'string'+2246e
FLTMGR!FltpOpenClientPort+564
FLTMGR!FltpMsgDispatch+f2
FLTMGR! ?? ::NNGAKEGL::`string'+2664
nt!IopParseDevice+14e2
nt!ObpLookupObjectName+784
nt!ObOpenObjectByName+306
nt!IopCreateFile+a08
nt!NtCreateFile+78
nt!KiSystemServiceCopyEnd+13

kd> !object fffffa80`1999a560
Object: fffffa801999a560 Type: (fffffa8018e41400) FilterConnectionPort
ObjectHeader: fffffa801999a530 (new version)
HandleCount: 1 PointerCount: 0

It seems that ObInsertObject encountered an error 0xc000009A. Then the reference count is incorrectly decremented once.
Can someone give some suggestions?

I'm not sure how one could mess up the reference count on a Communication Port (unless you're calling FltCloseCommunicationPort more than once?).

Enable Driver Verifier with Standard Settings on your driver, FltMgr.sys, and Ntosrknl.exe then see what happens.

2bd07 +1 Dflt 0 0
nt! ?? ::FNODOBFM::"string'+126bd
nt!ObpLookupDirectoryUsingHash+a3
nt!ObpLookupDirectoryEntry+fc
nt!ObpLookupObjectName+57d
nt!ObReferenceObjectByName+11a
FLTMGR!FltpOpenClientPort+1d5
FLTMGR!FltpMsgDispatch+f2
FLTMGR! ?? ::NNGAKEGL::`string'+2664
nt!IopParseDevice+14e2
nt!ObpLookupObjectName+784
nt!ObOpenObjectByName+306
nt!IopCreateFile+a08
nt!NtCreateFile+78
nt!KiSystemServiceCopyEnd+13

2bd08 +1 Dflt 1 1
nt! ?? ::FNODOBFM::'string'+12cc1
nt!ObpLookupObjectName+96b
nt!ObReferenceObjectByName+11a
FLTMGR!FltpOpenClientPort+1d5
FLTMGR!FltpMsgDispatch+f2
FLTMGR! ?? ::NNGAKEGL::`string'+2664
nt!IopParseDevice+14e2
nt!ObpLookupObjectName+784
nt!ObOpenObjectByName+306
nt!IopCreateFile+a08
nt!NtCreateFile+78
nt!KiSystemServiceCopyEnd+13

2bd09 -1 Dflt 0 0
nt! ?? ::FNODOBFM::'string'+2246e
nt!ObReferenceObjectByName+1b8
FLTMGR!FltpOpenClientPort+1d5
FLTMGR!FltpMsgDispatch+f2
FLTMGR! ?? ::NNGAKEGL::`string'+2664
nt!IopParseDevice+14e2
nt!ObpLookupObjectName+784
nt!ObOpenObjectByName+306
nt!IopCreateFile+a08
nt!NtCreateFile+78
nt!KiSystemServiceCopyEnd+13

2bd0f -1 Dflt -1 -1
nt! ?? ::FNODOBFM::'string'+2246e nt!ObfDereferenceObject+d4 FLTMGR!FltpCloseCommunicationPort+14 FLTMGR!FltpMsgDispatch+e7 FLTMGR! ?? ::FNODOBFM::`string'+2e80
nt!IopDeleteFile+11e
nt!ObfDereferenceObject+d4
nt!ObpCloseHandleTableEntry+c1
nt!ObpCloseHandle+94
nt!KiSystemServiceCopyEnd+13

This is the operation of correct count increment and decrement before the issue occurred. It appears that the count was increased and decreased twice during this process. In abnormal operations, it seems that the Connect operation has already failed (error code 0xC000009A), which is why the close operation was not triggered.

At least for now, I haven’t found any erroneous additional calls. Furthermore, even if there were incorrect additional calls, I believe they should be considered function failures rather than true reductions, as the handle is already invalid.