大家有没有试验啊，我记的一个进程中核心模式和用户模式不是同一个堆栈，（x86每一层都有不同的SS），这样即便是知道函数地址，也不能简单的通过指针来调用，（函数中的堆栈操作很容易出现问题，首先是函数参数，然后是new delete等）何况这种方法只能是在应用程序发送IRP后才能回调，而且我个人还是认为不能保证在处理IRP期间，进程上下文不发生变化，wowocock说的只是直接I/O和缓冲I/O提供的数据缓冲区不随进程上下文变化而变化，但是现在情况不一样了，你是以缓冲区中的数据作为指针调用函数，万一在调用函数之前发生了进程切换，你的指针................而且即使进程上下文不发生变化，也会有问题

大家有没有试验啊，我记的一个进程中核心模式和用户模式不是同一个堆栈，（x86每一层都有不同的SS），这样即便是知道函数地址，也不能简单的通过指针来调用，（函数中的堆栈操作很容易出现问题，首先是函数参数，然后是new delete等）何况这种方法只能是在应用程序发送IRP后才能回调，而且我个人还是认为不能保证在处理IRP期间，进程上下文不发生变化，wowocock说的只是直接I/O和缓冲I/O提供的数据缓冲区不随进程上下文变化而变化，但是现在情况不一样了，你是以缓冲区中的数据作为指针调用函数，万一在调用函数之前发生了进程切换，你的指针................而且即使进程上下文不发生变化，也会有问题

没问题的，passive_level能保证线程上下文

[quote]大家有没有试验啊，我记的一个进程中核心模式和用户模式不是同一个堆栈，（x86每一层都有不同的SS），这样即便是知道函数地址，也不能简单的通过指针来调用，（函数中的堆栈操作很容易出现问题，首先是函数参数，然后是new delete等）何况这种方法只能是在应用程序发送IRP后才能回调，而且我个人还是认为不能保证在处理IRP期间，进程上下文不发生变化，wowocock说的只是直接I/O和缓冲I/O提供的数据缓冲区不随进程上下文变化而变化，但是现在情况不一样了，你是以缓冲区中的数据作为指针调用函数，万一在调用函数之前发生了进程切换，你的指针................而且即使进程上下文不发生变化，也会有问题

没问题的，passive_level能保证线程上下文
 [/quote]
但是堆栈问题怎么解决？核心环境的堆栈肯定和用户模式的堆栈不同

你反汇编下函数代码看看即可，估计运行的时候在RING0运行的RING3函数使用的是RING0堆栈，所以自然有一定的限制，不过只要一般不是很大即可，而且可以在RING0中访问RING3堆栈中的内容所以问题不大。。。。。

顶!!!!!!!!!!
用户模式访问底层函数,缓冲区是什么情况呀?

你反汇编下函数代码看看即可，估计运行的时候在RING0运行的RING3函数使用的是RING0堆栈，所以自然有一定的限制，不过只要一般不是很大即可，而且可以在RING0中访问RING3堆栈中的内容所以问题不大。。。。。

按照楼主的方法，回调函数肯定被纳入ring0，其实已经算是驱动程序的例程了，只不过地址在用户地址空间，而且这种调用函数的结果肯定和用户模式调用这个函数的结果不太一样，我不太清楚你说的这种方法能不能称之为回调，自己处理堆栈....牛啊，举个例子

应用程序在一个函数里面肯定可以执行MessageBox("asdfghjkl");
但是到驱动程序中调用，堆栈改变，万一用户模式的API函数MessageBox有需要访问自己原来在用户模式的堆栈，你就傻了，而且要注意核心模式为函数提供的堆栈只有12K，不能深度调用，递归更是不可能，因此建议楼主还是放弃直接在驱动中直接调用用户模式函数，除非你的回调函数是按照驱动程序的要求写的，比如你最好不要调用一些WIN32API，因为这个函数本身已经不算是应用程序的一部分了，因此如果这样，你还不如直接把你的回调函数写到你的驱动程序中，这样还简单的多

虽然没有试验过，不过我觉得这种方法不可行！！

函数的指针是在应用程序进程内的地址空间，传到驱动程序里面有什么用吗？？根本不在一个进程内。

虽然我没试过，不过肯定不行！！

回调函数函数是在应用程序的进程空间内，传到驱动力有什么用吗？？难道驱动也会使用你的地址空间吗？？

我试过的，这种方法不行，应该用APC

我试过,这种方法完全没问题的.

估计有很多限制

但这种方法如果能在限制范围内没问题， 无疑给驱动向应用层通知，提供了很简单的思路

比如在 核心态 可以 回调 应用态的

SendMsg(int iMsgNo)
{
   SendMessage(xxx, yyy, iMsgNo);
}

通过应用态再转一次， 应该可以避免很多问题

那位大虾，严格论证一下， 这些想法即时调试出来，当时没问题，心里也没底