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.
>>
>>
>
>
>

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
>