Windows 7 BSOD: Process Has Locked Pages

I was working along in Windows 7, when suddenly I got a blue screen of death (BSOD).  The error message was PROCESS_HAS_LOCKED_PAGES.  The STOP code was 0x00000076.  I wasn’t sure what this meant, and decided to take a moment to figure it out.

A search led to a Microsoft Bug Check page for error 0x76.  That page suggested, generally, making sure I was current in Control Panel > Windows Update; scanning the computer for viruses; and checking the hard drive for errors.  I took these to be generic suggestions, not intended for this problem in particular; I noticed that they appeared in each of three other Microsoft Bug Check pages that I opened at random.  That did not make them bad advice; they just did not seem to address this particular odd situation with any specificity.

The Bug Check page noted that the BSOD would have shown me values of either 0x00 or 0x01 for each of four different parameters.  I believed that was correct.  Sadly, I had not recorded those four values before rebooting.  Either way, though, the essence of these options seemed to be that the error had something to do with a driver’s faulty approach to locked memory pages.  I did not remember what I had been doing right before the crash, so I was not sure which driver would have been at issue.

The thought did cross my mind that Windows 7, like the versions of Windows before it, worked best when it was periodically rebooted, so as to clear out memory and give all my running programs a chance to catch their breath.  In that regard, we could clearly say, “Mission Accomplished.”  But I wondered whether I could use the memory dump for further insight.

As suggested in a previous post and developed subsequently, I located the memory dump by going to Start > Run and typing %systemroot%.  As expected, that put me into C:\Windows.  Having made some changes suggested by that previous post, I did now have a C:\Windows\Minidump folder.  Unfortunately, its newest entry was nearly seven weeks old.  There was nothing from today’s crash.  Retracing the steps from that previous post, I saw that at some point I had apparently removed the paging file from drive C.  I was not sure whether that was also responsible for the fact that the alternative C:\Windows\MEMORY.DMP also dated from about seven weeks ago.  A general search for *.dmp files produced only one from this day, and that was a Firefox crash report from C:\Users\Ray\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending.  Just in case, I went into Start > Run > sysdm.cpl > Advanced tab > Settings > Advanced tab > Virtual memory Change > highlight drive C > Custom size > 800MB (both initial and maximum sizes) > Set.  Then I okayed out of there.  So at least I would have that in place for next time (and I would have to remember to exclude the large and extraneous C:\pagefile.sys from any drive C backups).

Just to double-check that I was not missing a current *.dmp file from somewhere, I ran BlueScreenView.  Correctimundo:  it found nothing.  I ran MyEventViewer to see if I could identify events moments before BSOdeath.  It chewed on unspecified information for a long time, seemingly unresponsive, and then gave me a list of events, sorted by time, whose most recent one was, “The Windows Error Reporting Service entered the stopped state.”  It reported pairs of single-digit numbers whose meaning I did not attempt to determine.  This inquiry was done, at least for now; I would have to await a later crash when the memory dump would actually be available.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s