Developing and Debugging DRM Drivers

The following checklist may help driver writers avoid some common pitfalls:

• If the driver disables wave-out capture and S/PDIF output while DRM-protected content plays, the driver should remember to enable them again after the DRM-protected content finishes playing (and the DRM buffer is destroyed).
• If the device performs hardware mixing, the driver should keep track of any changes in composite usage rights that occur when streams are added to or removed from the mix. Any time the mix includes one or more copy-protected DRM streams, for example, capture should be muted. It should remain muted if capture is turned on while the protected mix is playing.
• After a change to the filter graph or to the property settings that are associated with a stream, the driver might need to immediately update the stream's copy-protection and output-enable settings. The driver should synchronize its operation to prevent protected content from being copied to a capture buffer or digital output. For example, when the input stream to a capture multiplexer changes, the driver should not allow secure content to become vulnerable during the time required to turn muting on and off.

As mentioned previously, kernel support for DRM is only available in Windows Me, and in Windows XP and later. If a driver attempts to call a DRM function such as DrmCreateContentMixed in Windows 98 or Windows 2000, that call fails. Some vendors might prefer to write a single driver that takes advantage of DRM features in operating systems that support them, but that can still run on older versions of Windows. One approach is for a WaveCyclic or WavePci miniport driver to query the port driver for its IDrmPort2 interface, which is supported only in Windows XP and later. Of course, that query fails not only in Windows 98 and Windows 2000, which do not support kernel-mode DRM at all, but also in Windows Me, which supports the original DRM functions but lacks support for IDrmPort2 (and IDrmPort).

While developing your driver's DRM functionality, you might need to generate test files with content that is protected by a variety of DRM security levels. The SAPTool, which is included with the Platform SDK tools, can be used for this purpose. This tool accepts as input an unprotected file in .wma or .asf format. It generates an output file with one of several DRM security levels that the user can choose from.

The DRMK system driver prevents the kernel debugger from connecting while DRM-protected content is playing. Anti-debugging armor is one of several measures that DRMK uses to make protected content opaque. Once your driver is ready to be tested, however, you can debug its DRM-compliant features by using the following technique:

• Temporarily modify the wave stream's SetState method (for example, see IMiniportWavePciStream::SetState) to call IDrmAudioStream::SetContentId and set the DRMRIGHTS parameter's CopyProtect member to TRUE.
• After you finish debugging, remember to remove the SetContentId call.

With this technique, you can play unprotected content as though it were DRM-protected content but avoid disabling the debugger.

For example, you can use the debugger to verify that your driver prevents the content from being recorded. Try to trick the driver into enabling recording of the wave-out stream through the capture MUX by changing the SndVol32 program's volume and mute settings. The sliders should reflect the changes you make to their settings, which are persistent, but the capture MUX should continue to mute the wave-out stream until the "protected" content finishes playing. Only then should the new settings take effect.