Windows 7: Understanding the stdriver64.sys BSOD

I was using Windows 7.  I got a blue screen of death (BSOD).  I decided, for once, to investigate it, rather than taking the usual strategy of flailing around with random potential solutions until it went away.  This post begins with a rather rambling approach to that task, describing the actual steps that I took (including tangential explorations) on the way to a fuller understanding of what the BSOD was telling me.  As the problem persisted over a period of weeks, however, I became frustrated.  Although it did ultimately seem that I had resolved the problem, I could not be confident -- it had a way of recurring -- and I did eventually get very tired of it.

The Blue Screen of Death

My particular BSOD read as follows:

A problem has been detected and Windows has been shut down to prevent damage to your computer.

If this is the first time you've seen this Stop error screen, restart your computer.  If this screen appears again, follow these steps:

Check to be sure you have adequate disk space.  If a driver is identified in the Stop message, disable the driver or check with the manufacturer for driver updates.  Try changing video adapters.

Check with your hardware vendor for any BIOS updates.  Disable BIOS memory options such as caching or shadowing.  If you need to use Safe Mode to remove or disable components, restart your computer, press F8 to select Advanced Startup options, and then select Safe Mode.

Technical information:

*** STOP: 0x0000007E (0xFFFFFFFFC0000005, 0xFFFFF880066131E0, 0xFFFFF88007BB6888,0xFFFFF88007BB60E0)

*** stdriver64.sys - Address FFFFF880066131E0 base at FFFFF88006600000, DateStamp 4d82a4a9

Collecting data for crash dump ...
Initializing disk for crash dump ...
Beginning dump of physical memory.
Dumping physical memory to disk:  100
Physical memory dump complete.
Contact your system admin or technical support group for further assistance.

Stop Codes / Stop Errors / Bug Checks

Most parts of the BSOD message were clear enough.  I knew there were general-purpose BSOD advice pages (not to mention lots of random guessing and experimentation) that could gradually yield a solution to this sort of problem.  I decided to begin by learning a bit about the parts of this BSOD message that weren't so clear.

First, I searched but did not find a catalog or list of STOP errors for Win7 x64.  A Windows XP webpage seemed to say that the Windows 7 STOP error code numbers in parentheses (the first four long ones shown above) were "error-dependent values" that "typically aren't necessary information."  That webpage also listed some common BSODs in WinXP.  For instance, some error codes would point toward RAM errors; others would point toward a hard drive problem.  A Windows Vista webpage said that my STOP error included "the error number, in hexadecimal notation, and up to four parameters that are typical of this error type."  For instance, in some STOP codes, one or more of those parameters would include information about memory.  This raised the question of whether I had a good memory testing program, in case I did find myself with a possible RAM problem at some point.

Acting on the foregoing clues, I found a hexadecimal converter and plugged in my STOP code.  The converter wouldn't take the 0x part, so I just gave it 0000007E.  (I could also have just given it 7E, without all the zeroes.)  It said the decimal equivalent was 126.  So it seemed that my Windows 7 STOP error could be referred to as error no. 0000007E, or just 7E, or 126 -- or, as I later saw, 0x7E.  A webpage discussing common Windows XP STOP errors included a reference to 0000007E, so it appeared that XP and Win7 were likely using the same codes to identify specific problems.  According to that particular website, then, it seemed I had a "System Thread Exception Not Handled" error.  That webpage went on to say that, while such an error might result from many causes, the common issue was that "A driver is incompatible or is damaged."  So that's apparently why my BSOD referred to stdriver64.sys.  Another search seemed to confirm this understanding.

Eventually I did find Microsoft's Bug Check Code Reference website.  It provided a little more information (which I didn't understand) regarding the four parameters for Bug Check 0x7E, and stated that a complete list of error codes could be found in the Ntstatus.h file in the inc directory of the Microsoft Windows Driver Kit.  For this particular 0x7E error, it repeated the suggestions shown in the BSOD (above), and also provided a number of additional suggestions:

If you do not know the specific cause of the exception, consider the following issues:

Hardware incompatibility. Make sure that any new hardware that is installed is listed in the Microsoft Windows Marketplace Tested Products List.

Faulty device driver or system service. A faulty device driver or system service might be responsible for this error. Hardware issues, such as BIOS incompatibilities, memory conflicts, and IRQ conflicts can also generate this error.

If a driver is listed by name within the bug check message, disable or remove that driver. Disable or remove any drivers or services that were recently added. If the error occurs during the startup sequence and the system partition is formatted with NTFS file system, you might be able to use Safe Mode to rename or delete the faulty driver. If the driver is used as part of the system startup process in Safe Mode, you must start the computer by using the Recovery Console to access the file.

If the problem is associated with Win32k.sys, the source of the error might be a third-party remote control program. If such software is installed, you can remove the service by starting the computer by using the Recovery Console and then deleting the offending system service file.

Check the System Log in Event Viewer for additional error messages that might help identify the device or driver that is causing bug check 0x7E.

You can also disable memory caching of the BIOS might to try to resolve the error. You should also run hardware diagnostics, especially the memory scanner, that the system manufacturer supplies. For more information about these procedures, see the owner's manual for your computer.

The error that generates this message can occur after the first restart during Windows Setup, or after Setup is finished. A possible cause of the error is lack of disk space for installation and system BIOS incompatibilities. For problems during Windows installation that are associated with lack of disk space, reduce the number of files on the target hard disk drive. Check for and delete any temporary files that you do not have to have, Internet cache files, application backup files, and .chk files that contain saved file fragments from disk scans. You can also use another hard disk drive with more free space for the installation. You can resolve BIOS problems by upgrading the system BIOS version.

So by this point, I had a number of possible questions to examine.  When I rebooted again, Windows gave me this choice:

Windows Resume Loader

The last attempt to resume the system from its previous location failed.  Attempt to resume again?
(Use the arrow keys to highlight your choice.)

Continue with system resume
Delete restoration data and proceed to system boot menu

I went with the first option, "Continue with system resume." That gave me a BSOD again -- exactly the same as above, same error codes and all.  So I rebooted yet again, and this time I chose door no. 2:  "Delete restoration data." That worked.  It let me go into Windows 7.  So apparently my driver problem was specifically related to hibernation.  That was not the only time when it would arise:  I had also gotten a few BSODs while working away in Windows, though I was not sure whether the error code had been the same.

Video Adapter Issues

At this point, I took off on a tangent.  I wanted to understand the "memory dump" mentioned at the bottom of the BSOD.  In a separate post, I have described my steps to learn more about that concept.

While pursuing that memory dump project, I had begun to get ideas for what the actual problem might be on my system.  The warnings (above) told me that, if my BSOD mentioned a specific driver, I should look for updates or disable it.  I had already done the former.  So one solution would be to go into Device Manager (in Control Panel) and disable that driver.  But when I went there, I wasn't sure where to find it.  I had assumed it was a display adapter driver, but it wasn't listed in Driver File Details for that adapter.

Then I realized that maybe it wasn't listed because it wasn't being used.  That is, I had recently changed motherboards.  Now I was using the onboard video of the new motherboard, instead of the video card that I had used previously.  Maybe the system was trying to load a driver for hardware that did not exist.  (Eventually, it would occur to me to uninstall the accompanying NVIDIA programs that I no longer seemed to need.)

I wondered if the memory dump would give me more information about this.  I went to that other post for further guidance.  Its solution was to use BlueScreenView to view minidump files (in C:\Windows\Minidump\*.dmp), and optionally to look at the "Windows has recovered from an unexpected shutdown" dialog that I would get after a BSOD.  I had not previously getting those messages; my tinkering had apparently turned this on along with the ability to create minidump files, which also had not existed previously.  (As I reviewed that post, I was still not entirely clear on what I had done, other than tinker with the paging file size and location, to get my system to start creating those minidump files and giving me those "Windows has recovered" messages.)  The dialog said that the minidump file would help to describe the problem, and also offered a "Check for solution" button.  When I clicked that button, Windows put up a dialog that said it was checking for solutions, but then the dialog just disappeared without further explanation.

I started BlueScreenView and looked at the newly generated minidump file.  Oddly, in its "Caused by Driver" column (at the top of the screen), it claimed that the driver at fault this time was usbfilter.sys, not stdriver64.sys.  I thought that it had said stdriver64.sys on the actual blue screen.  I went to the lower pane in BlueScreenView and looked at these two drivers.  It had highlighted usbfilter.sys.  This made me wonder whether the problem was related to the BIOS setting calling for USB bootup first.

While I was still in BlueScreenView, I also went to stdriver64.sys > right-click > Properties.  I didn't get any useful information there.  On my system, a search found stdriver64.sys in C:\Windows\System32\drivers.  A right-click > Properties > Digital Signatures tab regarding that file linked it with NCH Software.  Start > Settings > Programs and Features did not show an entry for NCH, but I knew that the Debut video capture program was an NCH product, and I probably had one or two other NCH programs installed.  I went to the NCH tech support forum and found a thread in which several users posted seemingly similar complaints.  NCH had not responded there, so (since I had purchased a copy of Debut) I went to the NCH tech support webpage for Debut and, through the Contact Us link, sent them a message.  Their message form asked if I had paid for support, and gave me the impression that they might ignore me if I hadn't paid for that on top of the price for the software.  When I sent that message, I got this notice:

Your support ticket has been submitted.

If you do not have a paid support contract, a technician will respond to your inquiry after your ticket has been routed to the appropriate support group, and all paid support contract tickets have been answered.

If you have purchased a support contract, your ticket should be answered by a qualified technician within 8 business hours, usually much faster depending on the length of the support queues.

Optional: Purchase a Support Contract

I was not impressed.  But they got back to me within a few hours, with these instructions:

If you have purchased within the previous 3 months please uninstall your existing version, log in as an administrator and then download and install the latest version from - http://www.nchsoftware.com/capture/index.html and retry.

I wrote back to say that, actually, I bought my copy six months earlier.  The reply in that case was,

The license is linked to the version you originally purchased so we recommend all users to keep a safe copy of the installer.

Please install with the original setup file else you might need to purchase an upgrade to use the latest version on site.

So, OK, I went into Start > Settings > Programs and Features and uninstalled Debut.  I had to reboot to complete the uninstallation.  Then I reinstalled from the original Debut download.

Another BSOD

A couple weeks passed.  The next time I hibernated and then tried to restore the system, I got an stdriver64.sys BSOD again.  I did not check to verify if its details were the same as above.

This time, after hibernating, I rebooted with an Ubuntu 11.10 Live CD, which I used to run GParted and check my drives; and then I rebooted again with the Windows 7 installation DVD and ran CHKDSK /R on the drive C partition, before trying to reboot into Windows.  CHKDSK ran successfully:  it reported that it had fixed errors on the drive.  I didn't run it a second time, as is sometimes advised.  I was not sure whether I had taken either of those steps before any previous BSODs, or whether they contributed to this one.

This time, I tried harder to avoid the "Delete restoration data" option.  I figured that meant that I would lose my hibernation, and I didn't want to do that, because I had a bunch of files open.  But my efforts were worse than unsuccessful.  I wound up with a system that would not boot:

Windows Error Recovery

Windows failed to start.  A recent hardware or software change might be the cause.

If Windows files have been damaged or configured incorrectly, Startup Repair can help diagnose and fix the problem.  If power was interrupted during startup, choose Start Windows Normally.
(Use the arrow keys to highlight your choice.)

Launch Startup Repair (recommended)
Start Windows Normally

I was not sure, when I was writing these notes, which of those options I chose.  Both, at one time or another; I went through this scenario repeatedly.  The next screen I got was:

Windows Boot Manager

Windows failed to start. A recent hardware or software change might be the cause.  To fix the problem:

1.  Insert your Windows installation disc and restart your computer.
2.  Choose your language settings, then click "Next."
3.  Click "Repair your computer."

If you do not have this disc, contact your system administrator or computer manufacturer for assistance.

Status:  0xc000000f

Info:  The boot selection failed because a required device is inaccessible. 

The computer cycled between these two screens until I punched its reset button and rebooted with the Windows DVD.  When I ran the DVD's Startup Repair option, the resulting error was, "Root cause found:  the partition table does not have a valid System Partition."  It said it fixed that problem, but when I came back into the System Repair option again, it still showed no operating system.  I tried the Command Prompt option from the Windows DVD.  I tried to get to drive C (which the DVD was seeing as drive D), but it said, "The file or directory is corrupted and unreadable."

I rebooted with the Ubuntu 11.10 CD, in hopes of looking to see what was there, but for some reason was unable to mount what I called the PROGRAMS partition (i.e., drive C).  So I could see, in my future, the distinct possibility of a complete restore of drive C from a backup image.  Normally, I made those backups using Acronis True Image Home on a bootable CD.  Recently, however, I had tried making an Acronis image by using the version installed on my computer.  I now saw that this approach was bankrupt:  that backup was defunct.  Fortunately, I had made another Acronis backup by rebooting from the DVD.  That one worked.  So that got me past this particular BSOD.

Homing in on the Problem

When the system was back up, I played with it for five minutes, hibernated, and let it sit cold for another ten minutes.  This time, I didn't use the Ubuntu or other bootable CDs; I just restored from the hibernation.  It worked fine; I got no issues.  I hibernated again and immediately rebooted with the Ubuntu CD.  Last time, GParted had seen drive errors on drive C.  I wasn't sure whether those drive errors were related to (possibly the cause of) the BSOD.  Windows had been running OK.

Be that as it may, this time GParted saw errors again.  This time, though, I didn't reboot immediately with the Windows DVD to run CHKDSK.  Instead, I just tried to go directly into Windows 7.  It failed:  BSOD!  So was going into Ubuntu the cause?  Or was Ubuntu merely detecting problems that were already there?  I rebooted with the Windows 7 DVD and went into the Repair Your Computer option.  As before, it detected no operating system.  I tried Use Recovery Tools > Startup Repair > Finish, as before.  On reboot, it went into Windows OK.  There were a bunch of corrupted files, though:  Windows ran an automatic disk check and seemed to have a lot of things to clean up.

Once I was back in Windows, I tried the same cycle again.  First, a hibernate-and-reboot without inserting any other CDs.  No problem.  Then a hibernate-and-reboot with the Ubuntu CD.  Didn't go into GParted this time; just started Ubuntu and then exited and rebooted.  (This was an Ubuntu 11.10 Live CD.)  It started to load the Windows desktop, and then gave me the stdriver64.sys BSOD.  So it seemed that the stdriver64.sys BSOD was arising from the use of Ubuntu.  It seemed that the computer hardware was getting confused.  I did experiment with letting the computer sit, turned off, for five or ten minutes; unfortunately, my notes on that phase were lost, as I was now beginning the process of having similar problems on the other computer, where I was recording these developments.

It was beginning to seem that there were two distinct Ubuntu-related problems.  Very preliminarily, it appeared possible that, if I hibernated a 64-bit Windows 7 system and then started it with Ubuntu, there would be some nasty conflict between the hibernation file and something that happened when Ubuntu loaded.  If I immediately returned to Windows without doing anything more, I *might* have an option of dumping my hibernation file and still getting into Windows OK; but if I screwed around and tried to preserve the hibernation file, I might have an unbootable system, requiring an image restore.  And then, if I went ahead and ran GParted, while in Ubuntu, it seemed that might also give me an unbootable system, possibly for unrelated reasons.

Same/Different Machine, Different BSOD

While this was developing, I booted the other computer and ran GParted.  It had the same hardware:  Gigabyte GA-880GMA-USB3 motherboard, ATI Radeon HD 4250 onboard graphics.  On that machine, I wasn't using an Ubuntu CD; I was using a bootable Ubuntu 11.10 USB drive.  It was a great little tool.  I ran its version of GParted to adjust a partition on that second computer.  Then I rebooted into Windows ... almost.  Over there, I got a slightly different BSOD.  It started out the same as above:  "A problem has been detected and Windows has been shut down to prevent damage to your computer."  But it didn't contain a reference to stdriver64.sys, and its Technical Information section was different:

*** STOP: 0x000000F4 (0x0000000000000003,0xFFFFA80082AD060,0xFFFFFA80082AD340,0xFFFF800039878B0)

I punched that computer's reset button and chose the Start Windows Normally option from the boot menu.  It said Starting Windows.  Then I got a flash and it rebooted.  I tried the Launch Startup Repair option.  It told me to insert the Windows 7 DVD.  I went into the DVD's Command Prompt option.  It, too, gave me the "corrupted and unreadable" error.  I rebooted with an Ubuntu 10.10 (not 11.10) CD.  This time, I could see the contents of the PROGRAMS (C:) drive.  It seemed like the folders were all there:  C:\Windows, etc.

By coincidence, at this very time, an RSS feed gave me a Gizmo post on making hibernation work better.  The key ideas there were that hiberfil.sys could become corrupted or badly fragmented.  In that case, it seemed, one could delete it from the command line.  The delete command was "powercfg -h off."  Restoring the file was "powercfg -h on."  Changing its size (down to a minimum of 50%) was "powercfg -h -size 50."  Of course, since I was now looking at hiberfil.sys in the Nautilus file explorer program in Ubuntu, I could also just delete it right here.  I moved it to the trash, emptied the trash, and rebooted.  I chose the Start Windows Normally option.  That didn't work.  On the reboot, the Launch Startup Repair option didn't work either.  So deleting hiberfil.sys in Ubuntu was not the obvious solution.  I did wonder, though, whether I could use Ubuntu to move hiberfil.sys to somewhere else (assuming I did want or need to boot with an Ubuntu CD) and then move it back to C:\ after rebooting in Windows.  On the first Win7 reboot, I would not have my hibernated arrangement; but on reboot, after restoring my moved hiberfil.sys, perhaps I would.  And would it be possible to save different hiberfil.sys files, to return to different startup conditions?  I also wondered whether these problems were new with Ubuntu 11.10 and/or with this Gigabyte motherboard, replaced in recent months.  I hadn't had these problems previously.

But anyway, I booted with the Win7 DVD.  Command Prompt said, "The file or directory is corrupted and unreadable."  The solution used above was to restore from an Acronis backup.  I didn't like that option.  Surely there was a way to persuade Windows to be reasonable about this, seeing how it looked like all the files were there and waiting to go.  It seemed that something like BartPE might be the solution.  I was on drive C, there in Command Prompt, and I wanted to get to drive D.  A search led to the suggestion to just use CHKDSK D: /R.  Obvious solution that I had never tried.  Didn't know you could do that.  But it worked, at least in the sense that CHKDSK ran and proceeded to find all kinds of problems.  (Examples:  "Recovering orphaned file CR4951~1.760 (359913) into directory file 11168" and "Inserting an index entry with Id 4044 into index $SDH of file 9.")  There was also the suggestion to use TestDisk, if I was running from within Windows and wanted to recover lost data; but that wasn't the case here.

When CHKDSK was done, I rebooted and got the "Windows failed to start" error (above).  The status was 0xc000000e, "The boot selection failed because a required device is inaccessible."  I rebooted with the Windows 7 DVD.  Its Startup Repair option achieved nothing, in the sense that a reboot after I ran it left me with the same "Windows failed to start" error.  A second try with the Win7 DVD > Command Prompt showed me that I could now get into drive C (recognized here as D), and the hiberfil.sys file was gone.  We did seem to be making progress.  I tried "bootrec /fixmbr" and "bootrec /fixboot."  It said, "Element not found."  A search led to a thread indicating that perhaps I should enter BCDBOOT D:\Windows (where D was, again, what the Win7 CD was calling my drive C), but that produced "Failure when attempting to copy boot files."

That thread also suggested that I type DISKPART.  That opened a program, Microsoft's Diskpart.  Among its command line options (also visible by typing COMMANDS at the Diskpart prompt), I began with LIST DISK.  This showed me that I had two hard drives.  It wasn't too informative.  I tried SELECT DISK 0 and then LIST PARTITION.  That didn't look like the right drive.  I tried SELECT DISK 1 and then LIST PARTITION.  Yes, from the size of it, disk 1 partition 1 appeared to be what I wanted.  Then I noticed, from one of my own posts, that DETAIL DISK was more informative than LIST PARTITION.  But now I saw that I probably could have just started with LIST VOLUME, which listed all partitions on both drives.  So, yes, I was looking for volume 6, drive D, disk 1, partition 1.  Now what?  The advice seemed to be that I should just make sure I had typed SELECT DISK 1 and then (to be double-sure) LIST PARTITION and then SELECT PARTITION 1 and then ACTIVE and then EXIT.  I rebooted and found myself back at the Windows Error Recover screen.  I let it default to the repair option, and that immediately gave me the "required device is inaccessible" error again.  So DISKPART didn't seem to be the solution.

Others in that same thread had succeeded with GParted.  I decided to try that again, this time using the Ubuntu 10.10 rather than 11.10 CD.  The version of GParted was 0.5.1.  It showed the PROGRAMS partition as already being flagged as the boot partition.  I ran a check, while I was there.  It indicated no problems.  I noticed that someone said they had fixed the problem by reversing drive cables.  Since my first drive was actually being shown as my second drive, and vice versa, I decided to try that.  On reboot, I chose the Start Windows Normally option instead of Launch Repair.  The machine ran a disk test on one of my partitions.  This felt like progress.  While I was waiting for that to finish, I opened a command window on the first computer and ran DISKPART > LIST VOLUME and so forth.  It, too, seemed to be saying that my PROGRAMS partition (drive C) was actually located on the second of my two drives.  A few minutes later, I was able to boot into Win7 on the second machine.  Problem apparently solved on both.

Recap

My stdriver64.sys BSOD appeared to be related to several factors.  I had not nailed them all down at this point, but the focus was narrowing.  First, it appeared possible that I was getting more Windows-compatible results from an older version of GParted, as provided on the Ubuntu 10.10 rather than 11.10 CD.  In fact, it seemed that the newer GParted, opened in response to the BSOD, might actually be aggravating the problem.  Second, it appeared helpful to have the drive cables in the correct order, so that the bootable Windows partition (drive C) was the first partition on the first drive, as shown by DISKPART (and also, for that matter, by Start > Run > diskmgmt.msc).  Third, it seemed unwise to boot from an Ubuntu Live CD or USB drive (with or without running GParted) on a hibernated machine.  That is, if I was going to boot Ubuntu, I should probably do a full shutdown of Windows first.

In addition to these points, it may have been helpful to remove unnecessary NVIDIA software, now that I had switched to different video hardware; but if so, I was not seeing an obvious connection.  There was a suggestion that my version of the Debut video capture program was responsible, but at this moment that did not appear to be an issue.  The simple step of using CHKDSK from an adjacent drive (e.g., CHKDSK D: /R from the C:\ prompt) was a huge help.

One potentially helpful step, on at least one computer, was to use DISKPART to designate the active partition.  It appeared that POWERCFG would offer another option, but I did not test that.  The possibility of deleting hiberfil.sys (hibernation) files raised a question of whether it would be possible to get different starting desktop arrangements by swapping hiberfil.sys files.  It might not be difficult to do that if, for instance, Win7 was running as a virtual machine in Ubuntu.

Redux

Part of the reason for my disgust was that, as I was writing up that recap, I got another stdriver64.sys BSOD on the second computer.  I rebooted and let Windows fully load all of the programs in my Startup folder.  Then I looked particularly at a dialog that said this:

Windows has recovered from an unexpected shutdown

Windows can check onlin for a solution to the problem.

Last time, I had clicked on the "Check for solution" button, and then the system had given me that stdriver64.sys BSOD shortly thereafter.  Was that why it crashed?  Because I hadn't clicked that way this time, and it still hadn't crashed.  I clicked on the Problem Details option and saw an indication that two files contained relevant information.  One was a Minidump file.  Using BlueScreenView, I looked into that file, but I still didn't know how to interpret it.

I decided not to click the Check for Solution button.  Instead, since I had unceremoniously deleted the previous hiberfil.sys file while in Ubuntu, I thought it might help smooth things over if I hibernated the machine again, now, and then restarted it, just to clear out anything that might have been referring to that hiberfil.sys file.  No BSOD on reboot.  I ran Glary Registry Cleaner.  It found hundreds of errors.  I hoped that cleaning them up would help.  For the moment, at least, both systems were stable and had survived several reboots (without further forays into Ubuntu).