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.
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.
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:
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.