I was working with a customer and we were troubleshooting a problem. I had him unload my file system filter driver (mini-filter) and stop my service while I did some work, several hours later he got a BugCheck 35.
Now?since he unloaded (via fltmc unload) my driver shouldn?t be in the stack anymore?right? I got the mini-dump of the crash and did a lm command, my driver is listed under Unloaded modules, but nowhere else.
Needless to say, the customer is pretty upset, while troubleshooting one problem the server crashed?doesn?t look good.
So my questions are:
- If my minifilter was unloaded, can it still be the culprit?
- This IS on a BDC and the error looks similar to You may receive a "STOP 0x00000035 NO_MORE_IRP_STACK_LOCATIONS" error message when you try to log on to a domain - Microsoft Support since the DfsIrpStackSize value doesn?t exist so it?s defaulting to 3 filter drivers max AND my driver IS a file system filter driver. But it should be unloaded, therefore no longer in the stack.
- I have his poolmon log, and none of my tags are listed at all, but I could be using the log incorrectly.
- Is there any magic that I suppose to do in a file system filter drive to keep this from happening?
Any advice or guidance would be very helpful,
Thank you,
Gene
Here is the analyze
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disasterous
situation, since the higher level driver "thinks" it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet. This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: 88819680, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000
Debugging Details:
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
BUGCHECK_STR: 0x35
PROCESS_NAME: svchost.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8081df4c to 80827c63
STACK_TEXT:
b5a63b5c 8081df4c 00000035 88819680 00000000 nt!KeBugCheckEx+0x1b
b5a63b78 f7202c41 88819680 87c0df90 00000000 nt!IofCallDriver+0x2c
b5a63b90 f720a74b 86c7d5f0 88819680 88819680 Mup!DfsFilePassThrough+0x3d
b5a63bd4 f720a6ba 88891118 88819680 88819680 Mup!DfsCommonClose+0x6e
b5a63c18 f720a4b3 8a244510 88819680 88819680 Mup!DfsFsdClose+0xf6
b5a63c64 8081df65 8a244510 88819680 88819690 Mup!MupClose+0x223
b5a63c78 808f98e0 00000000 00000000 00000000 nt!IofCallDriver+0x45
b5a63cb0 80933914 00c0df90 80a5bf00 87c0df78 nt!IopDeleteFile+0x13a
b5a63ccc 8086c955 87c0df90 00000000 0000034c nt!ObpRemoveObjectRoutine+0xdc
b5a63cec 809344b5 e1d43098 888e9020 888b4db0 nt!ObfDereferenceObject+0x67
b5a63d04 80934546 e1d43098 87c0df90 0000034c nt!ObpCloseHandleTableEntry+0x139
b5a63d48 80934663 0000034c 00000001 b5a63d64 nt!ObpCloseHandle+0x82
b5a63d58 8088978c 0000034c 00eafd68 7c8285ec nt!NtClose+0x1b
b5a63d58 7c8285ec 0000034c 00eafd68 7c8285ec nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
00eafd68 00000000 00000000 00000000 00000000 0x7c8285ec
STACK_COMMAND: kb
FOLLOWUP_IP:
Mup!DfsFilePassThrough+3d
f7202c41 833dbc7120f701 cmp dword ptr [Mup!_MupDrv_ControlGuids+0x44 (f72071bc)],1
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: Mup!DfsFilePassThrough+3d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Mup
IMAGE_NAME: Mup.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a05d
FAILURE_BUCKET_ID: 0x35_Mup!DfsFilePassThrough+3d
BUCKET_ID: 0x35_Mup!DfsFilePassThrough+3d