Re: know problem but do not know how to fix

Traced the problem look like this:

  1. sfilter creat and attach the raw disk device object.
  2. sis get the sfiloter created raw disk device object. it look for the flag
    at location. Since sfilter did not set that flag. It jump
    to the wrong location. Another problem is <&(deviceobject-0x18)> has some
    secret data. It might be the execution function. This is the one that caused
    the crash.

    If anyone knows about the data at those two location, please post. Thanks.

    “fc” wrote in message news:xxxxx@ntfsd…
    >I set break point at sis!SiFsNotification and checked sis code. It is to do
    >the RawDisk fs notification. Sis code is different from the sfilter.sys
    >sample. It checks the device object flag and does some resource lock. They
    >are not in the sfilter sample. Look like sfilter driver also need to check
    >those flags before attach to the device. This is the bug in sfilter but I
    >do not know what flag need to check. Does any one know it?
    >
    > “Prokash Sinha” wrote in message news:xxxxx@ntfsd…
    >> This is not terribly difficult to fix !!!
    >>
    >> sis!SiFsNotification+0x39 <— This is the place you need to look at.
    >> If you could reproduce, then you would be able to capture it while you
    >> are loading your driver. Your driver is loading at boot stage ??
    >> You are trying to access a bad pointer ( it is the 4th args ).
    >>
    >> How do I guess all of it ???
    >>
    >> In Windbg, help if you type the KMODE_EXCEPTION_*****, you will see all
    >> the detail pops up. Please make sure you have the latest released build
    >> of the windbg, IT REALLY RAISED THE BAR now.
    >>
    >> -pro
    >>
    >> ----- Original Message -----
    >> From: “fc”
    >> Newsgroups: ntfsd
    >> To: “Windows File Systems Devs Interest List”
    >> Sent: Thursday, May 05, 2005 6:50 AM
    >> Subject: [ntfsd] Crash dump with symbol turn on
    >>
    >>
    >>>I am sorry that I did not include the Microsoft symbol in the path. The
    >>>following dump has added the symbol path. I also have the conclusion
    >>>about the problem. If I remove the RawDisk attach, the problem goes away.
    >>>Does anyone know when RawDisk attached what kind of command will pass
    >>>through filter driver? I can monitor that command. Thank you for all of
    >>>your help.
    >>>
    >>> kd> !analyze -v
    >>>*******************************************************************************
    >>> * *
    >>> * Bugcheck Analysis *
    >>> * *
    >>>
    >>>
    >>> KMODE_EXCEPTION_NOT_HANDLED (1e)
    >>> 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.
    >>> Arguments:
    >>> Arg1: c0000005, The exception code that was not handled
    >>> Arg2: eb44cf81, The address that the exception occurred at
    >>> Arg3: 00000000, Parameter 0 of the exception
    >>> Arg4: 00000008, Parameter 1 of the exception
    >>>
    >>> Debugging Details:
    >>> ------------------
    >>>
    >>>
    >>> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
    >>> referenced memory at “0x%08lx”. The memory could not be “%s”.
    >>>
    >>> FAULTING_IP:
    >>> sis!SiFsNotification+39
    >>> eb44cf81 837e0400 cmp dword ptr [esi+0x4],0x0
    >>>
    >>> EXCEPTION_PARAMETER1: 00000000
    >>>
    >>> EXCEPTION_PARAMETER2: 00000008
    >>>
    >>> READ_ADDRESS: 00000008
    >>>
    >>> DEFAULT_BUCKET_ID: DRIVER_FAULT
    >>>
    >>> BUGCHECK_STR: 0x1E
    >>>
    >>> EXCEPTION_RECORD: eb81b700 – (.exr ffffffffeb81b700)
    >>> .exr ffffffffeb81b700
    >>> ExceptionAddress: eb44cf81 (sis!SiFsNotification+0x00000039)
    >>> ExceptionCode: c0000005 (Access violation)
    >>> ExceptionFlags: 00000000
    >>> NumberParameters: 2
    >>> Parameter[0]: 00000000
    >>> Parameter[1]: 00000008
    >>> Attempt to read from address 00000008
    >>>
    >>> CONTEXT: eb81b358 – (.cxr ffffffffeb81b358)
    >>> .cxr ffffffffeb81b358
    >>> eax=00000000 ebx=820406c0 ecx=00000100 edx=eb81bdcc esi=00000004
    >>> edi=00000000
    >>> eip=eb44cf81 esp=eb81b7c8 ebp=eb81b7dc iopl=0 nv up ei pl nz na
    >>> pe nc
    >>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
    >>> sis!SiFsNotification+0x39:
    >>> eb44cf81 837e0400 cmp dword ptr [esi+0x4],0x0
    >>> .cxr
    >>> Resetting default scope
    >>>
    >>> LAST_CONTROL_TRANSFER: from eb44d861 to eb44cf81
    >>>
    >>> STACK_TEXT:
    >>> eb81b7dc eb44d861 820406c0 00000001 8203f5f8 sis!SiFsNotification+0x39
    >>> eb81b80c 8054deb6 8203f550 8007be40 8007de90 sis!DriverEntry+0x1fd
    >>> eb81b854 8054daff 8203f550 8007be40 8007bed8
    >>> nt!IopInitializeBuiltinDriver+0x279
    >>> eb81b8b8 8054c574 80087000 eb81ba00 00000000
    >>> nt!IopInitializeBootDrivers+0x2d0
    >>> eb81ba58 8054b35a 80087000 00000000 00000000 nt!IoInitSystem+0x5ef
    >>> eb81bda8 804524f6 80087000 00000000 00000000
    >>> nt!Phase1Initialization+0x71b
    >>> eb81bddc 80465b62 8054aca6 80087000 00000000
    >>> nt!PspSystemThreadStartup+0x69
    >>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
    >>>
    >>>
    >>> FOLLOWUP_IP:
    >>> sis!SiFsNotification+39
    >>> eb44cf81 837e0400 cmp dword ptr [esi+0x4],0x0
    >>>
    >>> SYMBOL_STACK_INDEX: 0
    >>>
    >>> FOLLOWUP_NAME: MachineOwner
    >>>
    >>> SYMBOL_NAME: sis!SiFsNotification+39
    >>>
    >>> MODULE_NAME: sis
    >>>
    >>> IMAGE_NAME: sis.sys
    >>>
    >>> DEBUG_FLR_IMAGE_TIMESTAMP: 3803c152
    >>>
    >>> STACK_COMMAND: .cxr ffffffffeb81b358 ; kb
    >>>
    >>> BUCKET_ID: 0x1E_sis!SiFsNotification+39
    >>>
    >>> Followup: MachineOwner
    >>> ---------
    >>>
    >>> Closing open log file fred.log
    >>>
    >>> “fc” wrote in message news:xxxxx@ntfsd…
    >>>> Here is the analyze dump:
    >>>>
    >>>> Opened log file ‘fred.log’
    >>>> kd> !analyze -v
    >>>>

    >>>> * *
    >>>> * Bugcheck Analysis *
    >>>> * *
    >>>> **************************************************************************
    >>>>
    >>>> KMODE_EXCEPTION_NOT_HANDLED (1e)
    >>>> 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.
    >>>> Arguments:
    >>>> Arg1: c0000005, The exception code that was not handled
    >>>> Arg2: eb44cf81, The address that the exception occurred at
    >>>> Arg3: 00000000, Parameter 0 of the exception
    >>>> Arg4: 00000008, Parameter 1 of the exception
    >>>>
    >>>> Debugging Details:
    >>>> ------------------
    >>>>
    >>>>
    Kernel symbols are WRONG. Please fix symbols to do analysis.
    >>>>
    >>>>
    >>>> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
    >>>> referenced memory at “0x%08lx”. The memory could not be “%s”.
    >>>>
    >>>> FAULTING_IP:
    >>>> sis+cf81
    >>>> eb44cf81 837e0400 cmp dword ptr [esi+0x4],0x0
    >>>>
    >>>> EXCEPTION_PARAMETER1: 00000000
    >>>>
    >>>> EXCEPTION_PARAMETER2: 00000008
    >>>>
    >>>> READ_ADDRESS: unable to get nt!MmPoolCodeEnd
    >>>> unable to get nt!MmSpecialPoolEnd
    >>>> unable to get nt!MmPagedPoolEnd
    >>>> unable to get nt!MmNonPagedPoolEnd
    >>>> unable to get nt!MmNonPagedPoolStart
    >>>> unable to get nt!MmSpecialPoolStart
    >>>> unable to get nt!MmPagedPoolStart
    >>>> unable to get nt!MmNonPagedPoolExpansionStart
    >>>> unable to get nt!MmPoolCodeStart
    >>>> 00000008
    >>>>
    >>>> DEFAULT_BUCKET_ID: DRIVER_FAULT
    >>>>
    >>>> BUGCHECK_STR: 0x1E
    >>>>
    >>>> LAST_CONTROL_TRANSFER: from 8042c068 to 80452e70
    >>>>
    >>>> STACK_TEXT:
    >>>> WARNING: Stack unwind information not available. Following frames may
    >>>> be wrong.
    >>>> eb81aeb0 8042c068 00000003 80409808 00000000
    >>>> nt!DbgBreakPointWithStatus+0x4
    >>>> eb81b238 8045249c 00000000 c0000005 eb44cf81 nt!KeBugCheckEx+0x154
    >>>> eb81bddc 80465b62 8054aca6 80087000 00000000
    >>>> nt!PsSetCreateThreadNotifyRoutine+0x50
    >>>> 00000000 00000000 00000000 00000000 00000000
    >>>> nt!KiUnexpectedInterrupt+0x180
    >>>>
    >>>>
    >>>> STACK_COMMAND: .bugcheck ; kb
    >>>>
    >>>> FOLLOWUP_IP:
    >>>> sis+cf81
    >>>> eb44cf81 837e0400 cmp dword ptr [esi+0x4],0x0
    >>>>
    >>>> FOLLOWUP_NAME: MachineOwner
    >>>>
    >>>> SYMBOL_NAME: sis+cf81
    >>>>
    >>>> MODULE_NAME: sis
    >>>>
    >>>> IMAGE_NAME: sis.sys
    >>>>
    >>>> DEBUG_FLR_IMAGE_TIMESTAMP: 3803c152
    >>>>
    >>>> BUCKET_ID: WRONG_SYMBOLS
    >>>>
    >>>> Followup: MachineOwner
    >>>> ---------
    >>>>
    >>>> Closing open log file fred.log
    >>>>
    >>>> I also found this crash when it attached to RawDisk and Cdrom drive.
    >>>> Any crew about that. Thank you for the reply.
    >>>>
    >>>> fc
    >>>> “Ladislav Zezula” wrote in message
    >>>> news:xxxxx@ntfsd…
    >>>>> Get the crash dump, open it in WinDBG, do !analyze -v
    >>>>> and send the call stack here. Maybe someone can
    >>>>> help you.
    >>>>>
    >>>>> L.
    >>>>>
    >>>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>
    >>>
    >>> —
    >>> Questions? First check the IFS FAQ at
    >>> https://www.osronline.com/article.cfm?id=17
    >>>
    >>> You are currently subscribed to ntfsd as: xxxxx@garlic.com
    >>> To unsubscribe send a blank email to xxxxx@lists.osr.com
    >>>
    >>
    >>
    >
    >
    >

> 2. sis get the sfiloter created raw disk device object. it look for the

flag at location. Since sfilter did not set that flag.

Then sis touches the object header. Every object (device object,
file object, driver object etc.) has the object header, represented
the OBJECT_HEADER structure. You may show it by typing
dt nt!_OBJECT_HEADER addr, where “addr” is the
object address - 0x18.

In this case [DeviceObject - 0x0C] is the name info offset.

> Another problem is <&(deviceobject-0x18)> has some secret data. It might
> be the execution function.

The [DeviceObject - 0x18] is the current pointer count
(reference count) of the object.

L.