内功不够深，打不通反汇编的任督二脉！ 道理是懂了！~~~

汗颜，不知道怎么在代码中能够搞定这种事！ ~~~~~~~~~

如题，我想调用内核的函数KeSuspendThread这样的函数，但是这个函数DDK是没有支持的，不能通过简单的编写原型Link的方式。 我怎样才能调用像这种类型的内核函数啊，只是一个方法问题。  

看到流口水，虽然我很老可是我很新面孔。 现在的工作暂时又没有足够的薪水支撑此项费用，又在最远的珠海，望洋兴叹... ...

写过驱动的应该知道CTL_CODE这个宏，以及IoCreateDevice驱动函数。一直不是很清楚CTL_CODE中的第一个参数DeviceType以及IoCreateDevice中使用的DeviceType之间的关系以及对驱动的影响。有人能够清楚的说明这个Type会影响什么吗？ 比如，我在CTL_CODE以及IoCreateDevice中使用FILE_DEVICE_UNKNOWN和FILE_DEVICE_DISK_FILE_SYSTEM到底会产生什么样的不同，系统会怎样区别对待？  

IRQL 0x1c是一个CLOCK2_LEVEL的中断。 我在上层应用程序中是采用定时器调用驱动接口，不知道有什么影响。 现在测试改为普通的程序循环不停的调用中断2千万次，目前还没有发现问题。 ~~ 郁闷中。。。

http://advdbg.org/forums/1001/ShowPost.aspx 准确的说和这个帖子的情况类似，也就是我至今未解决的问题。 不过我的例程中断是0x1c，这个是0x1b 我的那个问题似乎是KeAttachProcess引起的，目前还没有想法怎么处理。

按上述推测进行代码调整，依然会出现蓝屏，不知道如何处理了！ 调整的代码为在进入KeAttachProcess之后，判断如果IRQL过高，即调用KeDetachProcess然后稍作等待，再次尝试，等目标进程合适的IRQL的出现。 运行环境WinXP SP2 VS2005 调试状态下运行应用程序并调用驱动。 IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by ...

看来KeAttachProcess这个动作可能进入到某进程的高IRQL的上下文代码中。 我想通常我们的驱动程序代码是不应当具备这么高的中断级别的吧，遇到这种高IRQL的情况，安全起见，是否应该避开更为妥当些？ 也就是发现IRQL过高，直接调用KeDetachProcess等待下一次进入。

DIRQL: from 3 to 26 for device ISR 重新翻看了一下《Understanding IRQL》 找到这样一句话，看来你的猜测正确，DbgPrint即使是非Unicode版本也不能用于超过IRQL>26的上下文中. Thanks!