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

Shintaro

Shintaro

Well-known member
Joined
Jun 12, 2012
Posts
206
Location
Brisbane, Australia
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 a moderator:
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.
 
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??
 
Not entirely sure if I am correct on this, but I believe you're going to want to check IRP Logging for that.
 
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`[COLOR=#ff0000]c0000010 [/COLOR]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`[COLOR=#ff0000]c0000010 [/COLOR]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 = [COLOR=#ff0000]c0000010[/COLOR]
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 ffffffff[COLOR=#ff0000]c0000010[/COLOR]
 [  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:

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top