Filter Driver Crash in Early Boot RRS feed

  • Question

  • I am writing a new file system filter driver. All it does right now is send information about IO open events through a filter communication port.  I have this working fine on a 32-bit Windows 7 VM.  It crashes early in the boot sequence when I install it on 64-bit Windows 8.  I see this crash both on VMs and on a physical Surface Pro device. 

    I was able to reproduce the problem with the "SwapBuffer" WDK sample, with no modification beyond building.  The symptoms are identical.  One issue I noticed early on with both drivers is that though the INF file specifies SERVICE_BOOT_START (0) as StartType, and they install with that value on Windows 7, on Windows 8, the drivers get installed with SERVICE_DISABLED (4).  I have to manually set it to SERVICE_BOOT_START. 

    Here are the issues I'm facing with the crash:

    1. I have DMP file creation enabled, but no DMP (or MDMP) file is being created.

    2. I set up kernel-mode debugging.  I have that working when the driver is not loading.  When the driver is loading (I change the start-type to 0), WinDbg never gets beyond "Waiting to reconnect..."

    3. I enabled boot-logging, but when the driver crashes, I don't get the log.  Specifically, I cannot access the system volume drive in the recovery mode console, and of course, when I restart, the ntbtlog.txt is overwritten by the restart.

    4. I get nothing related to the crash in the Event Viewer.

    I use Visual Studio 2013 and build the "Win8.1 Release" x64 configuration.  I verified with DumpBin that the .sys file is 64-bit. My VM environment is Hyper-V.

    I'm running out of ideas on what to try next.  I am leaning towards a Microsoft support call, but want to see if anybody here have any insights.

    Tuesday, November 11, 2014 10:39 PM

All replies

  • I was able to reproduce the problem with the "SwapBuffer" WDK sample, with no modification beyond building. 

    I might have lied.  I have a recollection now of having to change the altitude of the driver to avoid a collision.  I definitely did not change any code.

    Tuesday, November 11, 2014 11:02 PM
  • First debug the filter completely on an easily identifiable disk (for example a flash drive) before you go anywhere near the boot disk.  From your description I suspect that the filter is interfering with the  OS load and you are not getting far enough to even debug.

    Don Burn Windows Filesystem and Driver Consulting Website:

    Tuesday, November 11, 2014 11:09 PM
  • Don,

    Thanks for the reply.  I don't quite understand "go anywhere near the boot disk."  I'm not (consciously) going anywhere near any disk.  The filter driver only triggers events and otherwise passes through on all the callbacks.  I did debug the filter fairly thoroughly on the Windows 7 system where it works.  I ran a number of stress-tests and functional tests on it, with and without the user-mode application connected.  I see no problems with it there.

    Wednesday, November 12, 2014 12:24 AM
  • In case you meant I shouldn't attach to the boot disk, I tried returning STATUS_FLT_DO_NOT_ATTACH on every instance setup callback.  (Maybe I didn't specify, but this is a mini-filter driver).  I still see the crash.

    Wednesday, November 12, 2014 2:19 AM
  • what is the specific bugcheck code? unsigned driver failed to load or code executing in your driver?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, November 12, 2014 5:18 AM
  • Doran,

    How do I see the bugcheck code?  All I get is the Windows 8 "Attempting Repairs" screen, with no further info.  I've been trying to get information from the recovery console and other means, but as described above, to no avail.

    Wednesday, November 12, 2014 8:14 PM
  • attach a kernel debugger and live debug

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, November 13, 2014 4:43 AM
  • I tried, again as described above, but the crash happens before the debugger attaches.

    Thursday, November 13, 2014 7:30 PM
  • This did turn out to be a driver signing issue. We now use a proper code signing certificate, and I no longer see the crash. I'm a little miffed that Windows 8 was unable to report that as the problem.

    Friday, January 9, 2015 8:45 PM