错误代码

我的驱动程序在调用时返回如下错误代码（蓝屏）：

INVALID_PROCESS_ATTACH_ATTEMPT

这个错误代码到底是什么意思呢？我找遍了所有的资料，都没有找到相关的东东。需要说明的是：该错误是在DPC例程中调用KeAttachProcess函数时发生的。请教各位高手。

到NTDDK.h或WDM。h文件中去查查看。

Install WinDbg, there are explanation in detail for bug check codes. (Also exists in Bug Check codes)

However, only useless information for this error:

\"
The INVALID_PROCESS_ATTACH_ATTEMPT bug check has value 0x00000005.

This bug check appears very infrequently.
\"

BTW, where did you refer KeAttachProcess? I couldn\'t find it in DDK document or header files. My DDK is XP 2600.

KeAttachProcess是一个未公开的系统调用，在老外写的Undocumented NT以及Microsoft出版的Inside Microsoft Windows 2000上面都有讲过，原型是：

NTSTATUS KeAttachProcess(void* Peb);
<-->
NTSTATUS KeDetachProcess();

这个函数用来把进程上下文切换到由Peb指定的进程，由此可以访问该进程空间中的虚拟地址。我在Dispatch例程中调用该函数都是成功的，但是一到DPC例程中调用的时候就出现蓝屏。：（

KeAttachProcess might be called only at passive IRQL (0). As you knew, all kernel mode support routine has its limitation on IRQL.

I disassembled KeAttachProcess, and I saw it called KeRaiseIrqlToDpcLevel, so it seems to imply that this API will be called at <DPC IRQL (1). BTW, I set a breakpoint in nt!KeAttachProcess, and its IRQL is 0 (PASSIVE_IRQL).

If I were you, I would like to set breakpoint on the instruction, which calles KeAttachProcess in you code, and track into KeAttachProcess to see which instruction cause KeBugCheck(\\Ex).

If you explain what is your goal, some people in this group might come up some good solutions for you. IMHO, as a commenrcial product, undocumented APIs will cost you a lot in maintaince.

Good Luck to you.

I search comp.os.ms-windows.programmer.nt.kernel-mode in http://groups.google.com. And found some interesting posts. You\'d better go to do the search by yourself.

Here is something useful, from Peter G. Viscarola, one of the great writers of the driver book:

\"
Nonsense.  There are a number of ways to manage handle-based operations
other than resorting to KeAttachProcess().

I will tell you that KeAttachProcess() is a VERY dangerous function to call.
It only works in a very specific, narrow, set of conditions and instead of
returning an error code, it BSODs.  For example, this function cannot be
called from within a DPC routine.  If you do, it BSODs.  This function
doesn\'t nest, thus if you try to attach a thread to a different process, and
it\'s already attached to another process, it BSODs.

In our Advanced Driver Development seminar (where we discuss the topic of
handle-based operations and context at length), we actively try to steer
people away from using this function.  It sounds like it might be sooo
good... but unless you really know what you\'re doing, this is a function is
nothing but trouble.

[Note: KeAttachProcess() is prototyped in the IFS kit.]

\"

谢谢xqchen网友。我的目标是：将一个User Mode DLL加载到Kernel Mode去运行，而且这个User Mode DLL应该是在一个DPC例程中调用的。为什么要用User Mode DLL呢？因为这个DLL是由用户开发的（Native），而且用户希望可以随时修改DLL源代码然后动态加载运行――用户是不懂内核编程的。我有三个想法：

1。将User Mode DLL改为Kernel Mode DLL，由系统启动时自动加载。
2。自己编写一个PE加载器。目前我已经编了一个简单的PE加载器，可以在内核中重定位这个DLL，并且调试通过。
3。由用户进程加载这个DLL，然后在DPC例程中调用时设法将Context切换到加载这个DLL的用户进程，就是我们现在讨论的这个问题。

还有一个问题，那就是如果调用KeAttachProcess不成功的话，能不能通过直接访问进程页目录和页表来实现进程Context切换？

1.I prefer this solution. I\'d rather build up a driver project including the source code of the user\'s DLL. And after your users change the code, just run \"build\" to get a driver, then dynamically load and run it. (You might need to write your own driver loading/unloading application, I remember there is \"instdrv\" example in NT4 DDK ).

Any code running on DISPATCH IRQL need to write very carefully, you need to persuade your boss or the users of this point - any error will hang your machine on DISPATCH IRQL.

2. The DLL must be loaded in NON_PAGE POOL, and all support routines, which are called in DLL, must exist in memory when DPC is running. If any data or code segment is swapped to disk, it must be a BSOD waitting for you. When there is enough memory in the machine, this bug won\'t happen. You can use driver verifier to test your driver in low memory condition. However, if the DLL is a standalone module, I means it doesn\'t call any win32 APIs or support routines, then you can try it. (I didn\'t quite understand what \'native\' meaned )

3. Same trouble as 2. In the mean time, you can\'t guarantee the DLL exist in memory when DPC is running. On the other hand, DPC runs on DISPATCH IRQL, no context switch or page fault is allowed.And the context switch will be scheduled for later and will be really executed when IRQL lowering <DISPATCH.

In brief, you must guarantee no page fault, and no context switch in DISPATCH IRQL. So I see no reason to call a user dll from DPC, just too dangerous.