*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007E, {c0000005, 81ded57b, 900c7c2c, 900c7928}

Probably caused by : ntkrpamp.exe ( nt!ObpRemoveObjectRoutine+da )

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

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

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 81ded57b, The address that the exception occurred at
Arg3: 900c7c2c, Exception Record Address
Arg4: 900c7928, Context Record Address

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
nt!ObpRemoveObjectRoutine+da
81ded57b ff90a0000000    call    dword ptr [eax+0A0h]

EXCEPTION_RECORD:  900c7c2c -- (.exr 0xffffffff900c7c2c)
ExceptionAddress: 81ded57b (nt!ObpRemoveObjectRoutine+0x000000da)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 000000a0
Attempt to read from address 000000a0

CONTEXT:  900c7928 -- (.cxr 0xffffffff900c7928)
eax=00000000 ebx=00000000 ecx=afbf6561 edx=afbf6561 esi=00000000 edi=00000000
eip=81ded57b esp=900c7cf4 ebp=900c7d28 iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010206
nt!ObpRemoveObjectRoutine+0xda:
81ded57b ff90a0000000    call    dword ptr [eax+0A0h] ds:0023:000000a0=????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

CURRENT_IRQL:  0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  000000a0

READ_ADDRESS: GetPointerFromAddress: unable to read from 81d315ac
Unable to read MiSystemVaType memory at 81d117e0
 000000a0 

FOLLOWUP_IP: 
nt!ObpRemoveObjectRoutine+da
81ded57b ff90a0000000    call    dword ptr [eax+0A0h]

BUGCHECK_STR:  0x7E

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER:  from 81ded46c to 81ded57b

STACK_TEXT:  
900c7d28 81ded46c afbf6561 00000001 81cfde40 nt!ObpRemoveObjectRoutine+0xda
900c7d44 81c78fc0 00000000 00000000 876dd3f0 nt!ObpProcessRemoveObjectQueue+0x39
900c7d7c 81e2553c 00000000 900cc680 00000000 nt!ExpWorkerThread+0xfd
900c7dc0 81c915fe 81c78ec3 80000000 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!ObpRemoveObjectRoutine+da

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  49ac8cd6

STACK_COMMAND:  .cxr 0xffffffff900c7928 ; kb

FAILURE_BUCKET_ID:  0x7E_nt!ObpRemoveObjectRoutine+da

BUCKET_ID:  0x7E_nt!ObpRemoveObjectRoutine+da

Followup: MachineOwner

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 18, {0, afbf6561, 1, 68000000}

Probably caused by : vtany.sys ( vtany+16f2 )

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

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

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

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 8dbbb6f2 to 81c478a5

STACK_TEXT:  
a366cd3c 8dbbb6f2 00000000 848f8458 00000000 nt!ObfDereferenceObject+0x66
WARNING: Stack unwind information not available. Following frames may be wrong.
a366cd7c 81e2553c 8dbbd110 a3667680 00000000 vtany+0x16f2
a366cdc0 81c915fe 8dbbb67c 8dbbd110 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
vtany+16f2
8dbbb6f2 ??              ???

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  vtany+16f2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vtany

IMAGE_NAME:  vtany.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a9e2c6b

FAILURE_BUCKET_ID:  0x18_vtany+16f2

BUCKET_ID:  0x18_vtany+16f2

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

1: kd> lmvm vtany
start    end        module name
8dbba000 8dbbec80   vtany    T (no symbols)           
    Loaded symbol image file: vtany.sys
    Image path: \??\C:\Windows\vtany.sys
    Image name: vtany.sys
    Timestamp:        Wed Sep 02 04:27:23 2009 (4A9E2C6B)
    CheckSum:         0000D1BA
    ImageSize:        00004C80
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4