1. #1
    Shintaro's Avatar
    Join Date
    Jun 2012
    Location
    Brisbane, Australia
    Age
    48
    Posts
    175

    How do I dig deeper in a Driver Verifier mini dump?

    Hi,

    I have this crash dump that I cannot seem to find why HIDCLASS.SYS is crashing.
    The user has updated:
    - MS AV
    - Motherboard Drivers / BIOS.
    - Using a standard Keyboard & mouse
    - Games, such as Steam.
    - Tested the RAM
    - Tested the HD (With Seagate software)

    Has problems running MS defender offline (Error Code: 0x8004cc01).

    Driver Verifier is on.

    So it crashes when the user plays a game or browsing the internet. So I am not sure how to dig deeper to find or prove the problem. I was hoping for a pointer in the crash dump that points to something other than HIDCLASS.SYS.

    Any ideas??

    Cheers
    Last edited by jcgriff2; 07-16-2017 at 05:27 PM.
    Try to live an ordinary life, in a non-ordinary way.


    • Ad Bot

      advertising
      Beep.

        
       

  2. #2

    Re: How do I dig deeper in a Driver Verifier mini dump?

    After checking the loaded modules list, SPTD.sys is listed, this is the SCSI Pass Through Direct Host - Daemon Tools (known issues with Win7). Daemon Tools isn't listed in the modules list, but it's probably still installed / was at one point. Regardless, tell the user to uninstall this driver using the DuplexSecure SPTD Uninstaller Tool.

    Unfortunately, no IRP address left over in the 4th argument to run an !irp on to get more info on what driver may be causing it. If the user it experiencing MS Defender online issues, I would recommend telling the user to uninstall MS Defender. It may be conflicting with whatever anti virus the user is using, or it may just need a good old fashioned reinstall.

  3. #3
    Shintaro's Avatar
    Join Date
    Jun 2012
    Location
    Brisbane, Australia
    Age
    48
    Posts
    175

    Re: How do I dig deeper in a Driver Verifier mini dump?

    Thanks for your help E-Peen, I have advised the user. I'll let you know as soon as I can.

    Is there a way to ensure that the IRP is added to the mini dump? Something in Verifier??
    Try to live an ordinary life, in a non-ordinary way.

  4. #4

    Re: How do I dig deeper in a Driver Verifier mini dump?

    Not entirely sure if I am correct on this, but I believe you're going to want to check IRP Logging for that.

  5. #5

    Join Date
    Mar 2012
    Posts
    469

    Re: How do I dig deeper in a Driver Verifier mini dump?

    Nope, there's no way to ensure it. Minidumps are very basic items that will only skim the most recent and "relevant" data, and it can be very fickle on picking and choosing. For a reliable source of info, you'll always want a kernel dump.

    As for IRP Logging, which IRP Logging is probably one of the best items to collect data on I/O and find faults dealing with em, you can only access the log during a live kernel debugging session - they are not preserved in crashdumps. Your best bet is to grab a kernel dump triggered by Driver Verifier.

    The issue in this case is that a driver within an IRP stack attempted to manipulate an IRP that doesn't belong to it. Sometimes drivers - like filter drivers - will sit in a device stack but isn't responsible for dealing with particular I/O that may pass through that stack. When that's the case, the I/O - or IRP - can't just "hop" over the device/driver. Rather, it passes through it, as in the driver looks at it, sees it's not responsible for it, and passes it along down the stack to the next driver. It should not manipulate it in any way when this is the case. So what was going on here is that IRPs are getting infiltrated by a rambunctious driver that's toying with I/O it's not responsible for. If I'm looking at it correctly, I believe the result ends up in a c0000010 error, which means, "The specified request is not a valid operation for the target device." You can see this in both the callstack, the IoStatus, and a hint of it in the IRP:

    Code:
    STACK_TEXT:  
    fffff880`033b60e8 fffff800`037183dc : 00000000`000000c9 00000000`0000023b fffff880`0443a710 fffffa80`083d2010 : nt!KeBugCheckEx
    fffff880`033b60f0 fffff800`0372247a : fffff800`037169f0 fffff880`0443a710 fffffa80`083d2010 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0x3c
    fffff880`033b6130 fffff800`03723483 : 00000000`0000023b 00000000`c0000010 fffffa80`083d2010 00000000`ffffffff : nt!ViErrorFinishReport+0xda
    fffff880`033b6180 fffff800`03723b42 : fffffa80`083d2248 fffff880`0443a710 00000000`00000000 00000000`00000000 : nt!VfErrorReport1+0x63
    fffff880`033b6220 fffff800`03718071 : fffffa80`09fbc330 00000000`00000001 00000000`00000000 fffffa80`083d2248 : nt!ViGenericVerifyIrpStackUpward+0x62
    fffff880`033b6250 fffff800`03724b2d : fffffa80`0a6231e0 fffffa80`09fbc010 fffffa80`083d2010 fffffa80`083d2010 : nt!VfMajorVerifyIrpStackUpward+0x91
    fffff880`033b6290 fffff800`0373650d : fffffa80`083d2248 fffff880`033b6480 00000000`c0000010 fffffa80`083d2248 : nt!IovpCompleteRequest2+0xad
    fffff880`033b6300 fffff800`03295bc1 : fffffa80`083d224b 00000000`00000000 00000000`000000ff fffff800`03719eea : nt!IovpLocalCompletionRoutine+0x9d
    fffff880`033b6360 fffff800`0372e19f : fffffa80`083d2010 fffff880`04444400 fffffa80`0a2bba00 00000000`00000000 : nt!IopfCompleteRequest+0x341
    fffff880`033b6450 fffff800`03277116 : fffff880`00000013 fffff880`033b6578 fffffa80`083d2248 fffffa80`0a2bbaf0 : nt!IovCompleteRequest+0x19f
    ...
    
    3: kd> !irp fffffa80083d2010 1
    Irp is active with 8 stacks 7 is current (= 0xfffffa80083d2290)
     No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
    Flags = 40000000
    ThreadListEntry.Flink = fffffa80083d2030
    ThreadListEntry.Blink = fffffa80083d2030
    IoStatus.Status = c0000010
    IoStatus.Information = 00000000
    RequestorMode = 00000000
    Cancel = 00
    CancelIrql = 0
    ApcEnvironment = 00
    UserIosb = 00000000
    UserEvent = 00000000
    Overlay.AsynchronousParameters.UserApcRoutine = 00000000
    Overlay.AsynchronousParameters.UserApcContext = 00000000
    Overlay.AllocationSize = 00000000 - 00000000
    CancelRoutine = 00000000   
    UserBuffer = 00000000
    &Tail.Overlay.DeviceQueueEntry = fffffa80083d2088
    Tail.Overlay.Thread = 00000000
    Tail.Overlay.AuxiliaryBuffer = 00000000
    Tail.Overlay.ListEntry.Flink = 00000000
    Tail.Overlay.ListEntry.Blink = 00000000
    Tail.Overlay.CurrentStackLocation = fffffa80083d2290
    Tail.Overlay.OriginalFileObject = 00000000
    Tail.Apc = 00000000
    Tail.CompletionKey = 00000000
         cmd  flg cl Device   File     Completion-Context
     [  0, 0]   0  2 00000000 00000000 00000000-00000000    
    
                Args: 00000000 00000000 00000000 ffffffffc0000010
     [  0, 0]   0  0 00000000 00000000 00000000-00000000    
    
                Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000    
    
                Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000    
    
                Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000    
    
                Args: 00000000 00000000 00000000 00000000
     [ 17,ff]   0  2 fffffa800a2bb9a0 00000000 00000000-00000000    
              fffffa800a2bb9a0: Could not read device object or _DEVICE_OBJECT not found
    
                Args: fffffa800a2b35b0 00000000 00000000 00000000
    >[ 17,ff]   0 e0 fffffa800a2bb9a0 00000000 fffff8000371ada0-fffffa80083d22d8 Success Error Cancel 
              fffffa800a2bb9a0: Could not read device object or _DEVICE_OBJECT not found
        nt!IovpInternalCompletionTrap
                Args: fffffa800a2b35b0 00000000 00000000 00000000
     [ 17,ff]   0 e0 fffffa800a2bb460 00000000 fffff80003724240-fffff880033b6720 Success Error Cancel 
              fffffa800a2bb460: Could not read device object or _DEVICE_OBJECT not found
        nt!ViIrpSynchronousCompletionRoutine
                Args: fffffa800a2b35b0 00000000 00000000 00000000
    
    3: kd> !error c0000010
    Error code: (NTSTATUS) 0xc0000010 (3221225488) - The specified request is not a valid operation for the target device.
    Note I added "1" to the end of the !irp command. Any value given after the address specifies that you want to display additional info on the IRP. Much of this is not retained in a minidump, but at least the IoStatus is.

    If I'm correct, this IRP may actually be a false, bogus one generated by Driver Verifier to perform these checks, or it could be legit. If it is legit, then you'll want to note the major function code for the IRP, which is 17 (that's the [17, ff] on each IRP stack). Look it up in Windbg help manual for !irp and you'll find it's SURPRISE_REMOVAL. This means that the system is notifying all relevant drivers that this device in particular has been suddenly removed and allows them to react accordingly. That should be a good hint on what's going on at the time.

    I, and I doubt many others, can figure out further on this, because any further attempt to dive into this gets shot down by missing data because it's a minidump. A kernel dump will be needed to continue further. Further. Lol.

    Btw, the client should only be selecting 3rd party drivers when setting up Driver Verifier. Can you confirm that this has been the case? Selecting Windows drivers can have various side effects and false positives.
    Last edited by Vir Gnarus; 06-20-2012 at 09:51 AM.
    Trouble and Shintaro say thanks for this.

  6. #6

    Join Date
    Feb 2012
    Posts
    2,086
    Blog Entries
    7

    Re: How do I dig deeper in a Driver Verifier mini dump?

    Just FYI - the sptd.sys driver isn't uninstalled when you uninstall Daemon Tools or Alcohol % software.
    You've gotta use the Duplex Secure tool to remove it: http://www.duplexsecure.com/faq#remove_32sptd

    This is probably the most problematic driver that we find during BSOD analysis. Removing it will normally fix most BSOD issues.
    zigzag3143, JMH and Vir Gnarus say thanks for this.

Similar Threads

  1. Is there anyway to fix corrupted / broken mini dump files.
    By Shintaro in forum BSOD, Crashes, Kernel Debugging
    Replies: 2
    Last Post: 07-23-2012, 09:55 AM
  2. [SOLVED] !verifier error?? 6: kd> !verifier fffff8000348fac0: Unable to get verifier list.
    By Shintaro in forum BSOD, Crashes, Kernel Debugging
    Replies: 12
    Last Post: 07-09-2012, 09:15 AM
  3. How do I see RAM overclocking in Mini dump????
    By Shintaro in forum BSOD, Crashes, Kernel Debugging
    Replies: 9
    Last Post: 06-27-2012, 01:57 PM
  4. Windbg: Processes and Threads in mini dump?????
    By Shintaro in forum BSOD, Crashes, Kernel Debugging
    Replies: 4
    Last Post: 06-14-2012, 11:52 AM
  5. Driver Verifier - BSOD related - Windows 10, 8.1, 8, 7 + Vista
    By jcgriff2 in forum BSOD, Crashes, Kernel Debugging
    Replies: 3
    Last Post: 03-14-2012, 11:56 AM

Log in

Log in