Windows NT driver developer prompt-precautions to avoid

Original Discussion link:Http://community.csdn.net/expert/topicview1.asp? Id = 4738353

Forum:Hardware/SystemAudit Team:VC/MFC

Questioner:CodewarriorReleased:Codewarrior

1. Do not return status_pending through the scheduling routine without marking the iomarkirppending.
2. Do not call kesynchronizeexecution through the interrupt service routine (ISR. It causes a system deadlock.
3. Do not set deviceobject-> flags to do_buffered_io and do_direct_io. It will disrupt the system and eventually lead to fatal errors. In addition, do not set method_buffered, method_neither, method_in_direct, or method_out_direct in deviceobject-> flags, because these values are only used when IOCTL is defined.
4. Do not assign scheduling program objects through the page buffer pool. If this is done, it will occasionally lead to system fault detection (bugcheck ).
5. When running on IRQL> = dispatch_level, do not allocate memory through the page buffer pool or access the memory in the page buffer pool. This is a fatal error.
6. Do not wait for the non-zero interval of the core scheduler object on IRQL> = dispatch_level. This is a fatal error.
7. When executing on IRQL> = dispatch_level, do not call any function that causes the calling thread to wait directly or indirectly. This is a fatal error.
8. Do not reduce the interrupt request level (IRQL) to a level lower than that called by your top-level routine.
9. If keraiseirql () has not been called, do not call kelowerirql ().
10. Do not stop the processor for more than 50 microseconds.
11. Do not keep the spin lock locked for more time than you need. To improve the overall performance of the system, do not lock effective rotation locks in any system range for more than 25 microseconds.
12. When IRQL is greater than dispatch_level, do not call keacquirespinlock and kereleasespinlock, or keacquirespinlockatdpclevel and kereleasespinlockfromdpclevel.
13. Do not call kereleasespinlockfromdpclevel to release the rotation lock obtained by keacquirespinlock because it will make the original IRQL unrecoverable.
14. Do not call keacquirespinlock and kereleasespinlock in ISR or synchcritsection routines or any other routine that uses the executable rotation lock.
15. When you create a device object in a routine instead of in DriverEntry, do not forget to clear the do_device_initializing tag.
16. Do not add the delayed Procedure Call (DPC) object to the queue (using keinsertqueuedpc) in multiple threads of different processors at the same time ). This can cause fatal errors.
17. Do not release the cycle timer through the cutomertimerdpc routine. You can release a non-cyclic timer through the DPC routine.
18. Do not pass the same DPC pointer to the kesettimer, or the kesettimerex (customtimerdpc) and keinsertqueuedpc (customdpc), because this will lead to competition.
19. Do not call iostartnextpacket when rotating the lock. This will cause a system deadlock.
20. Do not call iocompleterequest when rotating the lock. This will cause a system deadlock.
21. If your driver has set the completion routine, do not call iocompleterequest without setting the completion routine to null.
22. Before calling iocompleterequest, do not forget to set the I/O status zone in the IRP.
23. Do not call iomarkpending after adding IRP to the queue or sending it to another driver (iocalldriver. Before the driver calls iomarkpending, the IRP may have been completed, and fault detection may occur. For drivers that contain completion routines, if IRP-> pendingreturned is set, the completion routine must call iomarkpending.
24. Do not access a certain IRP after calling iocompleterequest.
25. Do not call iocancelirp for IRPs that do not belong to your driver unless you know that the IRP has not been completed.
26. Before your scheduling routine returns to the caller, do not call iocancelirp for the IRP being processed by your scheduling routine.
27. Do not call iomakeassociatedirp from an intermediate driver to create IRP for a lower driver. The IRP obtained in the intermediate driver may be the associated IRP, but you cannot associate other IRPs with the associated IRP.
28. Do not call iomakeassociatedirp for the IRP set with the buffer I/O.
29. Do not simply unreference the virtual pointer pointing to the device I/O register and access these pointers. Always use the correct Hardware Abstraction Layer (HAL) function to access the device.
30. If the IRP or device object may be modified at the dispatch level, do not access it through ISR. In a symmetric multi-processor system, this can cause data corruption.
31. When running advanced IRQL, do not modify the data if the data may be written by the low-level irol code. The kesynchronizeexecution routine should be used.
32. do not obtain the driver's own rotation lock (if any) in your dispatchcleanup routine before obtaining the ioacquirecancelspinlock for the system range ). To avoid possible deadlocks, you must follow the consistent lock acquisition hierarchy in the driver.
33. Do not call ioacquirecancelspinlock In the cancel routine because the system-level cancel rotation lock has been obtained when the routine is called.
34. Do not forget to call ioreleasecancelspinlock before returning from the cancellation routine.
35. Do not use IRQL-based synchronization because it is only valid for single-processor systems. Increasing IRQL on a single processor will not mask interruptions on other processors.
36. Do not use rtlcopymemory for overlapping memory address ranges. Rtlmovememory should be used.
37. Do not assume that the page size is a constant, even for a given CPU. To maintain portability, use page_size and other page-related constants defined in the header file.
38. Do not access any registry items except REGISTRY \ MACHINE \ hardware and REGISTRY \ MACHINE \ system from the DriverEntry routine of the driver loaded during boot \ system initialization.
39. Do not create an Enum entry in the Registry (REGISTRY \ MACHINE \ System \ CurrentControlSet \ Services) of the driver to load the driver. The system dynamically creates this item.
40. if you do not apply for required bus-related I/O Ports, memory ranges, interruptions, or direct memory access (DMA) channels/ports, and other hardware resources in the registry, do not initialize a physical device.
41. Do not call ioregisterdriverreinitialization in your DriverEntry routine unless the reinitialization routine returns STATUS_SUCCESS.
42. When IRQL is passive_level, do not call the kesetevent when the wait parameter is set to true in the page-scheduled thread or driver routine. If your routine is scheduled out of the page between the call of kesetevent and kewait.. Object (s), such calls will cause a fatal page error.
43. kereleasesemaphore cannot be called under the same conditions as the preceding example.