Windows Driver Kit (WDK) Documentation Blog

WDK to Continue Posting Documentation in CHM Format

Thanks for all the feedback regarding the CHM version of the WDK documentation.  Based on your overwhelmingly positive response, we’ll continue posting the CHM version to WHDC at major Windows release intervals (Beta, RC, RTM, etc.).  The CHM for the Windows 7 RTM release will be posted near the end of July.

Update to Windows 7 RC Version of the XPS Rasterization Filter Service Sample

Here are two updates that will help Printer driver developers who are working with the RC version of the XPS Rasterization Filter Service sample.

1.       If you are using the RC version of the XPS Rasterization Filter Service sample, it is strongly recommended that you work directly with the WIC bitmap returned from the XPS Rasterization service rather than the calls into WIC to encode each band as a TIFF. The sample calls into WIC for encoding each band were for demonstration purposes only and are not recommended for larger applications because they could be inefficient and difficult.

2.       In the sample, the output file consists of a series of per-band TIFFs. Because this file will be a series of complete TIFFs and not a single-page TIFF, opening the file in a viewer will only display the first band of the first page. More details can be found in the bitmaphandler.cpp file that is included in the sample source code.

The Windows 7 RTM version of the sample documentation will include this update. In the meantime, until Windows 7 is released, apply these changes to the sample documentation at http://msdn.microsoft.com/en-us/library/dd434895.aspx.

  －Seth McEvoy [MSFT], WDK Senior Programming Writer

 

 

Kernel Programming: Nt and Zw Versions of the Native System Services Routines

The Windows native operating system services API is implemented as a set of routines that run in kernel mode. These routines have names that begin with the prefix Nt or Zw. Kernel-mode drivers can call these routines directly. User-mode applications can access these routines through system calls.

With a few exceptions, each native system services routine has two slightly different versions that have similar names but different prefixes. For example, calls to NtCreateFile and ZwCreateFile perform similar operations and are, in fact, serviced by the same kernel-mode system routine. For system calls from user mode, the Nt and Zw versions of a routine behave identically. For calls from a kernel-mode driver, the Nt and Zw versions of a routine differ in the way that they handle the parameter values that the caller passes to the routine.

A kernel-mode driver calls the Zw version of a native system services routine to inform the routine that the parameters come from a trusted, kernel-mode source. In this case, the routine assumes that it can safely use the parameters without first validating them. However, if the parameters might be from either a user-mode source or a kernel-mode source, the driver instead calls the Nt version of the routine. The Nt version determines, based on the history of the calling thread, whether the parameters originated in user mode or kernel mode. (How does the Nt routine distinguish user-mode parameters from kernel-mode parameters? See Previous Mode, below.)

When a user-mode application calls the Nt or Zw version of a native system services routine, the routine always treats the parameters that it receives as values that come from an untrusted, user-mode source. The routine thoroughly validates the parameter values before it uses the parameters. In particular, the routine probes any caller-supplied buffers to verify that the buffers reside in valid user-mode memory and are properly aligned.

Native system services routines make additional assumptions about the parameters that they receive. If a routine receives a pointer to a buffer that was allocated by a kernel-mode driver, the routine assumes that the buffer was allocated in system memory, not in user-mode memory. If the routine receives a handle that was opened by a user-mode application, the routine looks for the handle in the user-mode handle table, not in the kernel-mode handle table.

PreviousMode

When a user-mode application calls the Nt or Zw version of a native system services routine, the system call mechanism traps the calling thread to kernel mode. To indicate that the parameter values originated in user mode, the trap handler for the system call sets the PreviousMode field in the thread object of the caller to UserMode. The native system services routine checks the PreviousMode field of the calling thread to determine whether the parameters are from a user-mode source.

If a kernel-mode driver calls a native system services routine and passes parameter values to the routine that are from a kernel-mode source, the driver must ensure that the PreviousMode field in the current thread object is set to KernelMode.

A kernel-mode driver can run in the context of an arbitrary thread, and the PreviousMode field of this thread might be set to UserMode. In this situation, a kernel-mode driver can call the Zw version of a native system services routine to inform the routine that the parameter values are from a trusted, kernel-mode source. The Zw call goes to a thin wrapper function that overrides the PreviousMode value in the current thread object. The wrapper function sets PreviousMode to KernelMode and calls the Nt version of the routine. On return from the Nt version of the routine, the wrapper function restores the original PreviousMode value of the thread object and returns.

A kernel-mode driver can directly call the Nt version of a native system services routine. When a kernel-mode driver processes an I/O request that might have originated either in user mode or in kernel mode, the driver can call the Nt version of the routine to ensure that the PreviousMode value of the current thread remains unaltered during the call. That way, the routine can determine whether the parameter values are from a user-mode application or a kernel-mode component, and treat them accordingly.

An error can occur if a kernel-mode driver calls an NtXxx routine and the PreviousMode value in the current thread object does not accurately indicate whether the parameter values are from a user-mode or a kernel-mode source.

For example, assume that a kernel-mode driver is running in the context of an arbitrary thread, and that the PreviousMode value for this thread is set to UserMode. If this driver passes a kernel-mode file handle to the NtClose routine, this routine attempts to close the user-mode handle of the arbitrary thread instead of the kernel-mode handle. When NtClose fails to find the handle in the user-mode handle table, it returns the STATUS_INVALID_HANDLE error code. Meanwhile, the driver leaks the kernel-mode handle, which was never closed.

For another example, if the parameters for an NtXxx routine include an input or output buffer, and if PreviousMode is UserMode, the routine calls the ProbeForRead or ProbeForWrite routine to validate the buffer. If the buffer was allocated in system memory instead of in user-mode memory, the ProbeForXxx routine raises an exception, and the NtXxx routine returns the STATUS_ACCESS_VIOLATION error code.

If necessary, a driver can call the ExGetPreviousMode routine to get the PreviousMode value from the current thread object. Alternatively, the driver can read the RequestorMode field from the IRP structure that describes the requested I/O operation. The RequestorMode field contains a copy of the PreviousMode value from the thread that requested the operation.

What Does the Zw Prefix Mean?

The Windows native system services routines have names that begin with the prefixes Nt and Zw. The Nt prefix is an abbreviation of Windows NT, but the Zw prefix has no meaning. Zw was chosen partly to avoid potential naming conflicts with other APIs, and partly to avoid using any potentially useful two-letter prefixes that might be needed for future APIs.

Today, the ZwXxx routines are more visible to drivers and to applications than the kernel architects might have anticipated in the early days of Windows NT development. In retrospect, perhaps a more meaningful prefix could have been chosen.

  – Jerry Van Aken [MSFT], WDK Programming Writer

 

 

Self-checkout Machines, Portable EKG devices and Windows Audio

So I was about to start using a self-checkout machine in a grocery store when service tech asked me to use the next one over, so he could service the one I was about to use. I obliged and he proceeded to work his magic. After he was done, he rebooted the machine and to my surprise and I saw the familiar Windows XP boot screen. The boot sequence was quiet with no fanfare and no other sounds.

Two days later, I was waiting for test results in the lab at my primary care clinic and noticed a laptop on a cart. The laptop had a USB device plugged into it, with what seemed like a ton of electrodes connected to the other end of the USB device. I went over to investigate and noticed that the laptop was running (you guessed it) Windows XP and the USB device had a label that indicated that it was an EKG device.

These two close encounters with Windows XP showed the versatility of this operating system. I was also left with a new appreciation for one of the topics that I just completed to describe a new feature that that has been added to Widows 7.

A new registry key, PKEY_AudioDevice_NeverSetAsDefaultEndpoint, has been added to Windows 7 to allow you to configure certain devices (like the portable EKG device, for example) so that they can never be selected as default audio devices. Say for example, that a service tech forgets to reverse audio settings he made while servicing the portable EKG device. It would be very unprofessional to boot up this EKG device later on in a hospital room and have to wait a few minutes while Windows XP initialized Media Player and then proceeded to apply the latest skins, in preparation to play music through the beeper in the EKG device!

In Windows 7 and later versions of Windows, this would be a non-issue because if the laptop were running Windows 7, as soon as you rebooted the laptop, it would apply the default settings and undo the previous selection of the EKG device as the default audio device.

The topic with more information about PKEY_AudioDevice_NeverSetAsDefaultEndpoint will be available on MSDN in the next month.

  － Eric Doku [MSFT], WDK Programming Writer

WDK Kernel Programming: Object Reference Tracing with Tags

Kernel objects are primitive data objects that the Windows kernel implements in system memory to represent the various features of the computing environment that are managed by the operating system. Kernel objects represent features such as devices, drivers, files, registry keys, events, semaphores, processes, and threads.

Most kernel objects are not permanent. To prevent a nonpermanent kernel object from being deleted while a kernel-mode driver uses the object, the driver can acquire a counted reference to the object. When the driver no longer needs the object, the driver releases its reference to the object.

If a driver fails to release all of its references to an object, the object's reference count never decrements to zero and the object is never deleted. Thus, any system resources that are used by the object (for example, system memory) are leaked. That is, they are unavailable for use until the next time that the operating system starts up.

Another type of reference error occurs if a driver under-references an object. In this case, the driver releases more references to an object than the driver actually holds. This error can cause the object to be deleted prematurely, while other clients are still trying to access the object.

Leaks and under-references of kernel objects can be difficult bugs to track down. For example, a process object or a device object might have tens of thousands of references. To identify the source of a reference bug in these circumstances can be a tedious and frustrating task.

In Windows 7, object references can be tagged to make these bugs easier to find. The Windows kernel developers have added a new set of routines to associate tags with references to kernel objects. These new routines are ObReferenceObjectWithTag, ObReferenceObjectByHandleWithTag, ObReferenceObjectByPointerWithTag, ObDereferenceObjectWithTag, and ObDereferenceObjectDeferDeleteWithTag.

For example, ObReferenceObjectWithTag and ObDereferenceObjectWithTag are enhanced versions of the familiar ObReferenceObject and ObDereferenceObject routines. These enhanced routines enable you to supply a four-byte, custom tag value as an input parameter. The tag value for each call gets added to an object reference trace that can be accessed by the Windows debugging tools. Although ObReferenceObject and ObDereferenceObject do not enable the caller to specify custom tags, the Windows 7 versions of these routines add default tags (with tag value "Dflt") to the trace. Thus, a call to ObReferenceObject or ObDereferenceObject has the same effect as a call to ObReferenceObjectWithTag or ObDereferenceObjectWithTag that specifies a tag value of "Dflt". (In your program, this tag value is represented as 0x33796b4c or 'tlfD'.)

To track down a potential object leak or under-reference, identify a set of associated ObReferenceObjectXxxWithTag and ObDereferenceObjectXxxWithTag calls in your driver that increment and decrement the reference count of a particular object. Choose a common tag value (for example, "Lky8") to use for all of the calls in this set. After your driver is done using the object, the number of decrements should exactly match the number of increments. If these numbers do not match, your driver has an object reference bug. The debugger can compare the number of increments and decrements for each tag value and tell you if they fail to match. With this capability, you can rapidly pinpoint the source of the reference-count mismatch.

To view an object reference trace in the Windows debugging tools, use the !obtrace kernel-mode debugger extension. In Windows 7, the !obtrace extension is enhanced to display object reference tags, if object reference tracing is enabled. By default, object reference tracing is turned off. Use the Global Flags Editor (Gflags) to enable object reference tracing. For more information about Gflags, see Configuring Object Reference Tracing.

After object reference tracing is turned on, the output that is produced by the !obtrace extension includes a "Tag" column, as the following example shows:

0: kd> !obtrace 0x8a226130

Object: 8a226130

 Image: leakyapp.exe

Sequence   (+/-)   Tag   Stack

--------   -----   ----  ---------------------------------------------

      36    +1     Dflt      nt!ObCreateObject+1c4

                             nt!NtCreateEvent+93

                             nt!KiFastCallEntry+12a

 

      37    +1     Dflt      nt!ObpCreateHandle+1c1

                             nt!ObInsertObjectEx+d8

                             nt!ObInsertObject+1e

                             nt!NtCreateEvent+ba

                             nt!KiFastCallEntry+12a

 

      38    -1     Dflt      nt!ObfDereferenceObjectWithTag+22

                             nt!ObInsertObject+1e

                             nt!NtCreateEvent+ba

                             nt!KiFastCallEntry+12a

 

      39    +1     Lky8      nt!ObReferenceObjectByHandleWithTag+254

                             leakydrv!LeakyCtlDeviceControl+6c

                             nt!IofCallDriver+63

                             nt!IopSynchronousServiceTail+1f8

                             nt!IopXxxControlFile+6aa

                             nt!NtDeviceIoControlFile+2a

                             nt!KiFastCallEntry+12a

 

      3a    -1     Dflt      nt!ObfDereferenceObjectWithTag+22

                             nt!ObpCloseHandle+7f

                             nt!NtClose+4e

                             nt!KiFastCallEntry+12a

                            

--------   -----   ---------------------------------------------------

References: 3, Dereferences 2

Tag: Lky8 References: 1 Dereferences: 0 Over reference by: 1

The bottom line in the preceding example indicates that the reference and dereference counts that are associated with the "Lky8" tag do not match and that the result of this mismatch is an over-reference by one (that is, a leak). If the result were instead an under-reference, the bottom line of the !obtrace output might look like this:

Tag: Lky8 References: 1 Dereferences: 2 Under reference by: 1

By default, the operating system conserves memory by deleting the object reference trace for an object when the object is freed. To track down an under-reference requires that the trace remain stored in memory even after the object has been freed. For this purpose, the Gflags tool provides a "Permanent" option, which preserves the trace in memory while the computer shuts down and starts up again.

Object reference tracing—without tags—was introduced in Windows XP. Because the trace did not include tags, developers had to resort to less convenient techniques to identify object reference bugs. The debugger could track the references of groups of objects, which the developer selected by object type. The only way that the developer could identify the various sources of object references and dereferences was to compare their call stacks. Although the preceding !obtrace example contains only five stacks, certain types of object, such as a process (EPROCESS) object, might be referenced and dereferenced many thousands of times. With thousands of stacks to inspect, the task of identifying the source of an object leak or under-reference without the help of tags might be very time consuming.

Special thanks to Salahuddin J. Khan of the Windows kernel development team for providing the information for this blog entry.

 

   – Jerry Van Aken [MSFT], WDK Programming

Send us feedback on any WDK Help topic - 24/7

Go ahead. We are ready. We want to hear from you. As we mentioned in a previous blog post, starting with the MSDN update in May, we have added a new feedback link to the bottom of our online WDK pages. When you click this new link the e-mail you send is directed to the writer of the topic. Sure, we might not be able to get to it right away, not all of us are awake at 3:00 am in the morning, but we will get your message.

Along with the new feedback link is a system that we use to guarantee your privacy. When you send e-mail about a topic, a special feedback bug is created. We only keep your e-mail for a short time. When we have read and responded to your e-mail or the issue is resolved (within 90 days), your e-mail and all personal identifying information is automatically removed from the database. You are free and clear, and you won’t end up on some mailing list.

Where is that feedback link again? How does it work?

The link is in the footer at the bottom of the page. Here is a screenshot of the DriverEntry topic on MSDN. Notice the circled Send feedback on this topic link at the bottom of the page.

 

Also make note of the “Built on” date. This is your guarantee of freshness. We are now able to do more frequent updates to our MSDN documentation (about once a month). So when you report errors or have suggestion for improvements there is a good chance that we will be able to respond to your feedback and update topics in a relatively short time. If you don’t like what you see, send us some feedback. If you like what you see, that’s even better. Send us your feedback and let us know and we will try to do more of the same.

Stars upon thars

For our online MSDN documentation, the new Send feedback on this topic link is a supplement to the existing MSDN page rating. You can rate a page by clicking the Click to Rate and Give Feedback link at the topic of the page. Unlike the Sneetches in the Dr. Seuss story, the stars ultimately do matter to us. They make a difference. When you rate the page it helps us know what is working and what is not. The star ratings help us find those topics that are causing you the most headaches.  And they also help us find topics that are making your tasks a little easier. Using the star ratings and the statistics on the volume of traffic the topics receive on MSDN, we can locate the bottlenecks and traffic jams. This gives us a better map of where we need to apply our efforts.

Confused? What’s up with the multiple feedback links?

Options. That’s all. We are just giving you options. There are multiple ways you can send ups feedback and this is a good thing. If you primarily work with our offline documentation, available when you download the WDK Kit or download the WDK Documentation, you can send us feedback from the Send feedback on this topic link at the footer of every topic. With the release of the WDK kit for Windows 7, our offline documentation will be using the same feedback mechanism we rolled out on MSDN. Use these links when you want to send e-mail with your comments, corrections, or suggestions. If you are reading a WDK topic on MSDN and feel particularly moved (positively or negatively), click the Click to Rate and Give Feedback link. It’s quick, anonymous and relatively painless. Unlike political elections, with page ratings you can vote early and vote often. Let us know how we are doing.

We look forward to hearing from you.

－Dave Hagen [MSFT], WDK Technical Writer

Windows 7 RC WDK Documentation Refresh with Improved Feedback Link

The WDKUA team is pleased to announce that we have refreshed the WDK documentation for Windows 7 RC on MSDN. You can view the documentation at: http://msdn.microsoft.com/en-us/library/aa972908.aspx

We have also provided an improved feedback mechanism with this documentation refresh. Near the bottom of each WDK documentation topic is a “Send feedback on this topic” link. You can use the link to provide targeted topic feedback to the WDK documentation team. Please note that while we attempt to address relevant submissions in a timely manner, it may take awhile for us to update any given topic.

The Windows 7 RC WDK documentation has also been posted on WHDC. You can download it at: http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx

  －Kevin Shirley [MSFT], WDK Programming Writer

 

Have You Followed a Roadmap Lately?

For the past year we have been posting “developer roadmaps” for many driver technologies. Like any map, they are intended to help you get from a starting point to a destination. We’ve tried to focus roadmaps on helping you, if you are new to a technology, to learn about the available driver models, architectural considerations, and nuts-and-bolts of installation and testing to finally complete a working driver that can be provided to customers.

So, we’re wondering how these roadmaps have been working. We’re looking for ways to improve procedures, links, and information in the roadmaps so that you can most efficiently complete typical development tasks.

Can you take a few minutes to help us improve the roadmaps? Just add a comment to this blog post, or send us an email at ddksurv1@microsoft.com. This is what we're looking for:

1.      Name any roadmap(s) that you have used—see the list below.

2.      Rate the usefulness of the roadmap, from 1 (poor) to 5 (excellent).

3.      What was your level of driver development knowledge before you read the roadmap--beginning, intermediate, or expert?

4.      Explain how the roadmap helped you (or not) to complete a driver development project or to learn about a technology.

5.      Provide any real-world examples of what caused you difficulty, or what worked well.

6.      Add any other thoughts about the roadmap, or about topics that it links to, or suggest other types of roadmaps that you’d like to see.

If you can suggest better ways to get developers up to speed and pointed in the right direction, we’d love to hear your opinions!

Here are the WDK roadmap topics currently available on MSDN:

Roadmap for Developing WDM Audio Drivers

Roadmap for Developing Biometric Drivers

Roadmap for Developing Drivers for the Windows Vista Display Driver Model

Roadmap for Developing Drivers for the Windows 2000 Display Driver Model

Roadmap for Developing Native 802.11 Wireless LAN Drivers

Roadmap to Develop MB Miniport drivers

Roadmap for Developing WFP Callout Drivers

Roadmap for Developing Network Drivers with Winsock Kernel

Roadmap for Developing Streaming Minidrivers

  － Mark Lawler [MSFT], WDK Programming Writer

 

WDK Documentation Feedback Results for 2008

The WDK documentation team is listening. That is, if you click the "Send feedback on this topic" link (ddksurv1@microsoft.com) that is included at the end of each WDK topic to send feedback about that topic, we investigate, and if necessary fix, your issue with that topic. We are happy to get your feedback because we are always striving to improve the WDK documentation. The following table shows the breakdown of feedback that we received and investigated in 2008 by technology. This feedback only applies to customers of the WDK (the actual kit) and not to customers who access the WDK documentation from MSDN.

Technology	Number of feedback messages
Kernel Architecture	23
Installable File System	18
Tools	16
Networking	14
Storage	11
Display	6
Input	5
Print	4
WDF-KMDF	4
WDF-UMDF	3
Streaming Media	2
Buses and Ports	2
Audio	1
Device Installation	1
Infrared	1

  - John Jackson [MSFT], WDK Senior Programming Writer

New WDK Documentation on WHDC and MSDN

The March refresh of the WDK documentation is now live on the WHDC site and on MSDN.

We listened to your strong positive feedback on the chm version of the docs, so you'll find a new chm on WHDC as well!

Online docs:

http://msdn.microsoft.com/en-us/library/aa972908.aspx

Hxs and chm versions:

http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx

Thanks,

Ted Hudek, Sr. Content Publishing Lead [MSFT]

MSDN Tips and Tricks: Loband and T to toggle TOC

Tired of MSDN pages taking too long to load?

 

You can now take advantage of a new feature in the MSDN online library called Low Bandwidth display, or “loband” for short.  To view a low bandwidth version of a given page, add the word “(loband)” right before the “.aspx” in an MSDN URL.  Simple as that! 

 

For example, here is the parent node of the WDK documentation viewed in regular (high bandwidth) mode:

 

http://msdn.microsoft.com/en-us/library/aa972908.aspx

 

And in low bandwidth mode:

 

http://msdn.microsoft.com/en-us/library/aa972908(loband).aspx

 

For more details, see Jon Galloway’s excellent post on the subject.  His article includes a handy bookmarklet that allows you to flip back and forth between regular (high) bandwidth and loband.

 

While we’re on the subject of MSDN, try typing “t” from a regular bandwidth MSDN library page.  You’ll see that this toggles the appearance of the TOC in the left pane.

 

Happy surfing!

 

Thanks,

Ted Hudek, Sr. Content Publishing Lead [MSFT]

New for Windows 7 – Distributed Scan Management

Distributed Scan Management is a new Windows 7 feature that will make it easier and more efficient for corporations to use scanners to create and route documents in their business networks. In the past, corporate IT departments often found it difficult to include paper-based scanned documents into their electronic communications. Distributed Scan Management is an innovative new technique that makes it possible to easily use scanners to integrate paper information into corporate computer-based networks more effectively than ever before.

For example, this could be used when a corporate employee has to submit paper receipts for business expenses. With Distributed Scan Management, an employee could use a scanner to submit them electronically. They would first put the receipt into the scanner and the scan management system would be able to authenticate the employee's status and then offer them a set of choices on where to deliver the receipt information, such as an email address, a SharePoint server, or a file server.

For Windows 7, the WDK documentation will provide programming information that scanner manufacturers will need in order to develop code for this new distributed scanning system. For more information, see http://go.microsoft.com/fwlink/?LinkId=144358

  -- Seth McEvoy [MSFT], WDK Senior Programmer Writer

New for Windows 7 - XPS Print Driver Rasterization Service

The new XPS Print Rasterization service has been created to convert XPS documents to bitmaps, simplifying printer driver development by eliminating the need to write your own XPS filter conversion routine. Previous to Windows 7, you had to write extensive code to convert XML-based XPS documents to raster-based bitmaps. By making just a few simple method calls, you can take advantage of this new rasterization service to transform fixed pages in an XPS document to bitmap images suitable for your print device.

How Does It Work?

The XPS Print Driver Rasterization service is easy to use. You need to write only a few lines of COM filter code to access this feature.

The steps for using this service in an XPSDrv COM filter are:

·         Get a reference to the Rasterization factory object from the print pipeline property bag. Use the IPrintPipelinePropertyBag::GetProperty method to retrieve the MS_IXpsRasterizationFactory object reference.

·         IUnknown::QueryInterface to get the IXpsRasterizationFactory interface.

·         Then call the IXpsRasterizationFactory::CreateRasterizer method to create XPS rasterizer objects.

·         Create a new rasterizer object for every fixed page you want to render to a bitmap.

·         When the factory object is no longer needed, the filter should release the object by calling the Release method on the object's IXpsRasterizationFactory interface.

The interfaces that are provided by the Rasterization service are:

IXpsRasterizationFactory

This interface provides a way to create rasterizer objects. It has one method, IXpsRasterizationFactory::CreateRasterizer, which creates a rasterizer object. You need one object for each XPS page you want to convert to a bitmap.

IXpsRasterizer

This interface does the actual conversion. It has two methods:

·         IXpsRasterizer::RasterizeRect, which converts an XPS page to a bitmap.

·         IXpsRasterizer::SetMinimalLineWidth, which sets the minimum line width for the conversion.

An XPSDrv filter should also implement the following interface if it needs to cancel an in-progress XPS rasterization operation before the operation completes:

IXpsRasterizerNotificationCallback

This callback needs to implement one method, IXpsRasterizerNotificationCallback::Continue, which tells the rasterization service whether it should continue the conversion process or not.

Note:   Because XPS Print Driver Rasterization service is a new development for Windows 7, it is not available on previous versions of Windows.

Want More Information?

See the following Windows Driver Kit topics:

• Using the XPS Rasterization Service at http://go.microsoft.com/fwlink/?LinkId=144356
• XPS Rasterization Service Reference at http://go.microsoft.com/fwlink/?LinkID=144357

   -- Seth McEvoy [MSFT], WDK Senior Programmer Writer

New Registry Routine – ZwOpenKeyEx Added to the Kernel

A new registry routine has just been added to the Windows kernel and is now available on MSDN.

This new ZwOpenKeyEx routine is an extension of ZwOpenKey and provides you with two new options to apply when opening a registry key by using the added OpenOptions parameter with the appropriate flags.

The new ZwOpenKeyEx flag options for OpenOptions are:

REG_OPTION_CREATE_LINK

Specifies that the key is a symbolic link.

REG_OPTION_BACKUP_RESTORE

Specifies that the key should open with special privileges that allow backup and restore operations.

Note that these new options are not used by device or intermediate drivers.

Check it out at http://msdn.microsoft.com/en-us/library/dd535803.aspx.

  -- Seth McEvoy [MSFT], WDK Doc Blogmaster

WDK Documentation Survey - We Need Your Opinion!

What do you think about the WDK documentation?  Does it totally stink or do you think it’s pretty good as-is?  Do you want more sample drivers, or not?  Just what do and don’t you like about the WDK in general?

Well now you have another opportunity to let us know.

Simply reserve about 8 to 10 minutes to complete the following anonymous survey about the current release of the WDK.  With your help, we will continue to improve the quality of the WDK and its documentation:

https://www.surveymonkey.com/s.aspx?sm=2I4RZU_2fFLaUEfE1UMKlpuQ_3d_3d

Your honest feedback is important, and I very much appreciate it.

   -- Karlito Bonnevie [MSFT], Installable File Systems Programming Writer