可以看一下日志文件，Vista起的地址：C:\windows\inf\setupapi.dev

可以从DDK的例子中，复制一个makefile，其实里面就是包含makefile.def # # DO NOT EDIT THIS FILE!!! Edit .\sources. if you want to add a new source # file to this component. This file merely indirects to the real make file # that is shared by all the components of NT # !INCLUDE $(NTMAKEENV)\makefile.def

大致看了下，目前的状况是两种构建方法，使用sources文件的DDK构建方法和手工编写makefile，混杂在一起了。 建议不要在这样的例子中花费太多时间，还是使用DDK中DDK的构建方法，使用sources文件，可以用命令行，也可以用VS调用批处理文件。

这样的问题值1万美金 :-) 范围很广，只能先“广撒网”，多点埋伏，然后逐步缩小目标。 建议从客户端下手，分析日志对于这样的问题很难有效，找突破口的一种方式就是上调试器，看“许久才弹出来”时的那个“许久”时，进程在等待哪个对象，然后再顺着这个线索抽丝剥茧......

热键触发蓝屏使用的IRQL是10左右（键盘驱动的IRQL），对于挂在更高IRQL的情况是不奏效的。建议先尝试一下双击内核调试，基于时钟中断，IRQL是28，有效范围还是大大提高的。 如果双机内核调试还无法中断，那很可能是硬件瘫痪了，访问了映射在内存空间的设备空间（MMIO），触发了硬件的局限，CPU不“转”了。对于这种情况，如果没有ITP，那么就要“未雨绸缪”了，建议先试一下，开启Verifier，看Verifier机制能否拦截到“疯狂”访问。 王宇的实践经验非常丰富，上面的推测也是有道理的，他提供的建议也很值得思考......

把makefile和sources贴上来，或者把codeproject的链接发上来...

windbg目录下的winext子目录

应该是开始菜单、任务栏这些东西不能动了，因为提供这些UI的explorer进程中断到调试器了，但是还是可以使用Alt+Tab切换到WinDBG进程，然后执行命令，g命令恢复目标运行，就活了 :-)

太多情况都会导致蓝屏，如果要大家帮忙，请把当时的上下文贴上来。如果当时有WinDBG，就帖当时的寄存器上下文，如果没有，就打开dump文件，然后!analyze -v

不认为内存不足是因为缓存占用过高造成的，对于3G内存的系统，缓存值为1G多是很正常的，这基本上是Cache Manager所管辖的内存数，是可以动态调整的。 其实观察Resource Monitor中的内存视图（见附件）可以更直观的理解内存使用情况。 不知楼主所说的内存不足表现出何种症状？是某个应用程序报告内存不足么？如果是这样，有可能是这个应用程序的地址空间出现不足，或者内存使用不当。