Toaster, remove device

NTDEV
1

Hello all.

Well, probably you are tired of my WDM questions. But I would like to ask one more. Reading Toaster’s bus example I wonder why FDO’s REMOVE_DEVICE handler cares about PDO’s SurpriseRemovalPending state?

case REMOVE_DEVICE:
// Typically the system removes all the children before
// removing the parent FDO. If for any reason child Pdos are
// still present we will destroy them explicitly, with one exception -
// we will not delete the PDOs that are in SurpriseRemovePending state.
//

ExAcquireFastMutex (&DeviceData->Mutex);

listHead = &DeviceData->ListOfPDOs;

for(entry = listHead->Flink,nextEntry = entry->Flink;
entry != listHead;
entry = nextEntry,nextEntry = entry->Flink) {

pdoData = CONTAINING_RECORD (entry, PDO_DEVICE_DATA, Link);
RemoveEntryList (&pdoData->Link);
if (SurpriseRemovePending == pdoData->DevicePnPState)
{
InitializeListHead (&pdoData->Link);
pdoData->ParentFdo = NULL;
pdoData->ReportedMissing = TRUE;
continue;
}
DeviceData->NumPDOs–;
Bus_DestroyPdo (pdoData->Self, pdoData);
}

AFAIK IRP sequence for remove is the following: QUERY_REMOVE ->REMOVE, SURPRISE_REMOVAL ->REMOVE. The thing I don’t get is why FDO handles PDO’s SR state in some special way.

Again, I am not trying to understand and remember all the complexity of WDM. Just would like to have general understanding.

–
Thanking In Advance,
Mikae.

2

Surprise on the pdo is not necessarily sent only when the device is reported as missing. Software failure can cause it to be sent. As such, the pdo sticks around until wither it is reported missing or the parent os removed.

d

debt from my phone

From: xxxxx@yahoo.com
Sent: 8/13/2012 2:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Toaster, remove device

Hello all.

Well, probably you are tired of my WDM questions. But I would like to ask one more. Reading Toaster’s bus example I wonder why FDO’s REMOVE_DEVICE handler cares about PDO’s SurpriseRemovalPending state?

case REMOVE_DEVICE:
// Typically the system removes all the children before
// removing the parent FDO. If for any reason child Pdos are
// still present we will destroy them explicitly, with one exception -
// we will not delete the PDOs that are in SurpriseRemovePending state.
//

ExAcquireFastMutex (&DeviceData->Mutex);

listHead = &DeviceData->ListOfPDOs;

for(entry = listHead->Flink,nextEntry = entry->Flink;
entry != listHead;
entry = nextEntry,nextEntry = entry->Flink) {

pdoData = CONTAINING_RECORD (entry, PDO_DEVICE_DATA, Link);
RemoveEntryList (&pdoData->Link);
if (SurpriseRemovePending == pdoData->DevicePnPState)
{
InitializeListHead (&pdoData->Link);
pdoData->ParentFdo = NULL;
pdoData->ReportedMissing = TRUE;
continue;
}
DeviceData->NumPDOs–;
Bus_DestroyPdo (pdoData->Self, pdoData);
}

AFAIK IRP sequence for remove is the following: QUERY_REMOVE ->REMOVE, SURPRISE_REMOVAL ->REMOVE. The thing I don’t get is why FDO handles PDO’s SR state in some special way.

Again, I am not trying to understand and remember all the complexity of WDM. Just would like to have general understanding.

–
Thanking In Advance,
Mikae.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Doron, I still miss something. Let me reformulate the question: Which disaster may happen if FDO destroys SRPending PDO in FDO’s REMOVE handler? And why this disaster doesn’t occur when destroying not-SRPending PDOs in FDO’s REMOVE?

I thought that this is because PDO in SRPending state expects REMOVE which destroys the PDO. But PendingRemove state also assumes that REMOVE will arrive. Why FDO doesn’t care about that in this case?

Also it seems a bit strange to unlink PDOs in FDO’s SR. We will do it in FDO’s REMOVE in any case, isn’t it?

Thank you.

4

I haven’t looked at the wdm version of toaster in a very long time. From eah you describe, this is a workaround for a pnp bug in windows 2000. A surprise removed parent should wait for all surprise removed children to process a remove before the parent is removed. This didn’t happen on win2k, fixed in XP. Unlinking the children in surprise remove is most likely to deal with this behavior. If you support XP and later, you don’t need it

d

debt from my phone

From: xxxxx@yahoo.com
Sent: 8/14/2012 6:34 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Toaster, remove device

Doron, I still miss something. Let me reformulate the question: Which disaster may happen if FDO destroys SRPending PDO in FDO’s REMOVE handler? And why this disaster doesn’t occur when destroying not-SRPending PDOs in FDO’s REMOVE?

I thought that this is because PDO in SRPending state expects REMOVE which destroys the PDO. But PendingRemove state also assumes that REMOVE will arrive. Why FDO doesn’t care about that in this case?

Also it seems a bit strange to unlink PDOs in FDO’s SR. We will do it in FDO’s REMOVE in any case, isn’t it?

Thank you.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

I just had feeling that the condition must be ‘if (SurpriseRemovePending == pdoData->DevicePnPState || RemovePending == pdoData->DevicePnPState)’. But not really sure. Good thing is that KMDF handles it all internally. But if someone knows the truth, would be glad to know.