INVALID_PROCESS_ATTACH_ATTEMPT

Hello OSR Gurus,

I’ve been beating my head against this for 3 days now. There doesn’t seem
to be a lot of information of why it happens and what I did found doesn’t
seem to be related to me since I’m using a minifilter and don’t use
KeAttachProcess.

Here is what I think is happening. While I don’t use KeAttachProcess, I AM
using FltSendMessage which according to the crash dump does indeed call
KeStackAttachProcess. According to a couple of messages here on OSR, it
looks like this STOP will happen IF to KeAttachProcess is called before a
previous KeDetachProcess was called on the same thread.

In other words, for me.since I’m not calling it FltSendMessage is, I’ve got
a memory overwrite somewhere and am screwing the stack up and the
KeDetachProcess is being missed. That’s all I can come up with to explain
this.

BTW, I’m processing IRP_MJ_CREATEs, IRP_MJ_READ, IRP_MJ_WRITE and
IRP_MJ_CLEANUPS. All calls to the FltSendMessages happen in Post routines.

I can’t think of any other way but start cutting code until I can get to
work and track it down that way.

Any thoughts on whether or not I’m on the right track?

Have a merry christmas,

Gene

Here is my bugcheck.

*******************************************************************************

*
*

* Bugcheck Analysis
*

*
*

*******************************************************************************

INVALID_PROCESS_ATTACH_ATTEMPT (5)

Arguments:

Arg1: 88afe658

Arg2: 80560f00

Arg3: 00000000

Arg4: 80556440

Debugging Details:


CUSTOMER_CRASH_COUNT: 14

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x5

LAST_CONTROL_TRANSFER: from 805217a4 to 805371aa

STACK_TEXT:

80556078 805217a4 00000005 88afe658 80560f00 nt!KeBugCheckEx+0x1b

8055609c 8062afe7 88afe658 805560b8 89ebd878 nt!KeStackAttachProcess+0x6a

805560f0 f786c2ef 8a25fcd8 88afe658 00000001
nt!MmProbeAndLockProcessPages+0x29

805561f4 b7070b2f 89383640 b7071370 e335c7f8 fltmgr!FltSendMessage+0xf9

80556240 b7070db3 fdb80000 00000000 8a491784 SoxAudit!gLastFileName+0x76f

805562f0 804e18ff 89e89ba0 882ec008 8a491728 SoxAudit!PortDisconnect+0x1f
[c:\soxaudit\bssaudit\filter\bssaudit.c @ 251]

80556350 804e18ff 00000000 88fcae28 89f2c800 nt!IopfCompleteRequest+0xa2

80556380 f74a165e 8a5e5aa0 8a6140e8 00000000 nt!IopfCompleteRequest+0xa2

805563ac f74a1b94 88fcae28 8a5e5aa0 80556427
atapi!IdeProcessCompletedRequest+0x664

80556428 804dcd22 8a6140a4 8a614030 00000000
atapi!IdePortCompletionDpc+0x204

80556450 804dcc07 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61

80556454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28

FOLLOWUP_IP:

fltmgr!FltSendMessage+f9

f786c2ef ?? ???

SYMBOL_STACK_INDEX: 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fltmgr!FltSendMessage+f9

MODULE_NAME: fltmgr

IMAGE_NAME: fltmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e97991

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x5_fltmgr!FltSendMessage+f9

BUCKET_ID: 0x5_fltmgr!FltSendMessage+f9

Followup: MachineOwner


You don’t mention what file system you are filtering. Some of them use
KeAttachProcess and that can cause this problem.

In addition, I think you confuse KeAttachProcess (which shouldn’t be
used anymore and should probably be deprecated) and KeStackAttachProcess
(which can be used multiple times in the same thread.) Filter Manager
should not be using the former, and the latter should not be causing
this bug check.

Try sending us the output from “!analyze -v” and perhaps there will be
something more obvious to suggest.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

He did at the end of the post - quite a few blank lines after the sig.
Is FltSendMessage allowed during PortDisconnect? (general Q, I would assume it is
until the port is closed by the mini-filter in that routine).
Can you post the code of the PortDisconnect routine?

Try sending us the output from “!analyze -v” and perhaps there will be
something more obvious to suggest.


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.

You are right. I missed it.

And therein lies your answer: KeStackAttachProcess can’t be used in a
DPC. Thus, the operation being performed here can’t be done in a DPC.
You’ll need to queue the operation in the completion logic
(“post-processing”) and handle it in a work routine. Filter manager
provides native support for this.

Note this is explicit in the documentation as well:

“Callers of FltSendMessage must be running at IRQL <= APC_LEVEL.”

Since this is in a DPC, IRQL > APC_LEVEL.

See “FltQueueDeferredIoWorkItem” for more information on posting the
work item (note: you shouldn’t allocate here, because there’s no way to
cleanly report back failures. You should allocate in the dispatch
(“pre-processing”) routine and pass the deferred work item to the
completion (“post-processing”) routine.)

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com