This problem has fixed in the service pack. Thank you for all help.
“Prokash Sinha” wrote in message news:xxxxx@ntfsd…
> FC,
>
> This is very detail, but couple questions might get you back up a little
> bit !
>
> What OS ver. (including SP ) you are using ?
> What sfilter ( ddk version ) you are using ?
> Is it the straight sfilter ( without any modification whatsoever ) giving
> this problem ?
> Did any of the Inf parameter you changed? . I guess not.
>
> Of course, you can debug down this path, but is it the sfliter ( as such
> have a problem ?). If you happen to have another machine, I would try that
> first by simply compiling sfilter from 3790+, (try both release and debug
> build, and try XP build - since it seems more stable for sfilter code
> path ). Just to be sure that sfilter has a problem for certain
> configuartions !!
>
> If someone knows ( or have seen ) this they will provide you with the
> info. But I’ve not seen, so may be it would help to take a look at those
> above mentioned points. If you already looked at those, then just avoid
> all of these…
>
> -pro
> ----- Original Message -----
> From: “fc”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, May 05, 2005 11:18 AM
> Subject: Re:[ntfsd] detail info
>
>
>> Following is the area that caused the problem:
>>
>> eb44cf48 55 push ebp
>> eb44cf49 8bec mov ebp,esp
>> eb44cf4b 51 push ecx
>> eb44cf4c 51 push ecx
>> eb44cf4d 53 push ebx
>>
>> //it move the raw disk device object to ebx. the device object created by
>> sfilter driver
>> eb44cf4e 8b5d08 mov ebx,[ebp+0x8]
>> eb44cf51 56 push esi
>> eb44cf52 57 push edi
>> eb44cf53 837b2c08 cmp dword ptr [ebx+0x2c],0x8
>> eb44cf57 0f853f010000 jne sis!SiFsNotification+0x154 (eb44d09c)
>> eb44cf5d 807d0c00 cmp byte ptr [ebp+0xc],0x0
>> eb44cf61 0f84ba000000 je sis!SiFsNotification+0xd9 (eb44d021)
>>
>> //here the good data at ds:0023:820416b4 is 0x10
>> eb44cf67 8a4bf4 mov cl,[ebx-0xc] ds:0023:820416b4=00
>>
>> //address at ebx-0x18 will use for calculation later.
>> eb44cf6a 8d43e8 lea eax,[ebx-0x18]
>>
>> //data at cl is 0, good one is 0x10
>> eb44cf6d 84c9 test cl,cl
>> eb44cf6f 7504 jnz sis!SiFsNotification+0x2d (eb44cf75)
>>
>> //do’nt know why it does this.
>> eb44cf71 33c0 xor eax,eax
>> eb44cf73 eb05 jmp sis!SiFsNotification+0x32 (eb44cf7a)
>>
>> //good one will come to here then it will calculate address base on cl
>> and eax.
>> eb44cf75 0fb6c9 movzx ecx,cl
>> eb44cf78 2bc1 sub eax,ecx
>>
>> //bad one eax is 0 that cause the invalid memory access
>> eb44cf7a 8d7004 lea esi,[eax+0x4]
>> eb44cf7d 85f6 test esi,esi
>> eb44cf7f 742c jz sis!SiFsNotification+0x65 (eb44cfad)
>> eb44cf81 837e0400 cmp dword ptr [esi+0x4],0x0
>> eb44cf85 7426 jz sis!SiFsNotification+0x65 (eb44cfad)
>>
>> Any clue?
>>
>> “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
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> —
>> 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
>>
>
>