I’m working on a scsi miniport that has an application that’s constantly
chatting with the miniport.
I see at times (like if the miniport changes the online devices with
ScsiPortNotification/BusChangeDetected) a lock get’s held that prevents
graphics operations from happening.
Specifically:
The CSRSS process sends I believe a IOCTL_MOUNTMGR_NEXT_DRIVE_LETTER IOCTL
to the MountMgr device (perhaps in response to some Win32 API call from
another app). Before doing so, somebody grabs a lock (it says
win32k!EnterCrit) that prevents operations on graphics device context’s
(scrolling a DC is where I’m seeing things deadlock). My miniport driver
needs to talk to an app before responding to the bus enumeration. The
system gets stuck because the lock is held, and my app can’t do graphics
(like scroll a command window with debug messages), so stops talking to the
scsi miniport, which prevents the INQUIRY srb from completing and releasing
the lock. It looks like GUI input event processing may be locked too
(win32k!RawInputThread is waiting on the lock).
I can work around this by queueing my graphics operations (a lot of work
just for debug messages), or caching a little more data in my miniport, but
was wondering what else might be prevented by this lock. If I don’t write
any messages (don’t scroll the DC) everything seems fine. It was one of
those fun bugs that the more debug info you dump the worse it gets.
Anybody know what the lock synchronizes, and when it get’s held? I also
believe none of the “new and improved” SCSIPORT replacements would resolve
this issue. It’s NOT an issue of a scsi queue being locked.
- Jan
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com