Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 2  
20 Mar 17 06:57
Maverick
xxxxxx@gmail.com
Join Date: 04 Jan 2010
Posts To This List: 32
Identify bad disk before IRP_MN_START_DEVICE

Hi, We have a situation where we want to identify whether a disk is bad as soon as it is enumerated and presented to our SCSI class driver. By the disk being "bad" I mean the disk fails TEST_UNIT_READY commands. But by the time we realize that, it is too late for us as we've built up our device stack for that disk and cleaning it up is going to be very expensive. To fix this, I figured if I could fire a TEST_UNIT_READY command before attaching an FDO to the disk PDO and if it fails, we'll return failure from AddDevice and we'll be all set. But apparently sending an SRB synchronously to a disk while we're in the middle of processing AddDevice (for the same disk) crashes the system. So I thought the next best place to do that could be from the IRP_MN_START_DEVICE notification. We can let AddDevice succeed and when we get START_DEVICE, we fire the TEST_UNIT_READY at the underlying disk and only if that call succeeds, we'll return success from START_DEVICE. If the call fails we'll return FAILURE and PNP will do the cleanup of objects for us. However the system leads to a crash regardless. What is going wrong here? Is there a better approach to check whether a disk is good or bad? Any help will be greatly appreciated.
  Message 2 of 2  
20 Mar 17 12:26
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 253
Identify bad disk before IRP_MN_START_DEVICE

I don't think it makes sense to speculate about crashes without looking at !analyze -v output. If I remember correctly the PnP manager doesn't cleanup with IRP_MN_REMOVE the device stack if an error is returned from the START_DEVICE. It just stops building the related stacks( BusRelations etc ) and marks the device as not started so IRP_MJ_CREATE fails. The device is still present in the system and the stack will be torn down when the bus to which the device has been connected reports the device as missing or there is a request to the PnP Manager to disable the device so IRP_MN_REMOVE is sent but the stack is not being rebuilt though a PDO for the device is present at the level the device is disabled.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 07:21.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license