
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\062317-30045-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.23807.amd64fre.win7sp1_ldr.170512-0600
Machine Name:
Kernel base = 0xfffff800`0300f000 PsLoadedModuleList = 0xfffff800`03251750
Debug session time: Fri Jun 23 22:56:54.855 2017 (GMT+2)
System Uptime: 1 days 2:40:06.463
Loading Kernel Symbols
...............................................................
................................................................
...................................
Loading User Symbols
Loading unloaded module list
...........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 18, {fffffa8004f12e40, fffffa8009441a50, 1, 1}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+4160a )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8004f12e40, Object type of the object whose reference count is being lowered
Arg2: fffffa8009441a50, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: 0000000000000001, 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:
------------------


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x18

PROCESS_NAME:  thunderbird.ex

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff8000310016d to fffff8000307fe40

STACK_TEXT:  
fffff880`08f7eb68 fffff800`0310016d : 00000000`00000018 fffffa80`04f12e40 fffffa80`09441a50 00000000`00000001 : nt!KeBugCheckEx
fffff880`08f7eb70 fffff800`0339a872 : 00000000`00000000 00000000`00000000 00000000`02a63dc0 00000000`029e0901 : nt! ?? ::FNODOBFM::`string'+0x4160a
fffff880`08f7ebd0 fffff800`0307f0d3 : fffffa80`09298060 fffff880`08f7eca0 00000000`02a63dc0 fffffa80`09441a50 : nt!NtRequestWaitReplyPort+0x82
fffff880`08f7ec20 00000000`7744bf5a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0971e188 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7744bf5a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+4160a
fffff800`0310016d cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+4160a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  5915f59a

FAILURE_BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+4160a

BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+4160a

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8004f12e40, Object type of the object whose reference count is being lowered
Arg2: fffffa8009441a50, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: 0000000000000001, 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:
------------------


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x18

PROCESS_NAME:  thunderbird.ex

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff8000310016d to fffff8000307fe40

STACK_TEXT:  
fffff880`08f7eb68 fffff800`0310016d : 00000000`00000018 fffffa80`04f12e40 fffffa80`09441a50 00000000`00000001 : nt!KeBugCheckEx
fffff880`08f7eb70 fffff800`0339a872 : 00000000`00000000 00000000`00000000 00000000`02a63dc0 00000000`029e0901 : nt! ?? ::FNODOBFM::`string'+0x4160a
fffff880`08f7ebd0 fffff800`0307f0d3 : fffffa80`09298060 fffff880`08f7eca0 00000000`02a63dc0 fffffa80`09441a50 : nt!NtRequestWaitReplyPort+0x82
fffff880`08f7ec20 00000000`7744bf5a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0971e188 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7744bf5a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+4160a
fffff800`0310016d cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+4160a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  5915f59a

FAILURE_BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+4160a

BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+4160a

Followup: MachineOwner
---------

