KERNEL_MODE_EXCEPTION_NOT_HANDLED_M

Igal_Kroyter · December 25, 2007, 3:34pm

hello,

I am trying to read from my file system with a User mode application (buffered access), works perfect, until I yank out the disk from the USB, then the FS release all resources, sends to the application that the FS is STATUS_NO_SUCH_DEVICE - the application receives error and zero buffer read. The FS replys to volume invalidation and surprise remove, releases all FCBs (and the open one),notify that FSRTL_VOLUME_DISMOUNT,…
But then The application (on purpose!!!) reads from the FS JUST this last time (after the volume was released), and I get the BSOD. Of course the debugger shows that the FS is not involved.

Is there something missing in my FS release that enables the “bad” handle used by the application to continue access to the my ghost FS which “long ago” was released?

I have attached the debugger’s log, if it might help.

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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: 80581a9b, The address that the exception occurred at
Arg3: a9973c30, Trap Frame
Arg4: 00000000

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!NtReadFile+2c1
80581a9b ff5608 call dword ptr [esi+8]

TRAP_FRAME: a9973c30 – (.trap 0xffffffffa9973c30)
ErrCode = 00000000
eax=a9973cd8 ebx=85c81478 ecx=85c81478 edx=fffff000 esi=00000000 edi=0011f544
eip=80581a9b esp=a9973ca4 ebp=a9973d38 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!NtReadFile+0x2c1:
80581a9b ff5608 call dword ptr [esi+8] ds:0023:00000008=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 8

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: transferProj.ex

LAST_CONTROL_TRANSFER: from 804dd99f to 80581a9b

STACK_TEXT:
a9973d38 804dd99f 000000bc 00000000 00000000 nt!NtReadFile+0x2c1
a9973d38 7c90eb94 000000bc 00000000 00000000 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0011f500 7c90e288 7c801875 000000bc 00000000 0x7c90eb94
0011f56c 00404474 000000bc 0011f588 00010000 0x7c90e288
0011f570 00000000 0011f588 00010000 0012f588 0x404474

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!NtReadFile+2c1
80581a9b ff5608 call dword ptr [esi+8]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77

SYMBOL_NAME: nt!NtReadFile+2c1

FAILURE_BUCKET_ID: 0x8E_nt!NtReadFile+2c1

BUCKET_ID: 0x8E_nt!NtReadFile+2c1

Followup: MachineOwner

OSR_Community_User · December 25, 2007, 4:42pm

Study the FASTFAT source to get an idea of how to tear down your volume
correctly on PnP device removal.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> hello,
>
> I am trying to read from my file system with a User mode application
(buffered access), works perfect, until I yank out the disk from the USB, then
the FS release all resources, sends to the application that the FS is
STATUS_NO_SUCH_DEVICE - the application receives error and zero buffer read.
The FS replys to volume invalidation and surprise remove, releases all FCBs
(and the open one),notify that FSRTL_VOLUME_DISMOUNT,…
> But then The application (on purpose!!!) reads from the FS JUST this last
time (after the volume was released), and I get the BSOD. Of course the
debugger shows that the FS is not involved.
>
> Is there something missing in my FS release that enables the “bad” handle
used by the application to continue access to the my ghost FS which “long ago”
was released?
>
> I have attached the debugger’s log, if it might help.
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> 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: 80581a9b, The address that the exception occurred at
> Arg3: a9973c30, Trap Frame
> Arg4: 00000000
>
> 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!NtReadFile+2c1
> 80581a9b ff5608 call dword ptr [esi+8]
>
> TRAP_FRAME: a9973c30 – (.trap 0xffffffffa9973c30)
> ErrCode = 00000000
> eax=a9973cd8 ebx=85c81478 ecx=85c81478 edx=fffff000 esi=00000000 edi=0011f544
> eip=80581a9b esp=a9973ca4 ebp=a9973d38 iopl=0 nv up ei pl zr na pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
> nt!NtReadFile+0x2c1:
> 80581a9b ff5608 call dword ptr [esi+8]
ds:0023:00000008=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 8
>
> DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
>
> BUGCHECK_STR: 0x8E
>
> PROCESS_NAME: transferProj.ex
>
> LAST_CONTROL_TRANSFER: from 804dd99f to 80581a9b
>
> STACK_TEXT:
> a9973d38 804dd99f 000000bc 00000000 00000000 nt!NtReadFile+0x2c1
> a9973d38 7c90eb94 000000bc 00000000 00000000 nt!KiFastCallEntry+0xfc
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0011f500 7c90e288 7c801875 000000bc 00000000 0x7c90eb94
> 0011f56c 00404474 000000bc 0011f588 00010000 0x7c90e288
> 0011f570 00000000 0011f588 00010000 0012f588 0x404474
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!NtReadFile+2c1
> 80581a9b ff5608 call dword ptr [esi+8]
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77
>
> SYMBOL_NAME: nt!NtReadFile+2c1
>
> FAILURE_BUCKET_ID: 0x8E_nt!NtReadFile+2c1
>
> BUCKET_ID: 0x8E_nt!NtReadFile+2c1
>
> Followup: MachineOwner
>

David_J_Craig · December 25, 2007, 6:09pm

In addition to the fastfat sources, think about what you said. You said
‘yank out the disk from the USB, then the FS release all resources, sends to
the application that the FS is STATUS_NO_SUCH_DEVICE’. You then go on to
say you arbitrialary release all FCBs - here is your first mistake. You
didn’t open the file that caused you to create that FCB, did you? No, it
was your application and not the FSD. You didn’t open/create it, you can’t
close it just because you want it closed. Why not just format all the
mounted partitions in response to a surprise remove? Both actions are not
good. You must continue to fail requests until the application takes the
hint and stops trying to make requests that your FSD cannot answer. When
the process terminates or closes the handle(s), then you can destroy the
FCB. I would say you can do the dismount notification, but close reading of
Nagar’s book and the fastfat sources will provide the minor details of the
proper sequence.

wrote in message news:xxxxx@ntfsd…
> hello,
>
> I am trying to read from my file system with a User mode application
> (buffered access), works perfect, until I yank out the disk from the USB,
> then the FS release all resources, sends to the application that the FS is
> STATUS_NO_SUCH_DEVICE - the application receives error and zero buffer
> read. The FS replys to volume invalidation and surprise remove, releases
> all FCBs (and the open one),notify that FSRTL_VOLUME_DISMOUNT,…
> But then The application (on purpose!!!) reads from the FS JUST this last
> time (after the volume was released), and I get the BSOD. Of course the
> debugger shows that the FS is not involved.
>
> Is there something missing in my FS release that enables the “bad” handle
> used by the application to continue access to the my ghost FS which “long
> ago” was released?
>
> I have attached the debugger’s log, if it might help.
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
> 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: 80581a9b, The address that the exception occurred at
> Arg3: a9973c30, Trap Frame
> Arg4: 00000000
>
> 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!NtReadFile+2c1
> 80581a9b ff5608 call dword ptr [esi+8]
>
> TRAP_FRAME: a9973c30 – (.trap 0xffffffffa9973c30)
> ErrCode = 00000000
> eax=a9973cd8 ebx=85c81478 ecx=85c81478 edx=fffff000 esi=00000000
> edi=0011f544
> eip=80581a9b esp=a9973ca4 ebp=a9973d38 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!NtReadFile+0x2c1:
> 80581a9b ff5608 call dword ptr [esi+8]
> ds:0023:00000008=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 8
>
> DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
>
> BUGCHECK_STR: 0x8E
>
> PROCESS_NAME: transferProj.ex
>
> LAST_CONTROL_TRANSFER: from 804dd99f to 80581a9b
>
> STACK_TEXT:
> a9973d38 804dd99f 000000bc 00000000 00000000 nt!NtReadFile+0x2c1
> a9973d38 7c90eb94 000000bc 00000000 00000000 nt!KiFastCallEntry+0xfc
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0011f500 7c90e288 7c801875 000000bc 00000000 0x7c90eb94
> 0011f56c 00404474 000000bc 0011f588 00010000 0x7c90e288
> 0011f570 00000000 0011f588 00010000 0012f588 0x404474
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!NtReadFile+2c1
> 80581a9b ff5608 call dword ptr [esi+8]
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77
>
> SYMBOL_NAME: nt!NtReadFile+2c1
>
> FAILURE_BUCKET_ID: 0x8E_nt!NtReadFile+2c1
>
> BUCKET_ID: 0x8E_nt!NtReadFile+2c1
>
> Followup: MachineOwner
>

Igal_Kroyter · December 26, 2007, 2:30am

Sirs,

Thank you very much for the response.

I was under the impresion that the notification to the IO manager shall cause the IO manager stop sending the FS the READ requests, as it knows that the FS is not available anymore.

Craig, so what you are actually saying is the following:

Announce the volume is not available (which shall not allow any new CREATEs)
close all non-used FCBs
when the last handle of a specific FCB is released, only then release the relevant FCB
free all volumes resources

Please verify my logic.

Igal