以前一直都是用 VS2008 + DDKWizard + WinDbg 来进行驱动程序的开发调试的， 使用 DDKWizard 来搭配调试环境呢，在 VS2008 下也还算方便， 因为不需要自己去设置一些什么包含文件啊，源代码路径啊之类的就可以直接编译驱动程序源码， 安装好 DDKWizard 后，在 VS200

由于从公司辞职了，所以以前在公司里搭建的驱动开发环境也就 Game Over 了， 同样由于那环境是很久以前搭建的，自己也有很多记不清楚的地方了， 而且其中还是有很多需要注意的地方的，所以在这里顺便做一个环境搭建的总结， 以后再要用的时候也会很方便的。            

上回我们留下一个未解的问题，就是当一个IRP的CancelRoutine没有被设置时，CancelIo操作会失败，系统中有可能会留下永远都不会被complete的IRP。在Threaded IRP和non-threaded IRP一节中我们有谈到irp分为线程相关和非线程相关两种。倘若一个永远不complete的irp是非线程相关的，情况会稍微好一点，顶多系统中泄露了一个资源。倘若该irp是线程相

虽然内核开发人员从一开始就要考虑多线程的问题，但用户态开发人员曾经有过一段美好的生活：他们只需关心一条线程（多半是UI线程）并且不必在乎太多性能问题：即使你在主逻辑里嵌套了无数层循环都没关系，该死的摩尔定律替你搞定一切问题。进入多核时代后，用户态开发人员终于发现了他们忽略很久的，但及其重要的一个技术点：多线程。朋友，好生活已经结束了，欢迎你来到混乱的时代。 我知道现在来写这篇东西似乎不合时宜，因为

不要再假装自己写的程序没bug了，不可能的，debug工具你早晚得用上。最常见的debug工具非printf（windows上用OutputDebugString函数）莫属，简单方便易学易用，但局限性也是显而易见的，首先它对debugee的影响很大，某些race condition的bug你要多加几个log它就重现不出来了，然后你把log去了发布给客户，结果又成了必现的bug，这种烂事咱们都碰到过

IO_STACK_LOCATION很重要，再多聊一点也无妨。上上回我们谈了IO_STACK_LOCATION和那几个重要的函数，当然，我的目的不是扫盲，而是记下一些容易犯错的地方（实际上都是工作中碰到过的钉子）以方便自己回顾。我的记性是如此的差以至于几月不看就会忘记。如果你对这东西没概念，我建议你先多查查WDK文档。 上回我们聊了IoCopyCurrentIrpStackLocationToNex

今天我们聊一聊CreateFile，这个名字取的不合适但IO的世界里完全绕不过去的东西，以及与之相关的“namespace”这一概念。 我们知道Create的意思是创造，创建，上帝创造了这个世界，指的可不是上帝打开了某样存在的东西（唯物主义者，我知道你们有意见，给我闭嘴…），但这个倒霉的函数要做的却是打开。我们也知道File是文件，windows里面也没有&l

今天我们来聊聊IRQL，这是驱动新手的梦魇，想想看多少BSOD是因为IRQL不对引起的。这也是*NIX类内核开发人员最喜欢的吐槽点之一，你看linux里就没有这个概念，我们还不是活的好好的？我偶尔有时候能得着一些空，也会问一样的问题：为毛？为毛要有这东西存在！后来我想通了。 我们先聊passive level和interrupt level。passive level是普通级别，同时也是优先级最低

如前文所述，nt内核的驱动模型没有完全使用函数调用栈，而是自己山寨出来一个IO_STACK_LOCATION，里面保存了驱动调用序列。我们知道函数调用栈的push和pop都是编译器帮忙弄的，你甚至都可以在完全不了解内幕的前提下写代码，但是驱动开发不一样，调用序列要你自己去关心，何时入栈，何时出栈，栈内保留的什么内容，全部都要照顾好，否则BSOD就在前方不远等你。 与IO_STACK_LOCATIO

nt内核的IO模型中，IRP有两类：threaded irp和non-threaded irp，顾名思义，前者跟thread绑定，后者跟thread无关。当一个threaded irp被创建时，创建线程会有一个队列保存该irp，直到irp完成之后才释放。当你试图让这条线程退出时，系统会检测队列看里面是否还有irp没完成，如果有，线程会一直等待，直到所有的irp全部完成。而non-thread ir