本人负责软件从应用层一直到驱动层的全部研发任务，通过对GE产品的公开的资料反复研究，一共近70个函数接口，现在都搞明白了，由于GE产品光盘手册开源了Linux和VxWorks平台的全部软件代码，唯独不开源windows平台的动态库驱动程序代码，现在只好通过理解GE反射内存卡的Linux平台的开源代码，来参照并实现windows平台的反射内存软件系统。

          从今年三月中旬一直到现在一直都在开发这个产品软件，要求按标准接口走，真是几经周折，途中遇到太多的技术难题，涉及到不少的内核或驱动编程方面。这不，最近被一个低级的问题卡了三天，别笑啊，哈哈！！，在中断程序ISR例程调用了KeReleaseSemaphore，中断频率低的时候系统很是正常，但如果应用程序要是这样调用RFM2gRead()函数时就会出现死机或蓝屏，如：

                   

RFMSetDMAThreshold( rh, 1);  //为了压力测试，就设置DMA触发条件为“当RFMRead()函数长度参数大于1时就启动DMA传输数据”
                       while(1)
                      {
                         RFMRead(.....);      //为了体现RFM2gRead()执行的频率高，缓冲区数组长度设置越小越好（假设不理DMA启动前的系统设置开销）
                      }

                      其实也就是GE测试DEMO代码Utill命令集里的"performancetest"命令，但该命令是为了测试板卡最大的性能指标的，为了简单测试自已的RFMRead接口

                      就直接用while(1)这样的压力测试高速DMA读数据性能。

                      这样一运行，蓝屏由 1秒～5秒间就挂死了，经反复大量的测试偶尔会有蓝屏现象，用WinDbg分析dump文件IRQL_NOT_LESS_OR_EQUAL
                      错误，基本上定位在中断例程ISR函数的最后一行“return TRUE;"这一行代码上，这个BUG的确费了我3天的时间，直到今天快下班了，看到一个仁兄的帖子，

                        提到：                                              

ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);        LONG wassignalled = KeReleaseSemaphore(semaphore, boost, delta, wait);

            恍然大悟，早就知道中断处理函数ISR中代码执行的优先级是>DISPATCH_LEVEL的，然尔在这里调用KeReleaseSemaphore（）肯定是有问题的！！

               其实之前做了好多PCI板卡驱都是把调用KeReleaseSemaphore（）放在DPC延时中断处理函数中，只不过在实现这个反射内存板卡时几乎大部分

               逻辑都在驱动中实现，中断类型繁多，一时疏忽了这个细节问题,希望一个问题下次不能再犯，特此做笔记。