Video Screencast Help
Encryption Blog

PGP Whole Disk Encryption – Not the Tipping Point for BSODs!

Created: 02 Mar 2011 • Updated: 05 Nov 2012
Kelvin_Kwan's picture
+1 1 Vote
Login to vote

Most recently, we have had enterprise and individual customers complain to Symantec about BSODs pertaining to PGP Whole Disk Encryption.  Initial signs were pointing to the pgpwded.sys driver as the culprit.  Symantec’s engineering team has analyzed dozens of submitted crash dump files and has come to the following conclusion. 

Symantec believes that the BSOD is being caused by a stack space resource issue.  The reason the pgpwded.sys driver is being seen in crash dumps first is that the pgpwded.sys driver is the last to be loaded.  Thus, the pgpwded.sys driver seems to be the tipping point for the BSOD.  But it is not, in fact, the cause.  Here’s why.

Caution:  Geek material ahead!  A quick summary on stack space. 
Stack space is limited and is a shared resource between the Windows kernel runtime and device drivers on a particular kernel thread.  If a thread runs out of kernel stack space, the system will crash and cause a BSOD.  Unfortunately, kernel mode components cannot reserve stack space (it is a free-for-all!) and Microsoft advises to use as little stack space as possible.  All you need is for one driver to occupy the majority of stack space, and BSODs will bloom like flowers in the spring!

There are approximately 12,000-bytes of stack space available for sharing.  In all versions of PGP WDE 10.0.2 and prior, the pgpwded.sys driver used 600-bytes of stack space.  In versions 10.1.x and newer, the pgpwded.sys driver uses only 100 bytes of stack space.  As good corporate citizens, we realized early on that we should reduce our stack space usage as other drivers might not be nearly as efficient as ours.  Symantec proactively reduced our stack space usage before this BSOD issue occurred.

Microsoft recently released a security update (see KB 2393802 for more information) which seems to utilize more stack space in the Windows kernel than previously used.  This is the actual tipping point of over usage of the total stack space. 

There are a couple of things you can do to resolve this issue:
1.  Uninstall the Windows security update.  We, however, DO NOT recommend this as it is a security related update.  We are, after all, a security company, so security is paramount to us.
2.  Upgrade from your current version of PGP Desktop to 10.1.x.  This will free up some stack space as the pgpwded.sys driver usage goes from 600-bytes down to only 100-bytes.  You can do an in-place upgrade to your already encrypted disk.
3.  Shrink the drivers in your stack space to utilize less stack space.  The question really then becomes, "How?"  We have found that a lot of the users running into this BSOD issue are running older versions of the Intel graphics accelerator driver, which uses about 7,000-bytes of the stack space.  We have reports that current Intel drivers that work well include versions 6.14.10.5218, 6.14.10.5303, and 6.14.10.5313.  The problematic drivers seem to be the following versions:  6.14.10.5179, 6.14.10.5220, 6.14.10.5225, and 6.14.10.5294.  We, of course, cannot test out every release of the Intel graphics driver, but this has been fairly consistent in our testing and that of our customers.  So YMMV here, you may wish to check the support forum and post your results if you think they can help others. 

In conclusion, PGP is not the culprit in this BSOD issue.  The real issue is the lack of stack space that is available.  This is why we see this BSOD issue on some systems but not others.  This issue also occurs without PGP WDE installed.  The recommendations I would make would be to go with options #2 first and also proactively do option #3 as well.  The more free room you have left in the stack space today, the less chance you will run into a BSOD tomorrow caused by stack space usage.

 

External reading:
http://news.cnet.com/8301-27080_3-10452064-245.html
http://blogs.technet.com/b/msrc/archive/2010/02/11/restart-issues-after-installing-ms10-015.aspx