在windows环境下使用wdf框架开发pcie驱动的dma读写功能时，启动一次dma传输需要两个步骤：
初始化DMA传输对象：在初始化DMA传输对象时，应将本次DMA传输的数据缓冲区的地址和长度写入该对象，并向其注册用于配置并启动DMA传输的回调函数PCIeEvtProgramWriteDma。该回调函数会获取缓冲区地址和长度，通过PIO方式配置PCIe Bar空间上的寄存器，以通知硬件启动DMA传输。
执行DMA传输：在执行DMA传输时，驱动仅需调用WDF框架的WdfDmaTransactionExecute函数，操作系统就会调用上一步注册的回调函数对硬件进行配置并启动DMA传输。
通常情况下，驱动调用一次WdfDmaTransactionExecute函数，操作系统应调用一次回调函数进行硬件配置。然而，在我们更换了硬件平台（CPU+FPGA）后，DMA写流程出现了严重问题。具体表现为：驱动的一次调用可能会导致操作系统多次调用回调函数，且每次回调函数都会完整执行并触发DMA写完成中断。这种情况导致驱动的中断状态机被打乱，表现为后续的DMA写开始中断丢失，无法正常启动DMA写。
如图1所示，图中显示了驱动调用WdfDmaTransactionExecute函数的次数与操作系统调用回调函数的次数不一致的情况。
图1 DebugMonito监测
其中，5658（5576+82+0）为驱动调用WdfDmaTransactionExecute函数的次数，5664为操作系统调用回调函数的次数。二者之间差6就是操作系统重复调用的次数。
我们尝试将操作系统多出来的调用回调函数的次数跳过，即仅保留第一次调用。硬件侧可以正常完成这次DMA传输，并触发DMA写完成中断。但驱动去查询DMA传输对象时，发现此次DMA传输并未处于完成状态，即无法正常接收数据。我们猜测，操作系统多次调用回调函数的原因是其认为配置过程出错才重新进行配置，直至最后一次成功。而硬件侧并不会感知到这种错误，每次都正常启动DMA写并触发DMA写完成中断，导致驱动的中断状态机跑飞。
问题排查到此，我们无法深入到闭源的Windows操作系统内部去探究错误原因。因此，我们转而考虑能否为中断状态机提供一些保障机制。
为了方便调试，我们在中断处理程序中添加了许多关键的调试日志信息，结果在其中发现了端倪。
图2 日志打印记录
观察图2中的日志，发现两个中断延迟处理函数MPHandleInterrupt在并行执行。在这个过程中，用于临时拷贝中断寄存的变量Adapter->IsrCode_dpc被覆盖重写。覆盖的直接后果是，前者已读取到的寄存的中断，后者覆盖后就无法由中断延迟处理程序进行处理。
这种现象显然是不合理的。为了解决这个问题，我们为MPHandleInterrupt函数内部加锁，防止MPHandleInterrupt并行执行。通过这种方式，中断寄存被覆盖的现象不再发生。
