Kernel-Mode Print Drivers: Gone the Way of the Dinosaur

Kernel-Mode Print Drivers: Gone the Way of the Dinosaur

  • Comments 4
  • Likes

If you have been around since the days of Windows NT, then you are probably all too familiar with Kernel-mode Print Drivers and the devastating effect that problems with those drivers can have on system stability.  In the majority of environments, these kernel-mode drivers have been supplanted by user-mode drivers.  However, there are still many environments where applications use legacy printers that rely on kernel-mode drivers.  So what is the future for those environments and drivers?

If you think about print drivers in the simplest terms, there are two parts to all Win32 Print Drivers - one part which performs the rendering of the print job, and one part which is provides configuration options for the user.  Although the configuration piece has always run in user-mode and normally in the context of the user requesting the printing, the rendering part has moved between user mode and kernel mode.  In Windows NT4, GDI drivers for both printing and video ran in the Kernel space for performance reasons - namely that the video drivers suffered a performance hit when switching back and forth between user and kernel mode.  However, although the video drivers benefited from the move to the Kernel space, printer drivers did not.  If a printer driver experienced an error (such as a crash), the entire machine would bugcheck which resulted in stability and availability issues.

With the release of Windows 2000, the printer drivers moved back to user-mode.  Although the use of kernel-mode printer drivers was discouraged, Windows 2000 maintained compatibility with Windows NT clients and allowed both user- and kernel- mode drivers to be installed for printers.  On Windows Server 2003, the installation of kernel-mode printer drivers is disallowed by default.  However, to maintain compatibility, the installation of kernel-mode drivers can be enabled through the modification of a Group Policy setting as shown below:

image

Although the policy itself is set to "Not Configured", by default on Windows Server 2003 kernel-mode printer driver installation is blocked.  On Windows XP systems, if this setting is set to "Not Configured", kernel-mode printer driver installation is permitted.  If you have allowed kernel-mode printer drivers to be installed on Windows Server 2003 and then you change the policy to block the installation, this only affects the installation of new kernel-mode drivers.  With the release of Windows Vista, the support for kernel-mode printer drivers has been completely removed.

Moving on, I'd like to take a minute to discuss a follow up question we often get from customers regarding kernel-mode printer drivers.  The question is, "What are your recommendations in terms of managing and maintaining these drivers if we have to have them?"  My personal philosophy is this - if you absolutely have to have kernel-mode printer drivers available, then set up a separate server that hosts only the queues that require kernel-mode drivers.  The reason for this is that if by some chance one of those kernel-mode drivers fails and the server bugchecks, you don't take down your entire network printing infrastructure - in other words, you're managing the risk of having these legacy drivers in use.

And that wraps up this post.  As always, if you have feedback & comments, we're always interested to hear from you!  Until next time ...

Additional Resources:

- CC Hameed

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://aceddl.cn/x/kernel-mode-print-drivers-gone-the-way-of-the-dinosaur.jsp

  • As a former perf team member, I now work for a company that is in the medical field.  We currently utilize 16 bit print drivers for all our x-ray printer line.  These printers are using DICOM (radiology protocol over tcp-ip, app level).  Unfortunately, I believe that the whole medical community has not gotten this message yet, even after all of the BSODs and freezes.  I am all for 32 bit, but the market is not entirely ready for it I believe.

  • In previous posts we've discussed the basics of memory management including an overview of kernel and

  • [URL=http://www.greggforking.com/skins-msn-messenger] skins msn messenger [/URL]   <a href='http://www.greggforking.com/skins-msn-messenger'> skins msn messenger </a>