如何在内核模式下实现对网络映射驱动器中的文件的访问

我在win2000环境下开发了一个wdm模式的驱动程序，其中要在一个映射的网络驱动器上访问并创建文件。
   我使用的是Driverwork开发工具，使用了KFile类中的OpenCreate
函数，当存取本地硬盘上的文件时没有问题，但是不能存取网络驱动器上的文件。
   请教给为大虾了，我在这里给各位作揖了！！！！

怎么没人搭理啊！拜托各位高人了！

使用如下两个未公开的函数处理进程环境！
KeAttachProcess（）
KeDetachProcess（）
看着给分把！我是小菜鸟，不是高人，嘿嘿。

liuyan1兄能否说的详细一点，是在驱动程序中调用这两个函数吗？
如何调用啊？要注意什么？

用google给您找到一个详细的
Network files access in kernel mode

The article about network files access in kernel mode drivers appeared on the pages of this Web site a few years ago. This aspect of NT/2000/XP kernel mode programming was discussed many times on NT/2K/XP kernel mode development forums during these years. However it makes sense to revisit this article since its discussion shows the progress of improving device driver development tools and documentation. New API and kernel mode features were introduced in Windows 2000 and Windows XP, as well as new information in Windows DDK and Windows XP IFS Kit has been made available.

The statement of the original article, which stressed the necessity of using undocumented operating system interfaces for the solution of the discussed problem, is not true for the current state of things simply because many previously undocumented interfaces became documented.

It is worth mentioning that NT OS interfaces documentation level may vary - undocumented, documented partially (prototyped in the IFS Kit header file) and documented (included in the IFS Kit documentation).

Let us look at the first approach, described in the original article (KeAttachProcess/KeDetachProcess)-

The words of the original article are - \"This approach depends on the user-mode process (usually a kind of service or your control application, running in background), which security credentials are used.

During the initial stage of your virtual drive creation process in the context of the above mentioned process you obtain the handle to the file (ZwCreateFile() with correct parameters) that resides on the network drive. After that you obtain the current process Id (correction - it is actually a pointer to the current process) (IoGetCurrentProcess()). File handles are valid in process contexts, where they are obtained.

Later in the system thread context you may perform the following manipulations:

Right before the file I/O operations take place, you switch to the saved process context (the one that was used to obtain the file handle), using undocumented (but widely used function KeAttachProcess()). After the completion of file I/O operations, you switch back to the original system thread context, using the undocumented function KeDetachProcess.\"

Two additions have been introduced in recent years -

1) The pair of functions (KeAttachProcess/KeDetachProcess) became documented fully (instead of simply having prototypes in the IFS Kit header) and declared obsolete.

2) New functions KeStackAttachProcess/KeUnstackDetachProcess were made available.

The IFS Kit documentation says - \"Note that attaching a thread to a different process can prevent asynchronous I/O operations from completing and can potentially cause deadlocks. In general, the lines of code between the call to KeStackAttachProcess and the call to KeUnstackDetachProcess should be very simple and not call complex routines or send IRPs to other drivers.\"

It means that the use of the first method is not encouraged, especially if you use ZwRead/ZwWrite functions (due to APC states). There are scenarios when this approach can be used safely, but it is definitely the case when someone \"knows what he is doing\" (aware of limitations) and consequently not a very attractive approach.

Let us look at the second approach, described in the original article -

\"But instead of switching process contexts every time you perform file I/O operations it is possible to open the file handle in the user-mode process context, and then open it in the system thread context using reference to already existing kernel file object. You obtain the handle to the file (ZwCreateFile() with correct parameters) that resides on the network drive. After that you obtain the current process Id (correction - it is actually a pointer to the current process) (IoGetCurrentProcess()). File handles are valid in process contexts, where they are obtained. Then you call ObReferenceObjectByHandle( function documented in DDK) to get PFILE_OBJECT.

And later in the system process context you may call the undocumented kernel mode function ObOpenObjectByPointer to get a valid file handle in the system process context (if you use handle oriented API)...\"

The second method probably does not suffer from the problem, mentioned in XP IFS Kit, since the Irp\'s MajorFunction for ZwCreateFile is IRP_MJ_CREATE, which is inherently synchronous.

As far as ObOpenObjectByPointer is concerned it is still not documented (it is only prototyped in the IFS Kit header).

Getting back to the third approach (impersonation) we can say that relevant functions are now fully documented in IFS Kit - (SeCreateClientSecurity, SeImpersonateClient, SeDeleteClientSecurity and related functions - see IFS Kit docs). The notable exception is PsRevertToSelf (it is only prototyped in the IFS Kit header), but it is self explanatory.

In conclusion we must mention the new option for Windows 2000 and XP - OBJ_KERNEL_HANDLE attribute for Zw?calls. It makes possible to obtain the handles which are valid not only in the current process context (in fact inserted in the System process tables) and at the same time are only valid in kernel mode. It is not of much use for you however, if Windows NT 4.0 compatibility is required.

If your goal is to create the code that works on Windows NT as well as Windows 2000 and Windows XP/.NET and relies on fully documented and recommended operating system API, then taking approach of using impersonation in your driver can be recommended.

多谢liuyan1兄，我看了这篇文章，有以下几点心得：
   1、 先在系统模式下调用IoGetCurrentProcess()，取得当前程序的运行环境，然后传递给驱动程序。然后在驱动程序中调用KeAttachProcess（）和KeDetachProcess（）。是这样的吧？
  2、文中有这样一段：In conclusion we must mention the new option for Windows 2000 and XP - OBJ_KERNEL_HANDLE attribute for Zw?calls. It makes possible to obtain the handles which are valid not only in the current process context (in fact inserted in the System process tables) and at the same time are only valid in kernel mode。
   liuyan1兄，这段话的意思是不是这样：在WIN2000/XP环境下，
在调用ZwCreateFile函数存取网络文件时，如果使用OBJ_KERNEL_HANDLE 标志，就可以直接存取网络文件，而不用使用 KeAttachProcess（）和KeDetachProcess（）。是不是这样？
   麻烦liuyan1兄了，请在帮我看看，多谢！