Microsoft KB Archive/832517

= How to call video miniport driver functions from a display driver =

PSS ID Number: 832517

Article Last Modified on 12/30/2003

-

The information in this article applies to:


 * Microsoft Windows Server 2003 Driver Development Kit (DDK)
 * Microsoft Windows XP Driver Development Kit (DDK)
 * Microsoft Windows 2000 Driver Development Kit (DDK)

-



SUMMARY
This article describes the recommended way for display drivers to access video miniport driver functions.

Because the display driver is in session space, and because the video miniport driver is in global kernel space, the display driver must use the guidelines that are outlined in this article to prevent a system crash or deadlock. By using these guidelines, a session-based display driver can safely access video miniport driver functions.



MORE INFORMATION
In some cases, session-based display drivers must access functions in their video miniport drivers. For example, drivers must access functions to hold a spinlock while accessing a list or to synchronize with the video miniport driver's interrupt service routine (ISR). Because no graphics device interface (GDI) functions in Win32k.sys permit session-based display drivers to perform such operations, session-based display drivers must call regular kernel functions by using the video miniport driver.

Consider the following guidelines when you try to access video miniport driver functions:  === I/O control (IOCTL) vs. static linking or dynamic linking ===

The operating system loader imposes restrictions on the libraries that a session-based driver can link to. Therefore, always use an IOCTL to query for an interface to a list of pointers in the video miniport driver. Never use a static link or a dynamic link to the miniport driver.

Dynamic linking, on the other hand, imposes no reference count on the miniport device object and does not guarantee that the miniport driver is always loaded. Therefore, the best way to call miniport driver functions is to query an interface by using an IOCTL.  === The interrupt request level (IRQL) ===

Never change the IRQL from a session-based display driver. If you do not release a spinlock before you return from a miniport driver function, or if you cause the IRQL to change in any way, system crashes and deadlocks may occur. Therefore, all session-based code and all data must be considered pageable and must run at PASSIVE_LEVEL.  === The video port device lock ===

Acquire the video port device lock when appropriate before the call to the video miniport driver, and then release the lock after the driver returns. This is to make sure that correct synchronization occurs between multiple threads that try to call the same video miniport driver function. You can acquire the device lock by using the documented video port function, VideoPortAcquireDeviceLock.  === Reentrancy issues ===

Be aware of reentrancy issues in the video miniport driver. There are some video port function calls that call back to the video miniport driver, and vice versa. If certain functions are not called in the correct order, deadlocks or data corruption may occur.  === Global data space ===

Do not store any state-specific information in the video miniport driver global data space unless you can identify the specific state that belongs to each session. Be careful when you do this; if you follow the Windows Driver Model (WDM) guidelines, you can expect no problems with this approach. 

Keywords: kbKMode kbDriver kbDDK kbhowto KB832517

Technology: kbAudDeveloper kbwin2000DDK kbwin2000Search kbWinDDK kbWinDDKSearch kbWinServ2003DDK kbWinServ2003Search kbWinXPDDKSearch

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© 2004 Microsoft Corporation. All rights reserved.