Windows documentation specifies strict requirements for process and thread callback functions: keep them short, avoid registry calls, skip blocking IPC functions, and never synchronize with other threads. These restrictions exist because callbacks fire during critical system operations like process creation and termination, where delays cascade into system-wide performance issues.

The guidance clarifies that developers should use System Worker Threads to queue expensive operations asynchronously. However, enterprise support teams frequently encounter drivers that technically follow this advice while violating its spirit—queuing work to background threads but then blocking until completion. This creates the same deadlock risks the rules were meant to prevent.

Raymond Chen notes the documentation was updated in 2020 to explicitly warn against waiting on queued work items. Yet some driver vendors attempt semantic workarounds, claiming they're not synchronizing with threads—they're just waiting on events. This mirrors the classic excuse of having someone else do the prohibited action.

The real issue isn't missing rules but missing understanding. Developers can memorize prohibitions while missing the underlying principle: these callbacks execute under internal system locks and must return control immediately to avoid hanging the entire operating system.