Where did my IRP go?

Hi!!!

Short story… trying to look for an IRP by following the steps listed here https://blogs.msdn.microsoft.com/ntdebugging/2011/11/23/where-did-my-disk-io-go/ without luck. The IRP is not in the outgoing packets and the original IRP is not completed.

Long: My driver makes a call to FltCreateFileEx (targetting a VHD volume) and stops in the call to NtfsAcquireExclusiveFcb owned by another thread which called NtFlushBuffersFileEx which ends in a call to DiskFlushDispatch/ClassSendSrbSynchronous that could track until VHDMP.SYS … don’t know what this driver internally do/did to the request. (checked all threads involving storport/vhdmp/disk/classpnp)

On the other hand I have several threads locked in NtfsCheckpointVolume and a worker thread that called NtfsCheckpointAllVolumes stopped in ClassShutdownFlush/DiskShutdownFlush.

No locks being held except the one for Fcb access.

Any hint on where I can continue my research will be appreciated.

Kind regards,
Mauro.

Can you make the dump available? Not saying I can find it, but faster than trying to debug over HTTP.

-scott
OSR
@OSRDrivers

Next Seminar: Windows Internals and Software Driver Development
9-13 April 2018, Sterling, VA
https://www.osr.com/seminars/software-drivers/

Hi Scott, thank you for the offer.

Because company rules, I can send you the link privately, might be thru OSR’s Facebook account or linkedin.

Kind regards,
Mauro.

(NOTE: We can make public information that might help other community users)

I revive this thread because, with the great help of Scott Noone, we could find what was going on.

The problem was a bug in my redirector driver. OneDrive’s cloud minifilter, opens a stream on a folder, first opening the folder and using the handle as the OBJECT_ATTRIBUTES.RootDirectory when opens the stream.

My driver was not handling this scenario properly and the wrong RelatedFileObject (the upper FO instead of the shadow one) was being sent to NTFS.SYS

BUT, the interesting part Scott could notice, was the volume’s VCB reference count dropping below zero and no bugcheck raising!! The only visible effect was the OS entering in some class of never-ending loop and preventing other threads to continue.

So, don’t assume a crash or deadlock will appear if your driver has a bug, other weird things can happen.

Kind regards,
Mauro.

Glad to be of help!

I have a work item to write up some of the stuff that we saw in order to help other folks track down these types of problems in the future. I will post this in the next week or two. However, in the end I just found a few things an Mauro did all the hard work to track down the issue (the man knows his way around the debugger :)).

-scott
OSR
@OSRDrivers